Full Node Sync

[ChiHaoLu]

Hi, I have some questions about the full node in StarkNet. We can observe that a Full Node can synchronize its state from three sources: the Sequencer, P2P (other Full Nodes), and Ethereum. If the contents of these three sources differ, how would a Full Node decide the current state?

Based on my understanding:

1. When a Full Node synchronizes a new transaction pending from the Sequencer, it adds this new transaction to the Pending state.
2. Once the Sequencer successfully executes the transaction and obtains the state_diff, the transaction enters the Accepted on Layer2 state. At this point, the new state will be updated in the Local DB of the running Node.
3. After the Layer1 Core (Rollup) Contract updates the state_diff, the transaction enters the Accepted on Layer1 state.

To delve deeper into the three sync data methods, they represent different implications:

• Requesting data from the Sequencer Gateway is the first step to obtain the current transaction data, which means acquiring the "most recent state (block)" on Layer2.
• Requesting data from Ethereum and performing verification is done to ensure the accuracy of the final data, which means obtaining the "latest confirmed Layer2 state (block)" on Layer1.
• Conducting P2P sync with other Layer2 Full Nodes is aimed at expediting the synchronization process of historical data and ensuring network consistency.

I believe there might be inaccuracies in my description, and I'm unsure about the correct approach. I would appreciate it if you could correct my description. Thank you very much!

[Mirko-von-Leipzig]

To delve deeper into the three sync data methods, they represent different implications:

• Requesting data from the Sequencer Gateway is the first step to obtain the current transaction data, which means acquiring the "most recent state (block)" on Layer2.
• Requesting data from Ethereum and performing verification is done to ensure the accuracy of the final data, which means obtaining the "latest confirmed Layer2 state (block)" on Layer1.
• Conducting P2P sync with other Layer2 Full Nodes is aimed at expediting the synchronization process of historical data and ensuring network consistency.

This is mostly correct, except that at the moment, all full nodes exclusively use the gateway for block and tx information, and don't use p2p yet - p2p is currently being worked on.

The current goal for p2p is to dramatically improve sync times for nodes, and to reduce the load on the gateway. A seconday goal is to pave the way for starknet decentralization - where there will be a subnetwork of sequencers and provers working to produce and share new block information. How exactly this will interlace with full nodes and p2p is as yet undecided, as it will largely depend on how consensus works.

The starknet L1 contract is used by full nodes to mark blocks / data as L1 accepted or not. If there is ever a difference between L1 and the data provided by the gateway / p2p then the full node has a difficult decision to make. Does it only follow L1 information? This isn't really viable as there is a lot of data that L1 does not contain, like transactions, classes, contracts and block headers - L1 only contains the state data. Further, it is always possible for there to be a reorg on L1 or L2 which will then re-align the data so it becomes difficult to be certain exactly.

What we do in pathfinder is just track the latest point at which L1 agrees with the data and mark it. Whenever there is an update to L1 or L2 data we update this point.

We can observe that a Full Node can synchronize its state from three sources: the Sequencer, P2P (other Full Nodes), and Ethereum. If the contents of these three sources differ, how would a Full Node decide the current state?

If the contents from the sequencer and p2p differ, then currently the full node should choose the sequencer data as it is (currently) the sole source of data. However, this will change once there are multiple sequencers at which point it depends on the consensus algorithm which is still being designed afaik.

If the contents of L1 and L2 differ, then as mentioned previously, the node needs to decide how it wants to handle that. In pathfinder we just mark data as L1 accepted or L2 accepted, because we cannot get any extra information from L1 to replace the L2 data. So we may as well just wait and see what happens when new information arrives.

1. When a Full Node synchronizes a new transaction pending from the Sequencer, it adds this new transaction to the Pending state.
2. Once the Sequencer successfully executes the transaction and obtains the state_diff, the transaction enters the Accepted on Layer2 state. At this point, the new state will be updated in the Local DB of the running Node.
3. After the Layer1 Core (Rollup) Contract updates the state_diff, the transaction enters the Accepted on Layer1 state.

Yes, this is correct.

The full node doesn't specifically interact with transactions, it requests entire blocks from the sequencer gateway. For pending information, the gateway provides the pending block information which is basically the current block it is building. Currently, transactions included in this block are marked as pending however they technically are already L2 accepted and I think this is a change that is happening in starknet v0.12.

The full node periodically polls the gateway for this pending block information, and updates its local state based on that. At some point this pending block becomes the next full block and pathfinder updates its state to match this with L2 accepted. And then as you say, once the L1 contract updates, the block and its contents (i.e. transactions) are also marked as L1 accepted.

I hope this answers your questions, but feel free to ask more if anything is unclear.

[ChiHaoLu]

Your answer is fantastic, very thanks to your reply!!

[Mirko-von-Leipzig]

No problem, happy to answer!

[gorbunova13]

thank u!