EIP-2935: Historical Block Hashes from State

[refcell]

Description

EIP-2935 serves historical block hashes from state. Effectively a new contract is deployed to track the previous 8192 block hashes.

This EIP:

• Replaces the header accumulator proposal made by @clabby
  • Header Accumulator #259
• EIP-2935 can be used as a drop-in-place replacement for the header accumulator.
  • Whereas header accumulator is log(n) lookup time, there are 8191 block hashes in the service window so the lookup is a sliding 8191 window of block hashes.
  • EIP-2935 requires an upgrade transaction in kona’s L2 stateless block executor.
  • https://github.com/op-rs/kona/blob/main/crates/executor/src/executor/mod.rs#L122-L130
  • op-reth will need an upgrade transaction as well.
• Upgrade Tx needs the same sender as the pre-determined example tx to ensure the contract is deployed.

References

• Pectra Devnet 5 EIP List
• Proto's list of Pectra EIPs
• Pectra support on the OP Stack tracking issue: [Tracker] OP Stack: Support Pectra (Upgrade 14) optimism#12435

[emhane]

does this require a noop spec if the feature is not implemented for use in isthmus, or will nothing break if it is skipped @protolambda ?

[ajsutton]

We would need to have the enabled on L2s for interop, so I would expect it would be implemented and enabled as part of supporting Pectra in OP Stack (but not needed as part of making OP Stack work when pectra is enabled on the L1).

[emhane]

ok thanks @ajsutton , so it doesn't require any action if not included in isthmus because lack of time, capisci

[ajsutton]

Is Isthmus activating pectra on L2? We aren't picking and choosing bits of pectra to enable other than where things just don't apply. But for things that make sense on L2 we are either activating all of pectra or none of it.

[emhane]

I thought there would just be one hard fork called isthmus, but I'm also the completely wrong person to ask. I think some Pectra issues have to be addressed to ensure nothing breaks when l1 forks, see issues labelled noop.

[ajsutton]

Yeah there are two parts to "supporting pectra". The highest priority is making sure that pectra can be enabled on the L1 and not have things break - that's the stuff around how to parse new transaction types.

The other part is actually enabling pectra on the L2 chain. That will be done in a future hard fork - possibly Isthmus but it depends when it's actually ready. We "include" L1 hard forks in an L2 hard fork which in terms of the geth config means you'd have isthmus_timestamp and pectra_timestamp set to the same time. But which L2 hard fork that happens in isn't set because we're trying to use a model where we decide what goes into a L2 hard fork based on what's ready vs deciding ahead of time what goes into the hard fork and rushing to have it ready in time.

[protolambda]

With the beacon-root history accumulator contract in the previous L1 upgrade, very similar to the new block-hash accumulator contract, we used a trick with deposits to deploy the contract automatically as part of the upgrade, in case it's not already permissionlessly deployed. I would strongly recommend we do the same type of thing this upgrade.

And then as @ajsutton said, if the pectra functionality is properly enabled as part of the L2 upgrade, then the block-hashes will be applied to the block-hash contract as expected.