Initial Accumulation Event
Between September and October of 2023, we completed what is known as the Initial Block Hash Accumulation Event.
The purpose of this one-time event was to generate the initial keccak256 and poseidon Merkle Mountain Ranges(MMRs) containing only provably valid Ethereum blocks starting from block 18120280 to the genesis block.
Think of the blockchain as a linked list: each block is tied to its predecessor through the parentHash in its header. By starting with a known, authenticated block hash and tracing the chain backwards using these parentHash links, we can reliably access the header of any block, even those deep in the past.
Going through this process each time we wanted to access historical data would be very expensive and inefficient. This is precisely why we employ accumulators. Using MMR accumulators ensures that we undertake this process only once.
Workflow
In order to generate the two MMRs, we have taken the following actions:
1. Creation of a new accumulator.
We have achieved that by invoking the method createAggregator from the AggregatorsFactory.sol contract. Invoking this method creates a new instance of a SharpFactsAggregator.
2. Blockhash snapshot and new range registration
The next step is to, within an instance of the SharpFactsAggregator take a snapshot of a reorg safe blockhash from which the backward iteration through the chain of headers will start. This process is also called new range registration.
3. Individual STARK-proof generation
Each execution of the Cairo0 program responsible for growing the MMRs will generate a .pie object. Such objects are then sent to the SHARP as jobs.
To learn more about SHARP facts and jobs, please see.
The SHARP internally for each job will generate a STARK proof. However, it is important to note that such STARK proof will never directly land on-chain.
4. Combine individual proofs into trains
The SHARP then aggregates such individual proofs into trains.
A train is a set of individual STARK proofs verified together by a dedicated cairo program, forming a final STARK proof combining multiple individual proofs.
Trains are formed when:
The maximum limit of 128 jobs per train has been reached.
OR
A certain amount(depending on the prover configuration) of time passes without a full train being formed.
5. Post trains on-chain and register facts
The process of verifying a STARK proof is a multistep process, mostly due to the calldata size constraints on Ethereum L1.
The steps are:
Merkle statements registration.
FRI verification.
Facts registration.
Final proof verification and facts authentication.
6. Aggregate the facts
Once all the proofs in a train are finalized on-chain and the corresponding facts are registered, we need to aggregate all the facts.
These facts need to be consumed and aggregated by the Aggregator contract.
Each registered fact attests to the validity of a state transition. Such state transitions need to be aggregated in the right order.
Relevant Smart Contracts
Security Audit: ABDK has audited the Cairo0 program and Solidity verifiers. The full audit report can be found here.
The two smart contracts that manage the growth and creation of the poseidon(Starkware's poseidon) and keccak256 MMRs are:
Additional Resources
Herodotus: Proving Ethereum’s State Using Storage Proofs on Starknet
Last updated
