holocene: smart contract changes

[tynes]

Description

This PR is the spec for:

• L2 Genesis Simplification (L2 MCP) #350
• Holocene: Make Elasticity configurable via SystemConfig #340

We are explicitly not scoping #122 because it will result in a large diff to the proofs. In the future we can work on proof optimizations.

[tynes]

The permit2 predeploy has the L2 chainid embedded in the bytecode. We need a way to handle this, I think we should just wipe the chainid to by 0 so it just uses block.chainid rather than a cached version

[tynes]

We need to think about the semantics of the upgrade.

For the L1Block storage part of the upgrade, we either need to:

• Include a "migration contract" that deterministically migrates the state
• Have fallbacks in each implementation contract that try to read from L1Block then fall back to state

Both have tradeoffs

The migration contract approach would look like upgrading the L1Block contract to a contract that is able to make a bunch of calls to get the data it needs and then storing it in its storage at the correct locations. So this would be fetching the storage values, for example calling L2CrossDomainMessenger.otherMessenger. We would need to make sure that all of the values can be accessed for this to work. The problem with this approach is that it will use a lot of gas and we need to be mindful of not using too much gas during the upgrade, otherwise it will conflict with user deposits. This is a risk we will always face until we have deposit queue. We could also make the semantics such that the deposit transactions are done over multiple blocks, but this is not flexible with certain configurations of the OP Stack.

The fallback approach will not force the storage migration to ever happen and we will likely be stuck with the fallback forever or at least a good amount of time until we can be sure that a SystemConfig.initialize does send all of the correct information to L2

[roberto-bayardo]

overall this LGTM other than the unresolved comments.

[BlocksOnAChain]

Async reminder:
@protolambda feel free to add your thoughts on any potential risks we might have with this approach.

[protolambda]

@BlocksOnAChain no immediate concerns.

From a purist view, I like if the post-genesis, but pre-user, state changes are immediately after genesis, rather than at any point (there may be gaps, because of the fixed block time). Should not be a concern if deposits are only enabled after the post-genesis system deposits complete.

And the 1559 fee parameters have fun lower/upper bound cases, but won't brick the system as long as they can be modified through L1-initiated deposits.

[tynes]

I will rebase this before merge

[tynes]

We need to think about the semantics of the upgrade.

For the L1Block storage part of the upgrade, we either need to:

• Include a "migration contract" that deterministically migrates the state
• Have fallbacks in each implementation contract that try to read from L1Block then fall back to state

Both have tradeoffs

The migration contract approach would look like upgrading the L1Block contract to a contract that is able to make a bunch of calls to get the data it needs and then storing it in its storage at the correct locations. So this would be fetching the storage values, for example calling L2CrossDomainMessenger.otherMessenger. We would need to make sure that all of the values can be accessed for this to work. The problem with this approach is that it will use a lot of gas and we need to be mindful of not using too much gas during the upgrade, otherwise it will conflict with user deposits. This is a risk we will always face until we have deposit queue. We could also make the semantics such that the deposit transactions are done over multiple blocks, but this is not flexible with certain configurations of the OP Stack.

The fallback approach will not force the storage migration to ever happen and we will likely be stuck with the fallback forever or at least a good amount of time until we can be sure that a SystemConfig.initialize does send all of the correct information to L2

I solved this with a setHolocene function on the L1Block contract that does the storage migration