all: L1 Pectra support (Upgrade 12)

[protolambda]

The L1 Pectra upgrade introduces a new tx-type and changes to the block-header.

---

Latest L1 Timeline:

• Holesky activation February 12th
• Sepolia actiaction February 19th
• Mainnet activation mid March (tentative)

---

These a breaking change to RPC contents and source-data verification.

These breaking changes have to be supported to
not halt the Fault-Proof or chain upon new unrecognized input data.
This will be prioritized over regular L2 upgrade work.

This is not Pectra in L2. Introduction of Pectra in the L2 itself is tracked here:
#12435

Core Pectra changes that break formats / preimages:

• Block-header (new requests root attribute)
• Transactions (EIP-7702, new tx type to decode when traversing batch inbox)
• Receipts (EIP-7702, new receipt type, no breaking change other than type itself)

Spec

• Clarify that unknown receipt types are decoded to best ability,
  • assuming the same receipt format we have for every tx type thus far, to support deposits.
• Clarify 7702 receipt type can contain valid deposits and system-config events
• Clarify that batcher-txs of types other than 0, 1, 2, 3 will be ignored by default.
  • TODO: L3s may also need 0x7e (deposit tx) to be a valid batcher tx, for force-batches.

op-service,op-node,op-program

The old plan for op-service, op-node and op-program which we discarded for now is in this fold

op-service

• Client bindings integration:
  • sources: EthClient.InfoAndTxsByHash needs to return a list of GenericTx.
    And ByLabel and ByNumber methods can mirror tha change.
  • testutils: mirror sources API changes on mock utils
• RPC block-header verification update
  • requestsRoot optional RPC attribute of block-header needs to be handled in sources.RPCHeader.verify()
• Core tx type support: (PR in progress - op-service: generic tx, raw json tx types #13628 )
  • eth.GenericTx interface:
    • type: to check if we can decode
    • tx-hash: to verify the transactions-root in block-header (MPT leaf pre-images match tx-hashes: both are keccak hashes of the encoded tx)
    • tx: to decode the transaction
    • JSON encode/decode support, err if tx-type is not supported
    • binary encode/decode support, err if tx-type is not supported
    • to be used in derivation pipeline
  • eth.OpaqueTransaction struct:
    • implements GenericTx interface
    • supports binary such that we can determine the type and tx-hash, even if not knowing how to interpret the binary payload, or how to turn into a JSON tx.
    • to be used in op-program, around preimages.
  • sources.RawJsonTransaction struct:
    • implements GenericTx interface
    • supports JSON such that we can determine the type and tx-hash, even if not knowing all JSON fields, or how to encode as binary.
    • to be used in op-node, when deriving from a L1 RPC

op-node

• node:
  • L1Client from op-service fits new derive changes for L1 data retrieval.
• derive package:
  • InfoAndTxsByHash needs to return a list of eth.GenericTx, not *types.Transaction
  • FetchReceipts ideally returns a list of *types.Receipt for now if we land minimum 7702 support,
    even if not the exact right 7702 final version, since the 7702 receipt format has no changes, and it's just the type we need to work.
• Sanity-check that the beacon-API format did not change for blobs retrieval.

op-program

• client:
  • only decode the tx preimages, when traversing L1, if the tx-type is 0 (legacy), 1 (berlin, 2930), 2 (london, 1559), 3 (cancun, 4844).
    • Use eth.OpaqueTransaction to fit eth.GenericTx interface requirement of derivation code.
  • EIP-7702 receipt support
  • block-header support: requests-root already supported in block-header. Not future compatible.
    Ignoring RLP-trailing items may be implemented later, for forward-compatibility.
• host:
  • preparing tx preimages by tx-hash needs to warn if JSON-RPC returns a RawJsonTransaction that we don't know how to encode into RLP.
  • EIP-7702 tx preimages can be supported without RPC fallback once op-geth is updated. This can be changed without breaking state-transition or client side, if L1 breaks things.
  • For future tx types we need a fallback to prepare the preimage using a non-JSON source, that has the opaque form of the tx.
  • EIP-7702 receipt support

op-geth

• Land the 1.14.12 PR: all: update to geth v1.14.12 op-geth#452
• Implement and land the upcoming v1.14.13 changes:
  • Contains EIP-7702: all: implement eip-7702 set code tx ethereum/go-ethereum#30078
  • Fixes the internal Geth requests-root Go API churn. Cleanup, good to have.
  • Milestone of 1.14.13 is 97% complete, but no release yet: https://github.com/ethereum/go-ethereum/milestone/176
  • We could just merge master upstream geth into optimism, and not wait for the v1.14.13 remainder.
  • Blocks the simple approach the EIP 7702 receipt support.
  • Blocks testing of Pectra L1 support in monorepo Go tests.

testing

• Action test that creates L1 with Pectra activated, and finalizes a L2 chain with a tx in it.
• op-program test to make sure a 7702 tx, 7702 receipt with deposit, and block header with a request, on L1 is not a problem.
• Deploy op-stack with OPCM on a L1 Pectra chain (devnet 5 or testnet)

Later Go work

Later, for better future compatibility against L1 forks:

• Introduce eth.GenericReceipt, eth.OpaqueReceipt, sources.RawJsonReceipt: we can introduce the same abstraction for receipts.
• Update FetchReceipts to return a list of eth.GenericReceipt.
• sources.RPCHeader support for unknown block header fields: unfortunately no way to translate to the RLP without type interpretation.
• Update op-program oracle interfaces to handle block-headers that are extended with additional RLP fields.
  • Block-header hash can then still be computed, without interpreting the new unknown contents.

Instead we are updating op-geth and monorepo in these PRs:

• all: Merge upstream pre-v1.15.0, based on #474, plus review fixes op-geth#480
• Update op-geth dependency to upstream pre-v1.15.0 master merge & ignore SetCode batcher txs #13958

Rust work

Separately, in the rust stack:

• Update Kona / op-rs:
  • With EIP-7702 (tx/receipt) handling.
    • Kona uses the op-alloy's OpReceiptEnvelope which includes the EIP-7702 variant.
  • Block-header handling.
    • Kona uses alloy's header for execution and rpc types. The alloy Header type already includes EIP-7702 support in the current version.
  • Ignore batcher txs with 7702 tx type in derivation pipeline.
    Even if the tx type decoding might work, to stay in consensus with spec / op-node / op-program.
    • Ignored by default, but a test has been added here.
• Plan and implement longer term forward-compatibility strategy for future L1 changes.
  E.g. through patterns similar to that of eth.GenerixTx.

[sebastianst]

@protolambda regarding your proposed future work for generic receipts, I'm not sure it makes sense for now given how I specified handling of future receipts in ethereum-optimism/specs#518 - they are expected to decode exactly the same as type 0-4 txs, so the current *types.Receipt type should be fine for now.

[protolambda]

@sebastianst see code here: https://github.com/ethereum-optimism/op-geth/blob/6c1047a2d9db86d03f635bb24704b77675189227/core/types/receipt.go#L351

Geth will not decode the receipt binary data (as passed via pre-image oracle) if not configured with a recognized type. The receipt bytes are prefixed with the type byte just like txs, and thus distinguished and not automatically compatible.

And currently type 4 is not supported (until we merge in later geth work with 7702 tx type). And this problem will repeat for future tx types if we don't change the receipt decoding code or implement separate custom receipt decoding here in the monorepo.

[sebastianst]

@sebastianst see code here: https://github.com/ethereum-optimism/op-geth/blob/6c1047a2d9db86d03f635bb24704b77675189227/core/types/receipt.go#L351

Geth will not decode the receipt binary data (as passed via pre-image oracle) if not configured with a recognized type. The receipt bytes are prefixed with the type byte just like txs, and thus distinguished and not automatically compatible.

And currently type 4 is not supported (until we merge in later geth work with 7702 tx type). And this problem will repeat for future tx types if we don't change the receipt decoding code or implement separate custom receipt decoding here in the monorepo.

Ah makes sense, thanks! I was falsely assuming that the decoding code wouldn't check the types, which of course was a strange assumption to make 😅

[geoknee]

We hit a roadblock when trying to have op-service handle transactions generically #13816 (comment). We likely will need to just adopt a strategy of explicitly supporting EIP-7702 transactions rather than trying to be forward compatible with any future tx types.

[tynes]

We hit a roadblock when trying to have op-service handle transactions generically #13816 (comment). We likely will need to just adopt a strategy of explicitly supporting EIP-7702 transactions rather than trying to be forward compatible with any future tx types.

Just wondering if any decisions have been made on the new scope

I am generally in favor of just rebasing op-geth and then supporting reading of calldata from 7702 txs if that unblocks this. It may not be possible to decouple at this point

[sebastianst]

We hit a roadblock when trying to have op-service handle transactions generically #13816 (comment). We likely will need to just adopt a strategy of explicitly supporting EIP-7702 transactions rather than trying to be forward compatible with any future tx types.

Just wondering if any decisions have been made on the new scope

I am generally in favor of just rebasing op-geth and then supporting reading of calldata from 7702 txs if that unblocks this. It may not be possible to decouple at this point

@tynes yes we've decided to abandon the generic future-proofing work, and instead just pull 7702 txs into op-geth and then add the support to the monorepo. I'm working on this right now.

Quoting summary from Discord

No matter how we spin it, we loose the ability when using JSON RPC (like in op-node or op-program host) to trustlessly verify the block hash integrity. We may be able to make it work with even more changes to how we pull data from an RPC, e.g. using some debug RPCs to get the binary encoding, but it seems unwieldy and the more we tried to make it work, the more issues came up, creating more complexity. And in the end, we don't even know whether this rather special kind of forwards-compatibility would even be enough for the next L1 upgrade. It would only proof against new EIP-2718 txs, that use the same receipt encoding as the existing non-legacy txs, which is quite the assumption to make.

[sbvegan]

@mslipper should we be tracking op-deployer updates in here so net new chains support Pectra at L1 contract deployment?

nvm I thought about it and realized the absolute prestate is the only thing that will need to be updated

[sebastianst]

Release candidates are ready:

• op-node/v1.10.4-rc.1
• op-geth/v1.101500.0-rc.1
• op-program/v1.5.0-rc.1 - absolute prestate hashes:
  • default: 0x03dfa3b3ac66e8fae9f338824237ebacff616df928cf7dada0e14be2531bc1f4
  • mt64: 0x03f83792f653160f3274b0888e998077a27e1f74cb35bcb20d86021e769340aa
  • interop: 0x03b7658b889796c1e372f57439e48eb46a5b008f6e6a4b7e5c8c2d3bddffa797

[geoknee]

Also

• op-batcher/v1.11.0-rc.1