Initial Accumulation Event
Last updated
Last updated
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.
In order to generate the two MMRs, we have taken the following actions:
We have achieved that by invoking the method createAggregator from the AggregatorsFactory.sol contract. Invoking this method creates a new instance of a SharpFactsAggregator.
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.
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.
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.
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.
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.
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:
Herodotus: Proving Ethereum’s State Using Storage Proofs on Starknet
