L1-origin and deposit inclusion at migration/genesis time

[protolambda]

At the genesis (or migration point) of the rollup, we currently configure two points:

• The L1 block hash and number
• The L2 block hash, number and timestamp

From there, we can start deriving the L2 chain.
However, The first L2 block may not have transactions if it is a regular genesis block, and basically no L1 origin, although it might refer to the L1 genesis hash as origin.

When the L1 block after the configured genesis has a higher timestamp than the L2 time (most, if not always, the case) then we continue building blocks on top of the genesis epoch. Doing so however will run an epoch-insertion, and include deposits as if it were the first block (I think, depends on what we recognize as L1 origin of the L2 genesis).

Including deposits correctly at genesis is hard in different ways:

• if we continue configure the L1 genesis to be a L1 block-hash after the deployment of the deposit-contract, then we may miss deposit events.
• if we start from a L2 block that is ahead of the L1 block after the L1 genesis, then we might skip straight to that block, and miss deposits.
• if we start from a L2 block that is equal or ahead of L1 genesis, but the next L2 block time is lower than the next L1 block time, then we are forced to continue the sequencing epoch of the genesis block. The "l2 genesis" should be the block before the first L2 block we derive from L1.

I think we need to change the spec to:

• explicitly not process any deposits or L1 information from the L1 block
• explicitly define the L2 genesis as a block that is regarded as "derived" from the L1 block, without the need to parse the L1 info attributes tx of said L2 block.
• explicitly state that the first sequencing window is incomplete: the sequencer may add L2 blocks to the L2 chain with the same L1 origin as genesis
• explicitly state that the user deposits of the first sequencing window are already processed

This way we:

• can configure the L2 genesis to pick up exactly at the last L2 chain block that processed deposits, without duplicate processing. Or an empty block if this is not a migration but a completely new L2 chain.
• can configure the L1 genesis to pick up exactly at the origin of that L2 block.
• solve the problem that we can't actually embed the L1 origin of the L2 genesis block in a regular deposit tx in the case of a new chain.

And for a migration from current mainnet to bedrock we could:

1. First make the deposit contract stop accepting deposits (do we have access to do this?). So we have a clean boundary between old and new, instead of a L1 block that could have both old and new deposits.
2. Continue running the L2 chain until we consumed all deposits that were not yet routed to the new contract, including batch-submission and all other operation.
3. Deploy the new deposit contract on L1, but lock it from accepting any deposits for now.
4. Freeze the legacy L2 chain at some block height, no new batches or state root submissions from there
5. ASAP continue from a snapshot of the old L2 chain as L2 genesis, and the last referenced L1 block. Aside from migrating over the state, the L2 chain should be back online super quick.
6. Unlock the new deposit contract once the L2 chain is healthy

There may be more elegant ways to handle the genesis edge-cases, open for suggestions here.
This issue was inspired by a comment here: #321 (comment)