From ed6c7ab2126718281b0180298eb12af2cc4c2e17 Mon Sep 17 00:00:00 2001 From: Sebastian Stammler Date: Thu, 16 Jan 2025 22:02:35 +0100 Subject: [PATCH 1/6] specs: Specify derivation of future tx types --- specs/protocol/derivation.md | 9 +++++++++ specs/protocol/system-config.md | 6 ++++++ 2 files changed, 15 insertions(+) diff --git a/specs/protocol/derivation.md b/specs/protocol/derivation.md index 02d97daa4..26bb9faff 100644 --- a/specs/protocol/derivation.md +++ b/specs/protocol/derivation.md @@ -499,6 +499,9 @@ transaction is one with the following properties: - The [`to`] field is equal to the configured batcher inbox address. +- The transaction type is one of `0`, `1`, `2`, `3`, or `0x7e` (L2 [Deposited transaction type][g-deposit-tx-type], to + support force-inclusion of batcher transactions on nested OP Stack chains). + - The sender, as recovered from the transaction signature (`v`, `r`, and `s`), is the batcher address loaded from the system config matching the L1 block of the data. @@ -1014,6 +1017,12 @@ entries. [deposit-contract-spec]: deposits.md#deposit-contract +Logs for all transaction types are parsed for deposits, also from possibly unknown transactions types like those that +are considered invalid batcher transaction types, see [L1 Retrieval][#l1-retrieval]. However, they are parsed as if they +were receipts for one of the known transactions types `0`, `1`, `2`, `3`, `4` and `0x7e`. If they fail this best-effort +decoding process, they are dropped and considered invalid. +The intention of this best-effort decoding is to future-proof the protocol for new L1 transaction types. + ### Network upgrade automation transactions [network upgrade automation transactions]: #network-upgrade-automation-transactions diff --git a/specs/protocol/system-config.md b/specs/protocol/system-config.md index 3db9be2d0..5ef7711fd 100644 --- a/specs/protocol/system-config.md +++ b/specs/protocol/system-config.md @@ -163,3 +163,9 @@ The contained log events are filtered and processed as follows: Note that individual derivation stages may be processing different L1 blocks, and should thus maintain individual system configuration copies, and apply the event-based changes as the stage traverses to the next L1 block. + +Logs for all transaction types are parsed for `SystemConfig` events, also from possibly unknown transactions types like +those that are considered invalid batcher transaction types, see [L1 Retrieval][derivation.md#l1-retrieval]. However, +they are parsed as if they were receipts for one of the known transactions types `0`, `1`, `2`, `3`, `4` and `0x7e`. If +they fail this best-effort decoding process, they are dropped and considered invalid. +The intention of this best-effort decoding is to future-proof the protocol for new L1 transaction types. From 75ef38a359433b4daf5e72b1f9d68280481c8d0c Mon Sep 17 00:00:00 2001 From: Sebastian Stammler Date: Fri, 17 Jan 2025 15:40:09 +0100 Subject: [PATCH 2/6] rewrite --- specs/protocol/derivation.md | 33 ++++++++++++++++++++++++++++----- specs/protocol/system-config.md | 9 +++------ 2 files changed, 31 insertions(+), 11 deletions(-) diff --git a/specs/protocol/derivation.md b/specs/protocol/derivation.md index 26bb9faff..28e3cb9d8 100644 --- a/specs/protocol/derivation.md +++ b/specs/protocol/derivation.md @@ -1017,11 +1017,8 @@ entries. [deposit-contract-spec]: deposits.md#deposit-contract -Logs for all transaction types are parsed for deposits, also from possibly unknown transactions types like those that -are considered invalid batcher transaction types, see [L1 Retrieval][#l1-retrieval]. However, they are parsed as if they -were receipts for one of the known transactions types `0`, `1`, `2`, `3`, `4` and `0x7e`. If they fail this best-effort -decoding process, they are dropped and considered invalid. -The intention of this best-effort decoding is to future-proof the protocol for new L1 transaction types. +Logs are derived from transactions following the future-proof best-effort process described in +[On Future-Proof Transaction Log Derivation][#on-future-proof-transaction-log-derivation] ### Network upgrade automation transactions @@ -1287,3 +1284,29 @@ follows: [extended-attributes]: exec-engine.md#extended-payloadattributesv1 [Fee Vaults]: exec-engine.md#fee-vaults + +## On Future-Proof Transaction Log Derivation + +As described in [L1 Retrieval][#l1-retrieval], batcher transactions' types are required to be from a fixed allow-list. + +However, we want to allow deposit transactions and `SystemConfig` update events to get derived even from receipts of +future transaction types, as long as the receipts can be decoded following a best-effort process: + +As long as a future transaction type follows the [EIP-2718][https://eips.ethereum.org/EIPS/eip-2718] specification, +the type can be decoded as the first byte of an encoded transaction or receipt (excluding legacy transactions, which are +not _future_ transactions). We can then proceed as follows to get the logs of such a future transaction, or discard the +transaction's receipt as invalid. + +- If it's a known transaction type, that is, legacy (first byte of the encoding is in the range `[0xc0, 0xfe]`) or its +first byte is in the range `[0, 4]`, then it's not a _future transaction_ and we know how to decode the receipt and this +process is irrelevant. +- If a transaction's first byte is in the range `[5, 0x7f]`, it is expected to be a _future_ EIP-2718 transaction, so we can +proceed to the receipt. +- The receipt encoding's first byte must be the same byte as the transaction encoding's first byte, or it is discarded +as invalid. +- The receipt payload is decoded as if it is encoded as `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`, +which is the encoding of the known non-legacy transaction types. + - If this decoding fails, the transaction's receipt is discarded as invalid. + - If this decoding succeeds, the `logs` have been obtained and can be processed as those of known transaction types. + +The intention of this best-effort decoding process is to future-proof the protocol for new L1 transaction types. diff --git a/specs/protocol/system-config.md b/specs/protocol/system-config.md index 5ef7711fd..558fceda7 100644 --- a/specs/protocol/system-config.md +++ b/specs/protocol/system-config.md @@ -144,6 +144,9 @@ A rollup node initializes its derivation process by finding a starting point bas After preparing the initial system configuration for the given L1 starting input, the system configuration is updated by processing all receipts from each new L1 block. +Logs are derived from transactions following the future-proof best-effort process described in +[On Future-Proof Transaction Log Derivation][derivation.md#on-future-proof-transaction-log-derivation] + The contained log events are filtered and processed as follows: - the log event contract address must match the rollup `SystemConfig` deployment @@ -163,9 +166,3 @@ The contained log events are filtered and processed as follows: Note that individual derivation stages may be processing different L1 blocks, and should thus maintain individual system configuration copies, and apply the event-based changes as the stage traverses to the next L1 block. - -Logs for all transaction types are parsed for `SystemConfig` events, also from possibly unknown transactions types like -those that are considered invalid batcher transaction types, see [L1 Retrieval][derivation.md#l1-retrieval]. However, -they are parsed as if they were receipts for one of the known transactions types `0`, `1`, `2`, `3`, `4` and `0x7e`. If -they fail this best-effort decoding process, they are dropped and considered invalid. -The intention of this best-effort decoding is to future-proof the protocol for new L1 transaction types. From 88fab03efaf437cf6d1eed13c0207072f62695a3 Mon Sep 17 00:00:00 2001 From: Sebastian Stammler Date: Fri, 17 Jan 2025 17:26:15 +0100 Subject: [PATCH 3/6] clarify --- specs/protocol/derivation.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/specs/protocol/derivation.md b/specs/protocol/derivation.md index 28e3cb9d8..1c7a0877a 100644 --- a/specs/protocol/derivation.md +++ b/specs/protocol/derivation.md @@ -1298,12 +1298,12 @@ not _future_ transactions). We can then proceed as follows to get the logs of su transaction's receipt as invalid. - If it's a known transaction type, that is, legacy (first byte of the encoding is in the range `[0xc0, 0xfe]`) or its -first byte is in the range `[0, 4]`, then it's not a _future transaction_ and we know how to decode the receipt and this -process is irrelevant. -- If a transaction's first byte is in the range `[5, 0x7f]`, it is expected to be a _future_ EIP-2718 transaction, so we can -proceed to the receipt. -- The receipt encoding's first byte must be the same byte as the transaction encoding's first byte, or it is discarded -as invalid. +first byte is in the range `[0, 4]` or `0x7e` (_deposited_), then it's not a _future transaction_ and we know how to +decode the receipt and this process is irrelevant. +- If a transaction's first byte is in the range `[5, 0x7d]`, it is expected to be a _future_ EIP-2718 transaction, so we can +proceed to the receipt. Note that we excluded `0x7e` because that's the deposit transaction type, which is known. +- The _future_ receipt encoding's first byte must be the same byte as the transaction encoding's first byte, or it is discarded +as invalid, because we require it to be an EIP-2718-encoded receipt to continue. - The receipt payload is decoded as if it is encoded as `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`, which is the encoding of the known non-legacy transaction types. - If this decoding fails, the transaction's receipt is discarded as invalid. From 34d334a26ca9c4b559cadabdb3711307e2f8f128 Mon Sep 17 00:00:00 2001 From: Sebastian Stammler Date: Fri, 17 Jan 2025 17:46:06 +0100 Subject: [PATCH 4/6] lint --- specs/protocol/derivation.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/specs/protocol/derivation.md b/specs/protocol/derivation.md index 1c7a0877a..ab8c8556b 100644 --- a/specs/protocol/derivation.md +++ b/specs/protocol/derivation.md @@ -1300,12 +1300,12 @@ transaction's receipt as invalid. - If it's a known transaction type, that is, legacy (first byte of the encoding is in the range `[0xc0, 0xfe]`) or its first byte is in the range `[0, 4]` or `0x7e` (_deposited_), then it's not a _future transaction_ and we know how to decode the receipt and this process is irrelevant. -- If a transaction's first byte is in the range `[5, 0x7d]`, it is expected to be a _future_ EIP-2718 transaction, so we can -proceed to the receipt. Note that we excluded `0x7e` because that's the deposit transaction type, which is known. -- The _future_ receipt encoding's first byte must be the same byte as the transaction encoding's first byte, or it is discarded -as invalid, because we require it to be an EIP-2718-encoded receipt to continue. -- The receipt payload is decoded as if it is encoded as `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`, -which is the encoding of the known non-legacy transaction types. +- If a transaction's first byte is in the range `[5, 0x7d]`, it is expected to be a _future_ EIP-2718 transaction, so we +can proceed to the receipt. Note that we excluded `0x7e` because that's the deposit transaction type, which is known. +- The _future_ receipt encoding's first byte must be the same byte as the transaction encoding's first byte, or it is +discarded as invalid, because we require it to be an EIP-2718-encoded receipt to continue. +- The receipt payload is decoded as if it is encoded as `rlp([status, cumulative_transaction_gas_used, logs_bloom, +logs])`, which is the encoding of the known non-legacy transaction types. - If this decoding fails, the transaction's receipt is discarded as invalid. - If this decoding succeeds, the `logs` have been obtained and can be processed as those of known transaction types. From b89f13721a5d3f9985f4663907c4f71d95c6d896 Mon Sep 17 00:00:00 2001 From: Sebastian Stammler Date: Fri, 17 Jan 2025 18:10:13 +0100 Subject: [PATCH 5/6] LINT --- specs/protocol/derivation.md | 1 + 1 file changed, 1 insertion(+) diff --git a/specs/protocol/derivation.md b/specs/protocol/derivation.md index ab8c8556b..27299afa4 100644 --- a/specs/protocol/derivation.md +++ b/specs/protocol/derivation.md @@ -50,6 +50,7 @@ - [GasPriceOracle Enable Ecotone](#gaspriceoracle-enable-ecotone) - [Beacon block roots contract deployment (EIP-4788)](#beacon-block-roots-contract-deployment-eip-4788) - [Building Individual Payload Attributes](#building-individual-payload-attributes) + - [On Future-Proof Transaction Log Derivation](#on-future-proof-transaction-log-derivation) From d541af1d2b2bd389c92c8540fbb46f1a5539c6ce Mon Sep 17 00:00:00 2001 From: Sebastian Stammler Date: Fri, 17 Jan 2025 19:34:42 +0100 Subject: [PATCH 6/6] address gk's review --- specs/protocol/derivation.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/specs/protocol/derivation.md b/specs/protocol/derivation.md index 27299afa4..0f4126676 100644 --- a/specs/protocol/derivation.md +++ b/specs/protocol/derivation.md @@ -1293,16 +1293,15 @@ As described in [L1 Retrieval][#l1-retrieval], batcher transactions' types are r However, we want to allow deposit transactions and `SystemConfig` update events to get derived even from receipts of future transaction types, as long as the receipts can be decoded following a best-effort process: -As long as a future transaction type follows the [EIP-2718][https://eips.ethereum.org/EIPS/eip-2718] specification, -the type can be decoded as the first byte of an encoded transaction or receipt (excluding legacy transactions, which are -not _future_ transactions). We can then proceed as follows to get the logs of such a future transaction, or discard the -transaction's receipt as invalid. +As long as a future transaction type follows the [EIP-2718][https://eips.ethereum.org/EIPS/eip-2718] specification, the +type can be decoded from the first byte of the transaction's (or its receipt's) binary encoding. We can then proceed as +follows to get the logs of such a future transaction, or discard the transaction's receipt as invalid. - If it's a known transaction type, that is, legacy (first byte of the encoding is in the range `[0xc0, 0xfe]`) or its first byte is in the range `[0, 4]` or `0x7e` (_deposited_), then it's not a _future transaction_ and we know how to decode the receipt and this process is irrelevant. -- If a transaction's first byte is in the range `[5, 0x7d]`, it is expected to be a _future_ EIP-2718 transaction, so we -can proceed to the receipt. Note that we excluded `0x7e` because that's the deposit transaction type, which is known. +- If a transaction's first byte is in the range `[0x05, 0x7d]`, it is expected to be a _future_ EIP-2718 transaction, so +we can proceed to the receipt. Note that we excluded `0x7e` because that's the deposit transaction type, which is known. - The _future_ receipt encoding's first byte must be the same byte as the transaction encoding's first byte, or it is discarded as invalid, because we require it to be an EIP-2718-encoded receipt to continue. - The receipt payload is decoded as if it is encoded as `rlp([status, cumulative_transaction_gas_used, logs_bloom,