Holocene: Hardfork Planning

[tynes]

Overview

Holocene is the next hardfork for the OP Stack. This discussion thread is meant to facilitate coordination around what features are included in it. There is a Holocene board view in the protocol monorepo. Please add ideas here for features that you would like to see included.

[tynes]

These are existing projects that we have thought about for inclusion in Holocene. None of this is a commitment of claim that these projects will end up in Holocene.

Custom Gas Token

I would like to propose rolling out the custom gas token contracts to the superchain per ethereum-optimism/optimism#10871. They have been merged into develop, and it will result in a massive headache if we do not roll them out as part of the next hardfork. The chains that do not use custom gas token would see this feature as a noop. This involves upgrade txs being sent for L2 predeploys as part of derivation on the hardfork block

Withdrawals Root in Block Header

This is specified in #177, the general idea is that it will remove the need to use an archive node for the challenger. In specific, fetching the output root preimages will no longer need an archive node.

Steady Batch Derivation

Open design doc in ethereum-optimism/design-docs#20, the idea is to reduce the amount of computation that has to happen in the derivation pipeline/fault proof program. This is very important to prevent long, complex and expensive reorgs in the world of interop.

[roberto-bayardo]

Elasticity as a system configurable parameter

In EIP-1559, the gas target of a block is (gas limit / elasticity). And since elasticity is a fixed constant of 6 as of the Fjord upgrade, one cannot adjust the gas target without increasing the gas limit. This has led Base to implement a hack whereby a different limit (a "soft" gas limit) is enforced by the sequencer during block building in order to allow us to increase the gas target without also increasing the (effective) limit. This unfortunately breaks things like priority fee suggestion, and is also simply unintuitive to users who see a gaslimit in the SystemConfig contract that isn't the one actually being enforced.

I would like to propose we make Elasticity configurable via the SystemConfig L1 contract, just as the Gas Limit is configurable, allowing gas target and gas limit to be independently configured.

[tynes]

I am in favor of this. A previous consideration that we had was around not adding too many fields to the L1 attributes transaction as to not bloat its size. We realized that there is a simple way around this, by not pushing "static" values (variables that don't change based on the L1 origin) via the L1 attributes transaction and instead having a separate setter path. This is described in #122 and has been implemented in a non generic way as part of custom gas token. Interop is attempting to implement setting static values in a more generic way, it would be great to standardize on this way of setting static config to reduce the size of the L1 attributes tx.

[tynes]

Curious if we should also consider the denominator to be dynamic as well. When the basefee rises super quickly when the target is exceeded, it creates this permanent pegging to the target throughput. It also This is a complex system and not sure what the best params ought to be for a high throughput chain. My guess is that the "ideal" params differ at different gas throughputs or usage patterns.

The optimism config in op-geth contains the elasticity as well as the denominator and the usage of the values can be found here.

[BlocksOnAChain]

Hey all, I would like to share a PM update on Holocene upgrade planning:

• We now have a dedicated mainnet upgrade board: https://github.com/orgs/ethereum-optimism/projects/84 and a dedicated
• Holocene view, in which we plan to add all issues that will be a part of this Hardfork: https://github.com/orgs/ethereum-optimism/projects/84/views/6
  The following steps are to add our planned issues for Steady batch derivation and other implementation tasks that are currently in discussion. After we agree on it, they will be included in the Holocene release.

[roberto-bayardo]

Looser coupling between L2 blocks and L1 origin

I would like to propose we amend chain derivation rules such that not every L1 block needs to serve as a unique origin for L2 blocks. Instead, the L1 origin should be able to represent a range of L1 blocks, allowing L2 block times to be better decoupled from the L1.

Because of the current tight coupling, an L($n+1$) must use a block time that is strictly greater than the block time of the L($n$). And since most OP stack L2s are using a 2 second block time, plus the fact that block times must be in second-granularity, the only option for L3s is a 1 second block time. Worse, this means an L2 can't switch to a 1 second block time without then breaking all the op stack L3s that settle to it.

I will link to a more precise specification for this idea when ready, but wanted to start the discussion now.

[sebastianst]

I support this change. It was also briefly discussed in another discussion on L(n)s.

[sebastianst]

Just talked to @protolambda about @tynes's proposal for a deposit queue and it sounds like this queue concept could solve the problem of too many deposits queueing up from L1-origin jumps >1. It also simplifies other aspects Interop. So it would probably make sense to include the deposit queue and the L1/L2 decoupling in the same protocol upgrade. Proto would have more details.

[roberto-bayardo]

Yes let's make deposit queue a pre-requisite for this item. Depending on time, we could possibly do the deposit queue for Holocene and postpone the decoupling for the fork after.

[BlocksOnAChain]

@roberto-bayardo - Based on the support we received for both proposals you shared here, I think we are safe to move to the next stage of Holocene scoping - you can create detailed issues for each proposal. 🚀 🪨
After we have the issues, I can add them to our dedicated Holocene view, which we will use for development, after we kick things off.

[BlocksOnAChain]

Hey folks,

Just wanted to share that I spent some time explaining the steps we're taking to plan for the upcoming hard fork work. There were some open questions from @roberto-bayardo and other OP Labs folks, so I wanted to share how we can reach a state of transition from this discussion to the actual development kick-off for any hardforks we plan to do.

All the details about the hardfork planning steps can be found in this public Notion doc: Network Upgrades: Hard Fork Planning Steps

I'm here for any questions you might have, and for that reason, I created a new discussion thread under this link

[BlocksOnAChain]

@tynes @protolambda - we should probably rename this discussion to Holocene HF and make reference to it, since Granite will be used for FP improvement and will come before this one?
I will optimistically take that action item, so we can provide clarity and avoid any confusion on this.

[BlocksOnAChain]

Hey folks, I just want to share that we closed down the scope for the Holocene Upgrade and that we will focus on the following topics in this upgrade:

• Steady batch derivation - Steady Batch Derivation changes the way in which invalid batches are processed during block derivation, ensuring timely progression of the derivation pipeline. Invalid batches are not substituted by newly incoming batch replacements any more, but instead are derived as deposit-only blocks.
• Partial span batch validation: after we are done with the implementation, it should allow us to determine the validity of singular batches within span batches on a case by case basis, and invalid singular batches are immediately derived as deposit-only blocks
• Add L2ToL1MessagePasser account storage root to Header withdrawalsRoot - Introduces an addition to the Holocene hardfork, where upon activation, consensus will require L2 block headers to contain the 32 byte account storage root of the L2ToL1MessagePasser predeploy after the block's execution.
• Make Elasticity configurable via SystemConfig - we will make Elasticity configurable via the SystemConfig L1 contract, just as the Gas Limit is configurable, allowing gas target and gas limit to be independently configured.
  --
  The entire scope and issues that will be a part of this hardfork are presented in this public Github view: https://github.com/orgs/ethereum-optimism/projects/84/views/6
  --
  The Team that will work on this this hardfork::
• @roberto-bayardo
• @sebastianst
• @geoknee
• @BlocksOnAChain
  Note: We will have other core contributors join in for reviews and testing.