State sync from l1

[OmniaFlux]

Add sync state from L1 feature

Pull Request type

• Feature

What is the current behavior?

Currently, there is no functionality to synchronize data from L1.

What is the new behavior?

• When the functionality to synchronize state from L1 is enabled, the node fetches a trusted state diff from L1.
• Node will package the state diff into a substrate block, which includes a starknet block header in the block header digest, and then apply it locally.
• Due to the absence of a transaction list on L1, this feature cannot construct a complete blockchain; it can only build a complete state.

Does this introduce a breaking change?

No

[tdelabro]

Hey thanks for the good work. Can I ask why did you develop that? In the context of a Madara appchain, what is the use you envision for this? What should the chain do with that l1 state once it get it?

I think it can be used as a way to finalize the l2 state, but it needs something build on top of it. Did you had other stuffs in mind?

[tdelabro]

Also, are you aware of this PR: #1282 It's about getting the l1->l2 messaging, by reading l1. We are going to merge it on main soon. Can you give it a look and tell me if it is redundant with your PR?

[OmniaFlux]

Hey thanks for the good work. Can I ask why did you develop that? In the context of a Madara appchain, what is the use you envision for this? What should the chain do with that l1 state once it get it?

I think it can be used as a way to finalize the l2 state, but it needs something build on top of it. Did you had other stuffs in mind?

Based on this issue https://github.com/keep-starknet-strange/madara/issues/1224, we developed the code in this pull request (PR). This feature can be used to rapidly rebuild the state of L2 from L1. After understanding the synchronization mechanisms of other Starknet sequencer implementation approaches, we found that they currently heavily rely on centralized feedline gateways, which are going to be phased out. The alternative to feedline gateways is full-node RPC. However, this remains fundamentally centralized as we must trust the linked RPC. Therefore, by utilizing data synchronized from L1, as the data on L1 is proven, we can rapidly build the L2 state without the need for trust assumptions.

[OmniaFlux]

Also, are you aware of this PR: #1282 It's about getting the l1->l2 messaging, by reading l1. We are going to merge it on main soon. Can you give it a look and tell me if it is redundant with your PR?

I've read the code, and there are no redundant with my PR. This PR (#1282) is about retrieving and applying messages from L1 to L2, whereas mine is about fetching L2 state from L1 and applying it locally.

[antiyro]

thanks for this impl! finishing some stuff on the rpc side and I'll deep dive here 👍

[antiyro]

Reviewing it now, my apologies for the delays I've been busy bumping madara specs.

[antiyro]

@jerrybaoo could you please sync with upstream when you have time so I can test it locally?

[OmniaFlux]

@jerrybaoo could you please sync with upstream when you have time so I can test it locally?

Okay, I'll start syncing with upstream now.

[antiyro]

Thanks!

[OmniaFlux]

Thanks!

Sync with upstream has been completed. Additionally, we have a quick start guide that we hope will be helpful to you. Alternatively, we can include it in the Readme.

[github-actions[bot]]

There hasn't been any activity on this pull request recently, and in order to prioritize active work, it has been marked as stale. This PR will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[tdelabro]

repository archived in favor of https://github.com/madara-alliance/madara