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

Isthumus: Spec updates for L2 withdrawals-root in block header #394

Closed
12 tasks done
vdamle opened this issue Sep 27, 2024 · 1 comment · Fixed by #396
Closed
12 tasks done

Isthumus: Spec updates for L2 withdrawals-root in block header #394

vdamle opened this issue Sep 27, 2024 · 1 comment · Fixed by #396
Assignees

Comments

@vdamle
Copy link
Contributor

vdamle commented Sep 27, 2024

Peeling off the work associated with updating specs mentioned in: ethereum-optimism/optimism#12044

General notes: keep the specs categorized in the isthumus directory, and file names consistent across upgrades:
e.g. Execution layer changes go exec-engine.md.

  • Specs note that the block-body withdrawals list is encoded as an empty RLP list.
  • Specs note that any block-after-transaction simulation should include an empty withdrawals-root;
    the block is sealed at the end of a block.
  • Specs note that the withdrawals-root in the genesis block,
    if Isthumus is active, is always the empty withdrawals root, regardless of L2 state.
  • Specs note that the withdrawals-root starting at shanghai, pre-Isthumus,
    is set to an empty withdrawals list, this equals the same root as an empty storage root.
    The withdrawals are there in L2 state, just not elevated into the withdrawals-root.
    Pre-Isthumus output-root construction should be careful not to use the header withdrawals-root.
  • Specs note that at the time of state-processing, with an in-progress header,
    the withdrawals-root should not be available to the EVM / application layer.
  • Specs Engine-API modification: ExecutableData gets a withdrawalsRoot attribute.
  • Specs note that for an accurate storage-root to be known,
    the block state has to be committed first, before the withdrawals storage root can be set accurately.
    This attribute should thus be set right after setting the state-root attribute of the header.
  • Specs EL P2P note: block-bodies and block-headerts responses are handled the same in isolation:
    we compute the body-withdrawal-hashes from the received withdrawals list in the block body.
    Then, when we compare the body-withdrawal-hashes to the header withdrawal-hashes,
    and if optimism Isthumus is active for the given header, we check if the body-withdrawal-hash matches the empty list root,
    while allowing the header-withdrawal-hash to be any non-null value.
    By verifying at this later stage, we have the header timestamp, and can apply the fork logic conditionally.
  • Specs update to describe CL ExecutionPayload SSZ encoding with new withdrawals-root included.
    • [ ] We remove the withdrawals list from the encoding, diverging from the L1 beacon-chain ExecutionPayload encoding.
  • Spec that we continue to use engine_newPayloadV3 engine-API,
    but now with the additional ExecutionPayload attribute, that is omitted pre-Isthumus.
  • Specs update to describe new CL P2P gossip topic, with updated ExecutionPayload SSZ encoding,
    and a gossip-validation rule that checks if the withdrawals root is non-nil, and withdrawals list is empty.
    This spec change goes into the main rollup-node-p2p.md, to be consistent with the other gossip topics.
  • Update fault-proof-program spec that describes the output-claim verification,
    and link to the Isthumus specs change of the block header.
@vdamle vdamle self-assigned this Sep 27, 2024
@sebastianst sebastianst moved this to In Progress in OP Stack Upgrades Oct 1, 2024
@vdamle vdamle changed the title Holocene: Spec updates for L2 withdrawals-root in block header Isthumus: Spec updates for L2 withdrawals-root in block header Oct 7, 2024
@vdamle
Copy link
Contributor Author

vdamle commented Oct 7, 2024

Updated references Holocene -> Isthumus

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants