Upgrade Proposal #15 - Isthmus Hard Fork

Technical Proposals 📃
1

Proposal Title: Upgrade 15 - Isthmus Hard Fork

Proposal Type: Protocol Upgrade

This proposal is intended to be voted on in Cycle 35

This proposal is contingent upon the passing of Upgrade Proposal #14

Executive Summary

Hi, I’m Lewej, a Technical Program Manager at OP Labs. I prepared this proposal in collaboration with Sebastian Stammler, Paul Dowman, and Ben Clabby from the OP Labs Team, Aurélien from Succinct, and Julian Meyer from Base.

Neither OP Labs nor I or any other entity mentioned represent or speak on behalf of the Optimism Foundation.

This proposal introduces the Isthmus hard fork. The features to be activated have been shared in preview posts:

Motivation

Many of the EIPs in the Pectra hard fork are useful to end users and developers on the Superchain, so including features that enable new account abstraction primitives, make proofs more efficient, and other enhancements are important to release as soon as possible after L1 activation. Other features in the Isthmus hard fork enhance the node operator and dev experiences, especially for those working on Alt-DA & ZK chains.

Impacted Stakeholders & Expected Outcomes

  • All node operators: will be required to update node software to a new release once the L1 Pectra activation date is finalized.
  • Users and developers: changes are backwards compatible, but this release enables new features like EIP-7702 to be leveraged on the Superchain. Some predeploy APIs are updated, see changelog here.

Specifications

  • Blockspace Charter

    • This upgrade does not require any changes to the Standard Rollup Charter beyond those in Upgrade 14, which this builds upon.

  • Technical details

    • Pectra Support

      Specs for each EIP are implemented in the specs repo under Isthmus. This spec explains how the protocol should change to adopt Pectra EIPs.

    • Operator Fee

      We propose the addition of 2 new rollup operator configured scalars, collectively named the Operator Fee Parameters. These scalars are named operatorFeeScalar and operatorFeeConstant, and they factor in the fee calculation as follows:

      operatorFee = operatorFeeConstant + operatorFeeScalar * gasUsed / 1e6

totalFee = operatorFee + gasUsed * (baseFee + priorityFee) + l1Fee

      These scalars will be updated via the SystemConfig L1 contract. A new fee vault, the OperatorFeeVault, is added to store the operator fee.

      Upgrade 14 already prepares the SystemConfig with support for setting the operator fee parameters. So this proposal doesn’t include an upgrade of the SystemConfig contract.

      This feature has the potential to adjust the collective fee take requirements in the standard rollup charter. However, the standard rollup configuration requirements are not being updated as a part of this proposal. For all standard OP Stack chains participating in the Superchain, both the operatorFeeConstant and operatorFeeScalar are required to be configured to 0, effectively deactivating the feature. In a future proposal, governance may approve the activation of this feature on standard OP Stack chains alongside an update to the standard rollup configuration requirements.

      Resources

    • L2 Withdrawals Root in Block Header

      The storage root of the L2ToL1MessagePasser contract is added to the block header at the withdrawalsRoot field, starting with Isthmus activation. This makes it easier for chain participants to inspect or post the correct output root proposals, since they don’t need to run an archival node any more, but have the info readily available in the block header, which any full node can provide.

      More implementation details can be found in the proposal review of this feature.

      Resources

  • Impact Summaries

    • Pectra Support

      Implementing Pectra features in Isthmus will make the next hardfork require upgrades to certain key components.

      • The op-challenger preimage will need to be upgraded to support new accelerated precompiles and new transaction types
      • proxyd needs to be updated to handle set code transactions
      • Span batch format is updated to include the new tx type

      All of the typical components that need to be upgraded during a hardfork also need to be upgraded.

    • Operator Fee

      This proposal is planned to be included in Isthmus, but the feature is disabled by default. In order to be able to set the operatorFeeScalar and operatorFeeConstant parameters, the SystemConfig contract must be upgraded. This upgrade will already have happened with Upgrade 14.

    • L2 Withdrawals Root in Block Header

      • The OP Stack Specs provides a comprehensive overview of the impact
      • Performance changes
        • Reduces the requirement to access withdrawals root, which benefits the OP Stack.
        • Only performance hit is specifying the withdrawals root during block building which is a very low cost account lookup per block.

  • Precommitment impact review:

    This Upgrade Proposal only impacts the Collective Fee Take precommitment in the Standard Rollup Charter.

    • Collective Fee Take: while the operator fee’s offchain codepath is included in this release, it is still required to be set to 0 for standard chains and thus does not impact the fee take today. However, this upgrade paves the way for the fee calculations to be updated in the future to account for additional costs, e.g. ZK proving.
    • Governor/Servicer Role Separation: no change to role structures or authorization patterns.
    • Ossified GasLimits: no changes to ossified gasLimits
    • Direct Fee Margin Controls: no change to the relevant configuration structure and authorization.

Action Plan

While this upgrade encompasses all code changes required to update to this new version of the OP Stack, one dependency is missing: the L1 Pectra activation date, which at the time of posting is not finalized. To deploy this upgrade, the L1 Pectra activation date needs to be known.

As such, a full action plan for this proposal is not prepared. Instead, we anticipate submitting a subsequent Maintenance Upgrade as a fast follow to this one, which sets the activation date and:

  • Commits to a concrete payload which the Security Council can sign
  • Tags the correct releases for off-chain software, inclusive of activation date, including:
    • op-node
    • op-geth
    • op-challenger
    • op-batcher

Since none of the above changes affect L1 contract implementations, this maintenance upgrade will also not need a new OPCM beyond the one for Upgrade 14.

Conclusion

This proposal outlines the features to be introduced with the Isthmus hard fork. These are key to maintaining parity with L1 and provide the best experience to users and developers of the Superchain that we can. We look forward to your support in implementing these features with your positive votes.

3 Likes
2

I am an Optimism delegate with sufficient voting power and we believe this proposal is ready to move to a vote.

3

I’m an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

4

We are familiar with the Pectra changes as a node operator and those changes to OP make sense. Other changes including the Operator Fee related one and L2 Withdrawals Root related one seem reasonable.

We are an Optimism delegate with sufficient voting power and believe this proposal is ready to move to a vote.

5

The SEEDGov delegation, as we have communicated here, being an Optimism delegation with sufficient voting power, we believe this proposal is ready to move towards a vote.

6

I am an Optimism Top 100 delegate [Delegate Commitments - #65 by mastermojo ] with sufficient voting power, and I believe this proposal is ready to move to a vote

7

At Superseed we’re an Optimism Delegate with sufficient voting power and we believe this proposal is ready to move to a vote.

8

I would like to comment on behalf of the Developer Advisory board with the goal of making the WHY of this proposal clear to governance.

Summary for upgrade 15 isthmus hardfork:

There are three parts of this change. The first is that this hard fork implements the ethereum Prague hardfork changes which include a number of EIPs. The second change is that the operator fee outlined in the previous proposal will go live. The third is that the L2 withdrawals root is put in the block header. This makes it easier for chain participants to inspect or and verify the correct output root. Prior to this change, in order to verify the output root individuals would need to run an archival node, but with this change we put the withdrawal root readily available in the block header, which any full node can provide. This enables third parties to compute block commitment outputs without grabbing the withdrawal root from an archival node.

4 Likes
9

GM @Jepsen;

I want to celebrate your comment; and thank the DAB (Developer Advisory Board) for helping us translate these proposals into less technical language. :folded_hands:

In fact, I’d like to take this opportunity to suggest some questions that often help us (mortals) better understand the context (without getting too technical), in case it serves as inspiration for this or other proposals.

  • What does this change solve?
  • What happens if we do nothing?
  • What is the trade-off assumed along this path?
  • Are there any valid criticisms anyone might have?
  • Why did this change come about until now?

Thanks for keeping this conversation going. :dizzy:
Stay optimistic. :heart:

10

Sure I am happy to answer these to the best of my ability.

I believe that my post answered the first questions in regards to the withdrawal root. In short it allows anyone to verify that the withdrawal root was created correctly which increases the transparency of some of the fault proof system. If we do not add this change, it makes it more difficult for everyday people to verify this part of the computation because it requires they need access to an archival node. I do not believe there is much valid criticism of this feature.

In regards the eip’s these are changes to the ethereum mainnet that agreed upon by the community. Optimism is maintaining compatibility with ethereum main-net but supporting these changes. If these changes are added or supported here then there will be features supported on the ethereum main-net that are not supported on optimism or OP stack chains. This presents substantial risks and I would consider good and standard for these upgrades to be added to the optimism stack, and that not adding them would present more risk. I do not know of much valid criticism of this upgrade of the top of my head but most of the discourse around what upgrades eth undergoes are well documented in a rigorous process that i do encourage anyone curious to look into.

In regards to the operator fee please see my comment here: Upgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon - #10 by Jepsen
You are welcome to provide any criticism or feedback about the operator fee here.