OP Stack: Support Pectra

[tynes]

One major benefit of the OP Stack is that it is minimally different from Ethereum. This means that users, developers and infrastructure providers have less chain specific gotchas and more tooling "just works". Ethereum periodically has hardforks and we want to keep the OP Stack up to date with the latest features that L1 supports.

Pectra is an upcoming hardfork for Ethereum, its scope is documented in EIP-7600. We would like to ship Pectra as soon as possible to the OP Stack when we know the spec is finalized and its ready to be released on L1. This ticket represents the work required to add Pectra support to the OP Stack.

As we identify tasks, we can track them here.

• Span batch changes are required for 7702, see Pectra: Span Batch Support specs#318
  • Span Batch Change - paradigmxyz@dcc0809
• Derisk the fault proof execution of the BLS precompiles

From @ajsutton

For whenever we pull Pectra into the OP stack, we will need to do some benchmarking on the new BLS precompiles - there's a pretty high likelihood we'll need to apply the preimage oracle acceleration to them. Since the G1/G2 MSM precompile pairing check operation has a variable gas cost if it needs to go via the preimage oracle we will need to include a maximum input length for the precompile to ensure any call to it on L2 can be executed on L1 with some gas to spare to store the result in the preimage oracle.

For the OP Stack, we activate L1 hardforks with L2 hardforks. Depending on when the code is frozen for Pectra, it will determine when we are able to activate on the OP Stack. It is possible that we are able to include Pectra support in the Isthmus hardfork, see discussion: ethereum-optimism/specs#373

An example PR for adding a hardfork can be found here: #12418

[ajsutton]

Also just to note: we should make sure that Pectra activates on L1 first, not just that the spec is finalized because core devs don't really ever finalise a spec and there have been last minute changes and cancellations. We can still get the implementation ready and start governance but should make sure that:

1. we retain the ability to abort activating Pectra on OP Stack if there are last minute changes to it on L1 (ie note this in the gov post)
2. we don't upgrade the fault proofs absolute prestate (ie op-program) prior to Pectra activating. Partly because it includes the scheduled upgrade of the L2 but also partly to ensure that any new precompiles that are accelerated in the fork are actually present on L1 prior.

If there are new accelerated precompiles we need to deploy a new PreimageOracle that is used with the FaultDisputeGame contracts for the upgrade. No changes are required, it just needs to have a fresh state to ensure that preimages added from before the Pectra upgrade on L1 (where the precompiles just return 0) can't be used by games after Pectra updates (where it returns the actual response).

[K-Ho]

Separate from L2 Pectra Support, is there any additional work required to make sure that chains in the Superchain don't break when L1 activates Pectra? Thinking back to when some things broke back when Shanghai activated on L1.