Verification

Starknet is a layer 2 solution that inherits security from Ethereum, meaning that its state can be reconstructed using Ethereum's data. Specifically, the Sequencer responsible for constructing Starknet's state sends it to the SNOS (Starknet OS), which then sends the corresponding execution trace to the Prover. The state diff and the generated proof are then sent to the DA layer (in this case, Ethereum) making it possible to verify the integrity of the Starknet state via the Layer 1.

Verification methods

Currently, there are primarily three methods for a node to keep track of the network’s state, and nodes can implement any of these methods:

• Replaying Old Transactions: Similar to Ethereum or Bitcoin, a node can replay all transactions and re-execute them. While this method is accurate, it is not scalable unless you have a powerful machine capable of handling the load. If you can replay all transactions, you can become a sequencer.

• Relying on L2 Consensus: Nodes can trust the sequencer to execute the network correctly. When the sequencer updates the state and adds a new block, nodes accept the update as accurate.

• Checking Proof Validation on L1: Nodes can monitor the state of the network by observing L1 and ensuring that every time a proof is sent, they receive the updated state. This approach does not require trusting anyone and only necessitates keeping track of the latest valid transaction for Starknet.

Each type of node setup comes with its own set of hardware requirements and trust assumptions. For Madara we decided to check the proof validation on the L1 as it is the fastest and less intensive way of verifying the state integrity.

Full node client verification

Nodes that verify state based on L1 proof validations require similar resources to Ethereum nodes, offering simplicity and mobility with the tradeoff of higher latency due to intermittent proof submissions, although plans to increase proof frequency aim to reduce this latency.

On Ethereum, there is currently a contract named Starknet Core Contract (opens in a new tab) written in Solidity and deployed by Starkware. This contract acts as a proxy for various contracts hosted on Layer 1. It periodically emits an event with a regular interval between 2 to 7 hours of latency:

This event provides three pieces of information:

• stateBlockHash: Corresponds to the last verified block hash on L1.
• stateBlockNumber: Corresponds to the last verified block number on L1.
• stateRoot: Corresponds to the state root at the height of the last verified block number on L1.

Madara then subscribes to this event and continuously monitors the updates to verify if the reported values match the data calculated during synchronization. If they do match, it confirms that the state is intact.

Layer 1 Access

As described above, Madara requires an L1 RPC key to continuously listen to Layer 1. This key can be obtained from a centralized RPC provider or a personal Ethereum RPC access. Below is a non-exhaustive list of Ethereum RPC providers and full node clients:

You just need to provide the RPC URL in the format http, https, ws, or wss as an argument, and Madara will take care of communicating with it. Here is an example tutorial on how to retrieve an L1 key via Alchemy: