ethereum-optimism
Isthmus: Header Accumulator
Overview
Specifies an addition to block execution in the Isthmus hardfork, which designates "header accumulation" blocks and an addition to the extraData field in "header accumulation" blocks' headers to enable this functionality.
TODO
- [x] Explicit block validity rules.
Possible Ideas
- [✅] Rather than the receipts batches, why not store header batches? Could be useful for efficient historical state lookups, i.e. in the fault proof program. No less efficient to store the broader commitment, either. h/t @protolambda
- #177
- #259 👈 (View in Graphite)
main
This stack of pull requests is managed by Graphite. Learn more about stacking.
@axelKingsley
My other question is around the selection of the Merkle Tree. Seems a good choice for compact storage, but this doc also points out that it only requires two merkle proofs as well as n merkle patricia trie proofs to verify inclusion. This seems like an important feature, but I don't fully understand how that mechanism is used by nodes to achieve the goal of only a single L2 block at a height that includes all receipts on a single chain that must be validated to resolve its dependents. Would you mind sketching that out a bit? This could be something very obvious to folks more familiar with Merkle Tree than I am.
This choice was made to allow for efficient batching of data, and to reduce historical state expansion. By splitting the incremental tree, and including batch roots as leaves, we have a very nice property where only every HEADER_BATCH_SIZE blocks, we include a new merkle stack. In addition, we also reduce the size of the merkle stack in the extraData field by 5 * 20 bytes for every "accumulation block" (block.number % HEADER_BATCH_SIZE == 0), saving quite a bit of storage costs over time.
As agreed on the ENG staff meeting, I'm assigning this to @protolambda as lead implementer that will own this side of work for Granite hardfork.
closing until further notice since is superseded by https://github.com/ethereum-optimism/specs/issues/510, will re-open if eip-2935 doesn't deliver satisfactory performance improvements
