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!