dev: starknet_getStateUpdate improvement ✨

[EvolveArt]

Current Behavior

getStateUpdate RPC endpoint is mocked.

Ok(StateUpdate {
            block_hash: block.header().hash(*self.hasher).into(),
            new_root: block.header().global_state_root.into(),
            old_root,
            state_diff: StateDiff {
                storage_diffs: Vec::new(),
                deprecated_declared_classes: Vec::new(),
                declared_classes: Vec::new(),
                deployed_contracts: Vec::new(),
                replaced_classes: Vec::new(),
                nonces: Vec::new(),
            },
        })

Expected Behavior

Make it work as expected, following pathfinder implementation.

[dbejarano820]

Is this possible with the current implementation of the rpc?

[nikania]

@EvolveArt it seems like rpc endpoint always returns empty state_diff https://github.com/keep-starknet-strange/madara/blob/10fd0a8c8735655fd09e32582bc11dafeb6aca72/crates/client/rpc/src/lib.rs#L631-L638 therefore not much to test

[danilowhk]

I can take this one

[MdTeach]

@danilowhk #836 refactored the integration test structure. I think you will be working on this test file. Could you check once.

[AbdelStark]

I can take this one

hey, any ETA ?

[danilowhk]

I had a look but wasn't able to actually dig into it, if someone wants to take it please give to them. Apologize for the late notice.

[chee-chyuan]

throwing in some of my ideas which could be 100% . happy to get corrected

1. should we follow pathfinder's implementation, that would mean that we will need to sync state_update while syncing block. As pathfinder is a client and not a sequencer, it takes no responsibility in executing transactions and proposing new blocks, and thus it gets the state_update from the feeder gateway. code below.

#[tracing::instrument(skip(self))]
    async fn state_update(&self, block: BlockId) -> Result<StateUpdate, SequencerError> {
        let state_update: reply::StateUpdate = self
            .feeder_gateway_request()
            .get_state_update()
            .with_block(block)
            .with_retry(self.retry)
            .get()
            .await?;

        Ok(state_update.into())

2. with madara being a sequencer, when proposing a block, there needs to have a way to store the state update for that block too. and then, share state_update for the specific block via rpc. with my shallow understanding of substrate, im guessing that there is a need to modify the block-proposer crate to do so.

3. after which, when in sync_block, somehow get state_update along with our block info (still figuring out how this part works)

[rkdud007]

Hey if this issue is not assigned to someone, can i take it?

[AbdelStark]

yes please

[rkdud007]

Before I jump on the code, any feedback appreciated ( cc. @abdelhamidbakhta, @EvolveArt).

Approach Suggestion:

1. Retrieve state_diff of Starknet from storage_change ( Can get it from Substrate's blockbuilder ).
2. When syncing a new block, obtain state_diff using storage_change before storing it in the Madara backend database.
3. Introduce a field in the Madara DB for storing state_diff.
4. Through rpc, access Starknet's state_diff from the Madara database, which was stored during block syncing.

I'm not deeply familiar with the substrate storage system, but I saw related discussions in the TG group chat. @abdelhamidbakhta, any insights on retrieving state_diff from storage_changes would be helpful. 🙏🏻

[tdelabro]

@rkdud007 Did you do any progress on this one?

[rkdud007]

hey sorry for delay, was paused for a moments handling recently. Will share shortly :)

[tdelabro]

Sure! Do you need help on this or all good? I just saw we didn't receive responses to your question. Did you find out by yourself?

[rkdud007]

Yes! If I could get more information about this question would be very helpful :) still bit confuse at how to combine pallet’s storage_change and starknet state_diff part :/

[lana-shanghai]

Yes! If I could get more information about this question would be very helpful :) still bit confuse at how to combine pallet’s storage_change and starknet state_diff part :/

Hey I will first do this issue https://github.com/keep-starknet-strange/madara/issues/1081 and then you can wrap up the RPC task, is that's OK with you!

[rkdud007]

Ah there is an issue for this, sure @lana-shanghai ! :))

[github-actions[bot]]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a 👍 Because this issue is marked as stale, it will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[github-actions[bot]]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a 👍 Because this issue is marked as stale, it will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[tdelabro]

blocked by https://github.com/keep-starknet-strange/madara/pull/1390

[tdelabro]

will use the code developed for https://github.com/keep-starknet-strange/madara/issues/1372

[github-actions[bot]]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a 👍 Because this issue is marked as stale, it will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[neelkamath]

Do we know when the state update API will be fixed? I heard of the following issues:

In the madara release-v0.7.0, the getStateUpdate interface is not implemented. Although the latest version of madara code implements this interface, the logic is also incorrect. The most critical issues are: 1. StateRoot calculation is not currently correct. 2. The state diff includes some states belonging to Substrate but not to StarkNet.

[tdelabro]

@antiyro and deoxys should fix the 1. soon. 2. I had no idea about that, will have to double check and fix it

[jbmkahdeksan]

hi! Is this available to contribute? I am interested, what do I need to know?

[github-actions[bot]]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a 👍 Because this issue is marked as stale, it will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[gerceboss]

@EvolveArt, would like to take up this issue if it's still relevant, I am new to Cairo and Starknet , might need help as well.

[onlydustapp[bot]]

Hey @gerceboss! Thanks for showing interest. We've created an application for you to contribute to Madara. Go check it out on OnlyDust!

[leykhan16]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I'm a recent graduate of computer science, Alx Africa certified software engineer, ICP/ Dacade certified blockchain developer and Rust (smart contracts ) expert.

How I plan on tackling this issue

Understand the current implementation Understand pathfinders implementation Implementation of missing logic Test the implementation

[nelsonaty]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I have a strong foundation in software development with a focus on blockchain technology and decentralized applications. My experience includes working with smart contracts, blockchain infrastructure, and various consensus mechanisms. I have also worked on integrating blockchain networks with front-end and back-end applications, providing end-to-end solutions for decentralized projects.

Relevant Skills:

Proficient in blockchain development (Solidity, Rust, etc.) Experience with blockchain frameworks and tools (Ethereum, Polkadot, StarkNet, etc.) Knowledge of smart contract auditing and security Strong problem-solving and debugging skills Familiarity with RPC (Remote Procedure Call) endpoints and blockchain APIs

How I plan on tackling this issue

Understanding the Requirements: The given snippet suggests that the tStateUpdate RPC endpoint is mocked, and the goal is to make it work as expected, following the pathfinder implementation.

Steps to Address the Problem:

Study Pathfinder Implementation:

Review the pathfinder codebase to understand how they handle the tStateUpdate endpoint. Identify the key components and logic used in pathfinder for state updates. Analyze the Mock Implementation:

Examine the existing mocked implementation to identify what aspects are missing or incorrect. Understand the structure of the StateUpdate and its components (block_hash, new_root, old_root, state_diff). Design a Working Implementation:

Plan how to transition from the mock to a functional implementation. Ensure that the necessary data (e.g., block header, global state root, state differences) is accurately retrieved and processed. Implement the Changes:

Replace the mocked components with real data processing and retrieval. Ensure that the block_hash, new_root, old_root, and state_diff are correctly computed and formatted. Testing and Validation:

Write unit tests to verify the correctness of the StateUpdate implementation. Perform integration tests to ensure the endpoint functions as expected within the larger application. Documentation and Best Practices:

Document the changes and the rationale behind them. Follow best practices for code quality, security, and performance.

[YashBit]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

NYU CS Cambridge MPhil (Deferred)

Rust Programmer Grant - PSE Ethereum Foundation

How I plan on tackling this issue

• Review the StateUpdate Structure: Check how the StateUpdate response is constructed in the Pathfinder implementation. Specifically, examine how block_hash, new_root, old_root, and state_diff are derived and populated.

• Understand Data Sources: Identify where and how data like block.header().hash, block.header().global_state_root, and old_root are sourced and used in the actual implementation.

• Study the StateDiff Components: Review how StateDiff is populated, including storage_diffs, deprecated_declared_classes, declared_classes, deployed_contracts, replaced_classes, and nonces. Ensure you understand the data and formats expected for each component.

• Consult Documentation: Refer to any available documentation or source code comments that describe the expected behavior and data structures for getStateUpdate.

---