feat(holocene): Simplify eip1559Params

[clabby]

Overview

Simplifies the dynamic EIP-1559 params feature of Holocene by including the parameters within the PayloadAttributesV3 and the block Header.

Rationale

Currently, the EIP-1559 parameters are included within the L1Block contract. However, unlike other variables within the L1 info transaction:

1. The EIP-1559 parameters are unlikely to change frequently enough to warrant being in the L1 info transaction. Most other fields change every L1 block, but even on the most ambitious OP Stack chains (Base), they only expect these values to change once per week.
2. In the execution engine, all OP Stack EVM implementations currently load the L1 block info from the state database. However, since the EIP-1559 parameters are required at the beginning of the block, we would also need to lift this out of the EVM and into the block executor.
3. The EIP-1559 params in L1 info makes the function to compute the next block's basefee stateful. That becomes a fairly invasive change, where the pre-block environment fillers now have to have access to the database, L1 block info formation from storage slots logic, etc. In reth, for example, the base fee computation function is within a lower-level config type, without access to the state or transactions. Ultimately we lose database access several layers of abstraction higher up, warranting a refactor to make this change work. In geth, it's similar, but the change is a bit less invasive higher up with only 2 layers to pass the state handle through.

There's precedent for SystemConfig variables that are needed at the beginning of a block, or that don't update frequently, to belong within the PayloadAttributes (The gas_limit). The block builder additionally having access to control the EIP-1559 parameters is constrained by consensus rule, and similarly to the gasLimit, is specified to be referenced from the SystemConfig in the derivation pipeline's payload builder. This change would simplify this feature's implementation within execution clients and save us from needlessly posting the parameters in the L1 info transaction every 2 seconds as such.

Why in the block header?

https://github.com/ethereum-optimism/specs/pull/404/files#diff-b93100978f12975e6b4ee660c7362c71d4f2a416ef7c9f0e76e17ca0062842efR144-R152

[clabby]

• feat(holocene): Simplify eip1559Params #404 👈
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @clabby and the rest of your teammates on Graphite

[refcell]

Although I think this is sound, I'm a bit concerned of using the nonce in case we need it down the road for something. Placing these in the L1 info feels more scalable to me and is a more consistent way of introducing modifications, though there is the aforementioned tradeoff that the basefee computation becomes invasive.

[tynes]

We should make sure that there is a getter for EIP1559 params on the SystemConfig so that its legible on chain what the config is. This will help to make standardness checks possible as part of the superchain-registry. This might also be in the spec, I just see the getters removed from the L1Block contract, would be good to double check