Upgrade Proposal #11: Holocene Network Upgrade

Technical Proposals 📃 Protocol Upgrade
1

Proposal Title: Holocene governance proposal

Proposal Type: Protocol Upgrade

Executive Summary

Hi I’m Dragan, a technical program manager at OP labs working on the OP blockchain development team, and a core contributor of the OP Stack. I reviewed this proposal in collaboration with Sebastian Stammler, Adrian Sutton, George Knee, Matt Solomon from the OP labs team and with Roberto Bayardo from the Base team.

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

Holocene contains three changes:

  • Holocene block derivation: a set of changes that render the derivation pipeline stricter and simpler, but also improve worst-case scenarios for Fault Proofs and Interoperability.
  • EIP-1559 configurability: The elasticity and denominator EIP-1559 parameters become configurable via the SystemConfig L1 contract, allowing gas target and gas limit to be independently configured.
  • MIPS contract upgrade: Updates to support additional calls made by the new op-program version.

Motivation:

We are submitting this proposal to make our community aware about all the improvement we made to our derivation pipeline and adding EIP-1559 configurability options.
I believe we should adopt the listed changes since we are getting a lot of improvements to the current codebase with this upgrade.
Also the listed changes are opening the doors for future Fault proofs and Interoperability project, since they both need improvement to our block derivation.

Specifications:

Blockspace Charter:

Technical Specification:

The Holocene network upgrade (spec overview) activates the following features:

  • Holocene derivation (Holocene L2 Chain Derivation) comprises the following changes to the derivation process:

    • Strict Batch Ordering requires batches within and across channels to be strictly ordered.
    • Partial Span Batch Validity determines the validity of singular batches from a span batch individually, only invalidating the remaining span batch upon the first invalid singular batch.
    • Fast Channel Invalidation, similar to Partial Span Batch Validity applied to the channel layer, forward-invalidates a channel upon finding an invalid batch.
    • Steady Block Derivation derives invalid payload attributes immediately as deposit-only blocks.

  • EIP-1559 configurability (Dynamic EIP-1559 Parameters) allows configuring the elasticity and denominator EIP-1559 parameters via the L1 SystemConfig. A new config update event was added, which is parsed by CL clients and then inserted into the extra field of the payload attributes in a special encoding format. These parameters, in turn, are then read by the EL clients during block building and applied accordingly. As with other SystemConfig updates, setting this is restricted to the SystemConfig owner.

  • Simplified Fee Scalar Configuration with new methods in the SystemConfig - this allows chain operators to change fee scalars in a more direct way, reducing the chance of user errors

Security Considerations

Consistent with OP labs audit framework we did not have the contents of Holocene audited; however, Coinbase and OP Labs engineers did perform a security review (Failure Mode Analysis) of these changes. The linked FMA can be consulted for details.

As for any hardfork that changes derivation, there is a risk that either the spec itself has a bug or that any implementation has a bug.
We’ve mitigated these risks by thorough internal reviews of the spec and unit and end-to-end tests of the implementations in Go and Rust.
Also, we have added differential tests of the derivation changes between the Go and Rust fault-proof program implementations op-program and Kona for the first time.

Holocene has also already been activated on internal devnets of Base and OP Labs, and it was confirmed that these networks operate as expected and that the new EIP1559 reconfigurability works as intended.

Specific security considerations for the Holocene upgrade are discussed in the respective section of the Holocene derivation spec. A noteworthy change in Holocene derivation behavior is that invalid payload attributes got second chances to replace valid, future payload attributes.
Because they are immediately replaced by deposit-only attributes with Holocene, there is a theoretically heightened risk for unsafe chain reorgs; however, it is only if a buggy or malicious sequencer batches an invalid block. To the best of our knowledge, we haven’t experienced this on OP Mainnet or other mainnet OP Stack chains yet.
Such a scenario would still be automatically resolved: the batcher would detect the reorg and submit the reorged unsafe section of the chain.

With the stricter derivation rules, some complexity gets shifted from the derivation pipeline to the batcher because it now has to adhere to stricter rules in order not to produce invalid channels or batches.
We’ve implemented a set of improvements to the batcher to guarantee the stricter ordering rules by design. Next to that, the Holocene contains the fail-safe rule that any first frame of a new channel replaces old buffered frames of non-completed channels. An invalid batch forwards-invalidates any remaining batches and the channel that contained the batch.

This means that an emergency batcher restart should be able to resolve any deadlock in the derivation pipeline if it were to occur.

Impact Summary

We do not anticipate any downtime due to this upgrade.

Bringing Holocene derivation changes is making our derivation pipeline stricter and simpler.
It also allow us to improve and unlock new development paths for Fault Proofs and Interoperability features.

EIP-1559 configurability allows chain operators to change the gas target independently from the gas limit. Before, a workaround had to be taken to raise the limit to indirectly raise the target, and then enforce the old limit via a sequencer block building policy.

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: this upgrade does make it easier to configure Gas Limits, but does not ossify them.
  • Direct Fee Margin Controls: no change to the relevant configuration structure and authorization. Some helper methods for get/set logic are added to the SystemConfig, but do not fulfill the overall intent of this precommittment.

Action Plan for this release

If this vote passes, the Holocene upgrade will be planned for execution on the 9th of Jan 2025 18:00:01 UTC. The upgrade will occur automatically for chains on the Granite mainnet release if those chains have opted-in to activate at Superchain times via their superchain-registry configuration (i.e., have the superchain_time set to a timestamp before or at the mainnet activation time, or have set their holocene_time directly). The mainnet release will be prepared at a later time during the governance process, but no later than 4 weeks before the proposed activation time.

Holocene is code complete in the optimism monorepo at a tag op-node/v1.10.2-rc.1 and op-geth at tag op-geth/v1.101411.4-rc.2.

Contract updates

The following contracts are updated to OP Contracts v1.8.0-rc.3 release:

  • MIPS: 1.2.1
  • FaultDisputeGame: 1.3.1
  • PermissionedDisputeGame: 1.3.1
  • SystemConfig: 2.3.0

SystemConfig Update

The SystemConfig L1 contract will get upgraded to version 2.3.0 (the implementation is deployed at this address:(“0xAB9d6cB7A427c0765163A7f45BB91cAfe5f2D375”).
This is a shared implementation of the Mainnet Superchain

The upgrade will happen after the Holocene activation. The upgraded SystemConfig enables chain operators to update the EIP-1559 parameters via a new function setEIP1559Params.

Fault Proofs Update

This update involves a new release of the op-program v1.4.0-rc.3 that contains the Holocene activation and generate the absolute pre-state (“faultGameAbsolutePrestate”: “0x03f89406817db1ed7fd8b31e13300444652cdb0b9c509a674de43483b2f83568”) for it, which is a commitment to the program and its starting state. This requires deploying new FaultDisputeGame and PerimissionedDisputeGame contracts to L1 Mainnet with the new op-program pre-state hash.

  • These contracts are deployed at the following addresses FaultDisputeGame: (“0x27B81db41F586016694632193b99E45b1a27B8f8”) and for PermissionedDisputeGame: (“0x91a661891248d8C4916FB4a1508492a5e2CBcb87”) - contract addresses are specific to OP mainnet
  • MIPS: 1.2.1 (with the following contract address: (“0x5fE03a12C1236F9C22Cb6479778DDAa4bce6299C”) - which is a shared implementation on the Mainnet Superchain

After the veto period has ended, we will ask the Security Council to sign transactions to update the DisputeGameFactory to begin using these new contract implementations. This transaction has to be executed before the actual Holocene activation to avoid a broken Fault Proofs system after the activation.

  • Updates to the MIPS contract

As part of the Holocene upgrade, the Go compiler was updated from 1.21 to 1.22. This impacts the op-program as the go1.22 runtime makes additional syscalls that are not supported by the pre-Holocene MIPS Fault Proof Virtual Machine (FPVM).

As such, Holocene includes an update to MIPS.sol that supports go1.22 programs. This change to the FPVM is very minimal; an update to the fcntl syscall emulation that was partially implemented by the pre-Holocene FPVM. In order to make sure we implemented this in a proper way, we conducted an external audit for this change. In order to make sure we implemented this in a proper way, we conducted an external audit for this change, which is open for reviews under this link - no major findings reported.

Conclusion

This proposal outlines the network upgrade after Granite titled Holocene. This network upgrade brings all the listed features and we hope we will get your votes to bring all the suggested improvements to the OP stack.

19 Likes
2

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

1 Like
3

Can I know why the audit is not performed for a major technical upgrade?

I feel users and developers would be more comfortable knowing the audit has been completed before a network derivation change

2 Likes
4

We are an Optimism Delegate (PGov Delegate) and we believe this proposal should be pushed forward to a vote.

5

I think it’s based on this framework.

3 Likes
6

I appreciate that the changes to the MIPs contract were audited and trust the DAB to provide the final decision on the SystemConfig contract review conducted by the OPLabs and Base teams.

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

2 Likes
7

We used OP Labs audit framework and determined that the changes we have in this upgrade don’t require us to perform an audit.
However, Coinbase and OP Labs engineering team did perform a security review (Failure Mode Analysis) of these changes.
Feel free to review the FMA document for all the details of our analysis.

1 Like
8

Thanks, @Dragan_ZzZ for putting forward this proposal.

Regarding the SystemConfig change, this looks very straightforward. On the side of the Holocene derivation changes, one important question for us is to understand the maximum risk during its implementation. Since the possibility of reorgs is introduced, how deep (in terms of time) could these reorgs go? Should users with time-sensitive activities be concerned about this?

Thank you!

3 Likes
9

Developer Advisory Board: Holocene Summary

Hello! The Developer Advisory Board has written the following non-technical summary of the Holocene upgrade proposal.

Disclaimer

Please note that I am an employee of OP Labs. I have written this summary in my capacity as a member of the Developer Advisory Board. I did not have any significant involvement with the development of the Holocene upgrade proposal presented here.

Holocene Derivation Changes

All of the block data for any OP Stack chain is published to Ethereum, which is what makes OP Stack chains Rollups! When nodes want to sync an OP Stack chain, they use a process called “chain derivation” to scan through Ethereum blocks and reconstruct the L2 chain from the various transactions that were published to Ethereum.

Why is chain derivation being updated?

OP Stack chain derivation is handled by a somewhat complex piece of code that tries to make the life of the Sequencer/block producer easier in certain cases. OP Labs has stated that experience from OP Mainnet and other OP Stack chains shows that some of this code is not necessary. Holocene proposes to simplify the chain derivation process and remove a lot of this existing Sequencer hand-holding code. These changes also benefit Fault Proofs and Interop by making the OP Stack simpler and easier to run.

How does this impact the OP Stack?

The Holocene chain derivation changes shift more responsibility for smooth chain operation onto the Sequencer but the changes do not allow the Sequencer to do anything new that it could not previously do. Sequencer software would need to be more careful to avoid causing short-term disruptions like reorgs of blocks that the Sequencer has not yet published to Ethereum. OP Labs states that the current Sequencer software already handles this appropriately but any future changes will need to keep this in mind.

What code is being changed?

These changes require modifications to op-node, op-geth, and any other implementations of these components.

Were these changes audited?

No, these changes were not audited by a third party. OP Labs states that this is consistent with the OP Labs Audit Framework. Engineers from OP Labs and Coinbase jointly wrote a Failure Mode Analysis for these changes.

EIP-1559 Configurability

EIP-1559 is the EIP that controls how Ethereum handles fees, gas, and block gas limits. EIP-1559 defines a number of parameters that control how this process works. Holocene proposes to change two of these parameters (the elasticity and denominator values) that were previously fixed to be configurable. This gives operators more flexibility when running an OP Stack chain.

What is the EIP-1559 elasticity parameter?

EIP-1559 defines a target gas limit for each block. EIP-1559 allows chains to be “elastic” to handle bursts of usage and blocks can therefore be larger than this target gas limit. The elasticity parameter defines how much gas a block can use at a maximum in comparison to the target gas limit. For example, if a chain sets a target gas limit of 25 million gas per block and has an elasticity of 2, then the maximum gas limit will be 25 million x 2 = 50 million gas per block.

What is the EIP-1559 denominator value?

Chains want the amount of gas used in the average block to be close to their target gas limit. EIP-1559 achieves this by automatically increasing the gas price when blocks are using more than the target gas limit and decreasing the gas price when blocks are using less than the target gas limit. The denominator parameter defines how quickly these increases can happen. For example, if the denominator is set to 8, then the gas price can increase or decrease by a maximum of 1/8 = 12.5% per block.

Why are these values being made configurable?

OP Labs states that OP Stack operators have requested the ability to have more fine-grained control over the way that block gas limits work on OP Stack chains.

How would this impact OP Mainnet?

OP Mainnet would not be immediately impacted by this change as the values for these two parameters are not changing with Holocene. However, future upgrades can now propose to modify these values.

What code is being changed?

These changes require a modification to the SystemConfig contract on Ethereum as well as modifications to the op-node, op-geth, and any other implementations of these two components.

Were these changes audited?

No, these changes were not audited by a third party. OP Labs states that this is consistent with the OP Labs Audit Framework. Engineers from OP Labs and Coinbase jointly wrote a Failure Mode Analysis for these changes.

MIPS Changes

The Holocene upgrade proposes to upgrade the Go compiler version in the OP Stack from 1.21 to 1.22. This new version of the Go compiler uses certain features that are not supported by the existing MIPS smart contract. Holocene proposes to update the MIPS contract as a result.

Why do we need this change now?

Version 1.21 of the Go compiler didn’t make use of certain MIPS features that version 1.22 does. Holocene proposes to upgrade to version 1.22 of the Go compiler, so these features must now be supported.

Were these changes audited?

Yes, these changes were audited by 3DOCSec, an independent security researcher. This audit did not result in any findings. You can find the audit report here.

Fault Proof Changes

Whenever the L2 code undergoes a fork, the Fault Proof code on L1 must also be updated to be able to follow this fork. Holocene proposes to update the FaultDisputeGame and PermissionedDisputeGame contracts to be able to follow this fork.

Is this a standard change?

Yes, this is a routine change that needs to happen whenever the L2 code forks. Delegates should expect that an update to the FaultDisputeGame and PermissionedDisputeGame code will come with any future upgrade that changes op-node or op-geth.

Feedback

If you have any additional questions, comments, or concerns about this proposal that the Developer Advisory Board can help to clarify, please feel free to ping me or any other member of the DAB!

14 Likes
10

Thanks Mr smartcontracts.eth & the DAB for the summary.

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

2 Likes
11

Thanks @Dragan_ZzZ for the proposal and @kelvin for the DAB summary of the proposal. All the proposed changes that are the chain derivation changes, the EIP-1559 elasticity parameter change and the MIPS related changes look reasonable and make sense, to be staged for the future major upgrades. The failure mode analysis provided for these changes is well-thought-out while these changes are not audited according to the Audit Framework.

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

2 Likes
12

After reviewing these proposals, we support this movement to upgrade proposal #11. The elasticity parameter, in theory, makes a lot of sense, allowing for greater flexibility for OP Stack chain builders. As an aside, we would be curious if research has been conducted surrounding user elasticity toward gas limits and what different chains (with different use cases) have found.

While the changes are not audited in accordance with the OP Labs Audit Framework, as the DAO is increasingly consulted, it would be beneficial to have some third-party auditing of all changes, if for no other reason than to better represent the needs of OP stack builders in ensuring all changes are as robustly reviewed as possible.

That said, as presented, we trust OP Labs’ process to properly audit the #11 upgrade.

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

3 Likes
13

Can we revisit this framework? This just seems unnecessary not to audit all of these upgrades.

What exactly is gained by not auditing, anyway? If Labs is unable to finance the audit, governance regularly provides audit subsidies. Even if no user funds are at risk, there’s reputational risk.

3 Likes
14

On behalf of Blockchain@USC:
We are an Optimism delegate with sufficient voting power and we believe this proposal is ready to move to a vote.

1 Like
15

Hey @GFXlabs, thanks for your comment. As mentioned in my post and by @kelvin, we performed a full Failure Mode Analysis for all the changes mentioned in Holocene.
This was done by all implementation teams and we shared all our findings publicly, which is the process that should follow according to the Audits framework.
I do believe that we are actively revisiting this framework and that we will probably make certain updates to it in 2025.

3 Likes
16

Hey @SEEDGov,

Unsafe reorgs have always been possible. We have just identified a new scenario which could theoretically cause an unsafe reorg. We’ve introduced the new derivation rule to reattempt invalid payload attributes with a deposits-only version. This new rule is primarily in preparation of future Interop protocol extensions, to avoid cascading reorgs of inter-dependent chains.

An unsafe reorg from this scenario is very theoretical and could only be cause by a malicious or (very unlikely) buggy sequencer implementation. A sequencer would need to craft invalid attributes, different from the matching unsafe block, and then batch them. So under normal operation, this scenario cannot happen. And if you have a malicious chain operator, there’s worse things to worry about than an unsafe reorg. The depth of such a reorg would be at most the length of the unsafe chain, so it wouldn’t go into the safe chain.

Therefore no action needs to be taken by normal chain users, and practically, unsafe chain reorgs aren’t more probably than they were before, in terms of expected causes of reorgs.

Hope this helped putting the reorg risk into perspective.

4 Likes
17

Fully agree

A network that is securing billions in TVL like Optimism and Superchain should not push any network level upgrades without a third party audit.

It seems bordering on careless…

2 Likes
18

Weldone team… more effort in ensuring the op collective mission is actualize
Stay Optimistic.

1 Like
19

Hi @lavande!

This proposal met the requirement for delegate approvals, but how will this go to a vote if there is currently no elected DAB to give the remaining approval?

As I recall, during all Reflection Periods we always have Upgrade Proposals.

I think this situation should be considered in the DAB charter for Season 7. CC:@zachobront

1 Like
20

Hey all, just a quick update on my side:

  • I want to let everyone know that I re-formatted the gov proposal to the new “charter-aware upgrade proposal” format that was approved with the ratified standard blockspace charter proposal.
  • No substantive changes were made to the content of this proposal.
  • @AnthiasLabs, @PGov, @Gauntlet @Tane, @Luckyhooman.eth - I’m making you aware about this change, since you already shared your approval on the Holocene upgrade proposal. :pray:
5 Likes