op-program: EIP-7702 compatibility if Pectra before Isthmus

[pauldowman]

If Pectra on L1 comes before Isthmus it will cause problems for us. EIP-7702 (included in Pectra) introduces a new transaction type which isn't supported by the op-program version in Holocene. (Because it's not merged into the current version of Geth.)

We should change the derivation pipeline to ignore transaction types that aren't used by the batcher (see @tynes comment below).

We're aiming for cycle 33

• If it looks like the Pectra HF might happen before Feb 19 then getting the change into cycle 32 isn't early enough and we need an emergency response.
• If it's Feb 19 to April 3 then it can go in cycle 32 or 33.
• If it's later then it's after Isthmus which has Pectra.

[pauldowman]

FYI @protolambda

[tynes]

We should consider enshrining a set of tx types that the derivation pipeline only cares about. This will prevent this sort of issue from happening again - we don't want to have to upgrade our proof system alongside L1 upgrades, we want to be decoupled from L1 upgrades so that we can both make progress in decoupled ways.

An honest batcher only uses dynamic fee tx type (1559) or blob tx type (4844). Technically legacy and berlin access list types could work, but the batcher doesn't submit txs of those types. We should update the derivation pipeline such that it ignores unknown tx types, meaning it will only observe legacy, berlin access list, dynamic fee and blob txs. We can make it observe other tx types at will in the future.

[tynes]

The definition of done for this involves:

• updating the derivation pipeline to only parse known transaction types BEFORE pectra. This means the derivation pipeline will ignore 7702 (setcode) tx types
• getting a new updated prestate onchain

This doesn't need to roll out via a hardfork necessarily as long as it happens before pectra since 7702 txs will not exist before pectra. If this rolls out after pectra, the proof will be broken and the op-node will halt on the first 7702 tx that is included in L1. This is difficult because it depends so much on the timing of L1 upgrading to pectra

[sebastianst]

I agree that we should go so far to add a whitelist of tx types that the batcher is allowed to use, and drop all other tx types during derivation that are not in this list. So we'd only allow 1559 and 4844 txs (and maybe legacy? Are we sure no batcher impl ever sent legacy?). We don't even need to allow ACL txs imo.

Since no batcher impl ever sent ACL or future 7702 txs, I think it's fine not to include it in a hardfork if we add this soon before Pectra.

[tynes]

This also needs to skip over receipts that have an unknown version, since typed transaction envelopes also define receipts

[joshuacheong]

Hey @pauldowman could you provide access to the L1 Pectra risks document to my notion account at [email protected]? Thank you

[pauldowman]

@joshuacheong It's an internal doc and doesn't really add much to what's here except details on the timeline which is a bit out of date now. The status is that we're working on the solution described in comments here.