From f3cf025c6c75b1ca45f744d8030b4486d575028f Mon Sep 17 00:00:00 2001 From: Mark Tyneway Date: Mon, 16 Sep 2024 18:22:45 -0600 Subject: [PATCH 1/2] holocene: execution engine page Rebased version of https://github.com/ethereum-optimism/specs/pull/177 There is consensus that this is to be included in holocene Co-authored-by: clabby --- specs/protocol/holocene/exec-engine.md | 75 ++++++++++++++++++++++++++ specs/protocol/holocene/overview.md | 4 +- 2 files changed, 77 insertions(+), 2 deletions(-) create mode 100644 specs/protocol/holocene/exec-engine.md diff --git a/specs/protocol/holocene/exec-engine.md b/specs/protocol/holocene/exec-engine.md new file mode 100644 index 000000000..7db5ef9b2 --- /dev/null +++ b/specs/protocol/holocene/exec-engine.md @@ -0,0 +1,75 @@ +# L2 Execution Engine + + + +**Table of Contents** + +- [`L2ToL1MessagePasser` Storage Root in Header](#l2tol1messagepasser-storage-root-in-header) + - [Timestamp Activation](#timestamp-activation) + - [Header Validity Rules](#header-validity-rules) + - [Header Withdrawals Root](#header-withdrawals-root) + - [Rationale](#rationale) + - [Forwards Compatibility Considerations](#forwards-compatibility-considerations) + - [Client Implementation Considerations](#client-implementation-considerations) + + + +## `L2ToL1MessagePasser` Storage Root in Header + +After the Granite hardfork's activation, the L2 block header's `withdrawalsRoot` field will consist of the 32-byte +[`L2ToL1MessagePasser`][l2-to-l1-mp] account storage root _after_ the block has been executed. + +### Timestamp Activation + +Granite, like other network upgrades, is activated at a timestamp. +Changes to the L2 Block execution rules are applied when the `L2 Timestamp >= activation time`. +Changes to the L2 block header are applied when it is considering data from a L1 Block whose timestamp +is greater than or equal to the activation timestamp. + +### Header Validity Rules + +Prior to Granite activation, the L2 block header's `withdrawalsRoot` field must be: + +- `nil` if Canyon has not been activated. +- `keccak256(rlp(empty_string_code))` if Canyon has been activated. + +After Granite activation, an L2 block header's `withdrawalsRoot` field is valid iff: + +1. It is exactly 32 bytes in length. +1. The [`L2ToL1MessagePasser`][l2-to-l1-mp] account storage root, as committed to in the `storageRoot` within the block + header, is equal to the header's `withdrawalsRoot` field. + +### Header Withdrawals Root + +| Byte offset | Description | +| ----------- | --------------------------------------------------------- | +| `[0, 32)` | [`L2ToL1MessagePasser`][l2-to-l1-mp] account storage root | + +#### Rationale + +Currently, to generate [L2 output roots][output-root] for historical blocks, an archival node is required. This directly +places a burden on users of the system in a post-fault-proofs world, where: + +1. A proposer must have an archive node to propose an output root at the safe head. +1. A user that is proving their withdrawal must have an archive node to verify that the output root they are proving + their withdrawal against is indeed valid and included within the safe chain. + +Placing the [`L2ToL1MessagePasser`][l2-to-l1-mp] account storage root in the `withdrawalsRoot` field alleviates this burden +for users and protocol participants alike, allowing them to propose and verify other proposals with lower operating costs. + +#### Forwards Compatibility Considerations + +As it stands, the `withdrawalsRoot` field is unused within the OP Stack's header consensus format, and will never be +used for other reasons that are currently planned. Setting this value to the account storage root of the withdrawal +directly fits with the OP Stack, and makes use of the existing field in the L1 header consensus format. + +#### Client Implementation Considerations + +Varous EL clients store historical state of accounts differently. If, as a contrived case, an OP Stack chain did not have +an outbound withdrawal for a long period of time, the node may not have access to the account storage root of the +[`L2ToL1MessagePasser`][l2-to-l1-mp]. In this case, the client would be unable to keep consensus. However, most modern +clients are able to at the very least reconstruct the account storage root at a given block on the fly if it does not +directly store this information. + +[l2-to-l1-mp]: ../protocol/predeploys.md#L2ToL1MessagePasser +[output-root]: ../glossary.md#l2-output-root diff --git a/specs/protocol/holocene/overview.md b/specs/protocol/holocene/overview.md index 568348754..28ab76bc7 100644 --- a/specs/protocol/holocene/overview.md +++ b/specs/protocol/holocene/overview.md @@ -14,8 +14,8 @@ This document is not finalized and should be considered experimental. ## Execution Layer -## Consensus Layer +- [L2ToL1MessagePasser Storage Root in Header](./exec-engine.md##l2tol1messagepasser-storage-root-in-header) -- [Interop](../interop/overview.md) +## Consensus Layer ## Smart Contracts From 7dcaffd4a30c2b77cb419da30848e331e6c3793d Mon Sep 17 00:00:00 2001 From: Mark Tyneway Date: Mon, 16 Sep 2024 18:27:37 -0600 Subject: [PATCH 2/2] specs: replace granite with holocene --- specs/protocol/holocene/exec-engine.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/specs/protocol/holocene/exec-engine.md b/specs/protocol/holocene/exec-engine.md index 7db5ef9b2..73ca23bca 100644 --- a/specs/protocol/holocene/exec-engine.md +++ b/specs/protocol/holocene/exec-engine.md @@ -16,24 +16,24 @@ ## `L2ToL1MessagePasser` Storage Root in Header -After the Granite hardfork's activation, the L2 block header's `withdrawalsRoot` field will consist of the 32-byte +After the Holocene hardfork's activation, the L2 block header's `withdrawalsRoot` field will consist of the 32-byte [`L2ToL1MessagePasser`][l2-to-l1-mp] account storage root _after_ the block has been executed. ### Timestamp Activation -Granite, like other network upgrades, is activated at a timestamp. +Holocene, like other network upgrades, is activated at a timestamp. Changes to the L2 Block execution rules are applied when the `L2 Timestamp >= activation time`. Changes to the L2 block header are applied when it is considering data from a L1 Block whose timestamp is greater than or equal to the activation timestamp. ### Header Validity Rules -Prior to Granite activation, the L2 block header's `withdrawalsRoot` field must be: +Prior to holocene activation, the L2 block header's `withdrawalsRoot` field must be: - `nil` if Canyon has not been activated. - `keccak256(rlp(empty_string_code))` if Canyon has been activated. -After Granite activation, an L2 block header's `withdrawalsRoot` field is valid iff: +After Holocene activation, an L2 block header's `withdrawalsRoot` field is valid iff: 1. It is exactly 32 bytes in length. 1. The [`L2ToL1MessagePasser`][l2-to-l1-mp] account storage root, as committed to in the `storageRoot` within the block