Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP-2935: Historical Block Hashes from State #510

Closed
refcell opened this issue Jan 15, 2025 · 7 comments · Fixed by #526
Closed

EIP-2935: Historical Block Hashes from State #510

refcell opened this issue Jan 15, 2025 · 7 comments · Fixed by #526
Labels
A-execution Area: execution layer A-prover A: fault prover H-pectra Hardfork: change planned for Pectra (L1) upgrade U-node Upgrade: involving changes to node component (cl, el, etc.) U-smart-contract Upgrade: involving changes to smart contracts

Comments

@refcell
Copy link
Contributor

refcell commented Jan 15, 2025

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
  • EIP-2935 can be used as a drop-in-place replacement for the header accumulator.
  • Upgrade Tx needs the same sender as the pre-determined example tx to ensure the contract is deployed.

References

@refcell refcell added the H-pectra Hardfork: change planned for Pectra (L1) upgrade label Jan 15, 2025
@emhane emhane added U-smart-contract Upgrade: involving changes to smart contracts U-node Upgrade: involving changes to node component (cl, el, etc.) A-kona labels Jan 15, 2025
@emhane emhane mentioned this issue Jan 16, 2025
1 task
@emhane emhane added A-execution Area: execution layer A-prover A: fault prover and removed A-kona labels Jan 16, 2025
@emhane
Copy link
Member

emhane commented Jan 17, 2025

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
Copy link
Contributor

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
Copy link
Member

emhane commented Jan 17, 2025

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

@ajsutton
Copy link
Contributor

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
Copy link
Member

emhane commented Jan 17, 2025

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
Copy link
Contributor

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-execution Area: execution layer A-prover A: fault prover H-pectra Hardfork: change planned for Pectra (L1) upgrade U-node Upgrade: involving changes to node component (cl, el, etc.) U-smart-contract Upgrade: involving changes to smart contracts
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants