Skip to content

specs: Specify derivation of future tx types #518

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.

Sign up for GitHub

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

Merged
sebastianst merged 6 commits into from
Jan 17, 2025
Merged

specs: Specify derivation of future tx types #518

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
ed6c7ab
specs: Specify derivation of future tx types
sebastianst Jan 16, 2025
75ef38a
rewrite
sebastianst Jan 17, 2025
88fab03
clarify
sebastianst Jan 17, 2025
34d334a
lint
sebastianst Jan 17, 2025
b89f137
LINT
sebastianst Jan 17, 2025
d541af1
address gk's review
sebastianst Jan 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions specs/protocol/derivation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -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
Expand Down
6 changes: 6 additions & 0 deletions specs/protocol/system-config.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.