Upgrade Proposal #12: L1 Pectra Readiness

Technical Proposals 📃 Protocol Upgrade
1

Proposal Title: L1 Pectra Compatibility

Proposal Type: Maintenance Upgrade

Executive Summary

Hi I’m George, a Protocol Engineer at OP Labs and core contributor of the OP Stack. I reviewed this proposal in collaboration with Sebastian Stammler and Lewej Whitelow from the OP Labs Team.

Neither OP Labs nor I represent or speak on behalf of the Optimism Foundation.

Background: Pectra is an upgrade to the Ethereum protocol composed of Prague (Execution Layer) and Electra (Consensus Layer) which will activate soon on testnets and mainnet. It contains consensus changes which, by default, would cause all OP Stack chains to halt. In particular:

  • a new transaction type (and corresponding receipt type) is introduced by EIP-7702.
  • a new field in the block header is introduced by EIP-7685

Upgrade 12 is a maintenance upgrade which consists of changes to

  • Node software
  • Optimism protocol specifications and
  • L1 Fault Proofs smart contract system(s)

to elegantly handle activation of the Pectra hardfork on L1 networks.

The expected outcome is that OP Stack chains continue to operate as before (they do not halt) when Pectra activates on their respective L1 chains. This is a critical piece of maintenance affecting all operators and users of OP Stack chains.

Motivation

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

These are breaking changes 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.

Specifications

Blockspace Charter

This Protocol Upgrade is scoped to the Standard Rollup Charter. No changes will be made to the charter as a part of this upgrade, as the new prestates can be added to standard prestates TOML in accordance to the existing Standard Rollup Charter.

Technical details

In summary, the required changes are:

  • An update to the Optimism Protocol Specification (and CL clients) to clarify that: EIP-7702 type 4 “SetCode” transactions are not included in the set of transactions from which batches are input into the derivation pipeline.
  • An update to the Fault Proof’s absolute prestate, the FaultDisputeGame, the PermissionedDisputeGame and the DisputeGameFactory on chains which use Fault Proofs.

As well as updates for the node software(s) (enumerated below) such that

  • EIP-7702 transactions may be parsed and decoded without error and
  • The requestsHash property in the block header is properly deserialized. L1 blocks can thereby verified and processed as usual.

The changes are described in detail (with links to code changes) in the release notes below:

These updates incorporate breaking changes to L1’s RPC contents and source-data verification. The strategy employed to handle the breaking changes is to perform an upstream merge of geth into op-geth, and then to import the new code into the monorepo where it is consumed by op-node and op-program. Additionally, some quality-of-life optimizations and breaking changes are bundled with the criticial ones called out above; however, none of them are consensus critical.

Security Considerations

We performed a Failure Mode Analysis as well as extensive end-to-end testing, including on devnets based on the live Holesky L1 network which has already activated Pectra.

Impact summary

We do not anticipate any downtime due to this upgrade, as long as it is executed on each chain before the respective L1 chain activates Pectra. There should be no impact on performance after the upgrade.

As long as the upgrade is executed in this manner, it will count as a soft fork instead of a hard fork and there will be no risk of chain splits. For this reason, the upgrade is not named as a hard fork and no activation time needs to be set. Operators should just upgrade their node software as soon as possible once the releases are out.

The impact of not performing the upgrade is as described above (all OP Stack chains will suffer a safe head stall and a few hours later the sequencing window would expire causing a large reorg).

Key Dates

  • Activation of Pectra on Holesky: 24th February 2025
  • Activation of Pectra on Sepolia: 5th March 2025
  • Activation of Pectra on Mainnet: 8th April 2025 (provisional)

Precommitment impact review

This Upgrade Proposal does not impact any of the precommitments in the Standard Rollup Charter.

  • Collective Fee Take: no modification or onchain implementation introduced.
  • Governor/Servicer Role Separation: no change to role structures or authorization patterns.
  • Ossified GasLimits: no change
  • Direct Fee Margin Controls: no change to the relevant configuration structure and authorization.

Conclusion

This proposal outlines an unnamed network upgrade with index 12, whose purpose is to allow the Optimism protocol and implementation software to continue working as it does now even when consensus changes are activated by L1 in the Pectra hardfork. We rely on your votes to bring this improvement in order to maintain the health of the OP Stack superchain.

Note: By submitting a proposal, you represent and warrant to the Optimism Collective that all the information it contains is true and complete to the best of your knowledge.Preformatted text

13 Likes
2

The SEED Gov delegation, as we have communicated here, being an Optimism delegation with sufficient voting power, we’re in favor of this proposal being approved.

This upgrade is necessary for OP Chains to continue operating after Pectra is implemented; otherwise, Pectra will brick the chains. We take this opportunity to highlight a few useful aspects as presented:

  • The FMA helps in understanding the risks of the proposed changes and allows us to introspect on what has been done to prevent or resolve incidents.

  • The effect on precommitment over SRC is broken down by items, making it easier to verify that the proposal remains compliant.

3

Will there be an EIP-2537 update in line with the Ethereum update?
(BLS12-381 elliptic curve, including BLS signature verification)

4

I think you might refer to this proposal Proposal Preview: Implement Prague features on the OP Stack