Consistent Block Time Block Derivation Function

[karlfloersch]

Design Goals

• Constant block time (ie. 1 block every n seconds) -- informed by: https://github.com/ethereum-optimism/optimism/issues/1790
  • Allows devs to make timing assumptions based on blockNumber
  • Allows us to use eip1559 off the shelf
• Sequencer can set timestamp of deposits up to a point -- informed by: How should we handle `timestamp` in v1.0? #23

These

High Level Overview

The intuition for how the algorithm works is that you automatically derive blocks based on the L1 timestamp. So for example if on L1 you had the following three blocks with these timestamps:

L1: [10, 22, 30]

We would derive the following blocks on L2 with these timestamps (given a 2 second blocktime):

L2: [10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30]

Once we have laid out all of the blocks, the sequencer may choose (within their sequencing window) which blocks it included deposits, and which blocks contain sequencer transactions. If the sequencing window passes without inputs from the sequencer, then all deposits are included in the block with timestamp: l1_block_timestamp - (l1_block_timestamp % l2_blocktime).

Challenges

• In order to preserve a constant blocktime, we might want to have a single block contain both deposits AND sequencer transactions. This is annoying because it breaks the very nice deposit block / sequencer block abstraction which is useful for How to handle early Fault Proof VM exits #22 & possibly for reducing implementation complexity.
• There will be a lot of empty blocks -- not great for super small scale rollups.

[tynes]

Related work:

EIP-4396 is a modification to EIP 1559 that works on time instead of blocks. This helps to keep the basefee calculation more smooth after the merge when the blocktime is constant instead of probabilistic and there is the possibility of a missed slot where a block comes after 24 seconds instead of the standard 12 seconds.

[karlfloersch]

Great callout! I love EIP-4396 and it would also solve our EIP1559 pricing problem, but I still like consistent block times because it works both today with the current EIP1559 implementation AND the future EIP-4396.

[norswap]

Worth to mention that some users are seemingly very vocal about consistent block time, and that there are lots of people who seem to measure time by the passing of blocks instead of timestamps (and even more surprisingly, often have a configurable block time parameter, probably to accomodate multiple chains).