There are currently two methods to synchronize with the StarkNet chain (i.e., download, hold, and update the StarkNet state):
- The StarkWare feeder gateway (a centralized API provided by StarkWare) or
- The Layer 1 StarkNet contracts on the Ethereum chain (these contracts hold the StarkNet data on-chain, providing data availability).
The syncing process with the feeder gateway is relatively simple: request a state update from the API like this and apply that state update to the local database.
Layer 1 Syncing
Syncing with the L1 contracts is more complicated. To do this, we listen for events emitted by the contracts to reconstruct the StarkNet state update.
The three key StarkNet contracts on L1 that we are interested in are:
- MemoryPageFactRegistry: stores a mapping between a fact (a hash of some data) and a memory page hash.
This contract has an external function
registerMemoryPageContinuousthat accepts memory pages as input (data structure that contains L2 transaction data). When it receives a new valid memory page, the
LogMemoryPageFactContinuousevent is emitted with the hash of the registered memory page.
- GpsStatementVerifier: verifies proofs from layer 2.
When this contract verifies a proof, it emits a
LogMemoryPagesHashesevent, which contains a fact (hash of data used in the verification process) and an array of memory page hashes.
- Starknet: transitions the StarkNet state.
LogStateTransitionFactevent with a fact corresponding to the state transition being processed. Once it completes additional safety checks, it will officially transition the state and emit a
LogStateUpdateevent with the new state root and Starknet block number (sequence number).
When syncing against L1, we need to work backwards through the above steps to reconstruct the original state update.
Since we cannot rely on receiving the events in chronological order, we hold three mappings to keep the information straight (one for each contract):
- memoryPage: memoryPageHash -> hash of the Ethereum transaction where the
LogMemoryPageFactContinuousevent was emitted.
- gpsVerifier: fact1 -> list of memory page hashes
- facts: sequence number -> fact (this fact is from
LogStateTransitionFact, sequence number is from
To sync, we follow these steps:
- Once we see a
LogStateTransitionFactevent, we look for a
LogStateUpdatein the same Ethereum block. If found, we add it to the third mapping above. If the sequence number (StarkNet block number) is one greater than the latest sequence number of the last block we synced, we begin processing the state update.
- Use the fact from the
LogStateTransitionFactevent to get the list of corresponding memory page hashes from the gpsVerifier mapping.
- For each memory page hash, use the memoryPage mapping to find the hash of the transaction where the memory page data was sent.
- Query an Ethereum node for the actual transaction using the transaction hash.
- Parse the Ethereum transaction calldata to reconstruct the StarkNet state update.
- StarkNet State - layout of the StarkNet state trie
- Fact registry design - the reasoning behind the StarkNet L1 contract architecture
- StarkEx contracts on GitHub - contain initial implementations of the MemoryPageFactRegistry and GpsStatementVerifier contracts for StarkEx
- StarkNet contract on Goerli (may be out of date by the time you're reading this)
- Cairo white paper - useful background knowledge to have while reading the above contracts