On Faster Blocktimes

[tynes]

There is a desire to have faster blocktimes in the OP Stack. From the point of view of the protocol, what is a blocktime exactly?

The only thing that the protocol sees is the incrementing value in the block header. An OP Stack chain with a 2 second blocktime doesn't mean that it must create a block every 2 seconds - it just means that every block that is produced must have its timestamp incremented by 2. In theory a sequencer could build blocks extremely fast, incrementing the timestamp by 2 seconds until it reaches the maximum its allowed to be ahead of the L1 timestamp.

The most simple way to think about supporting 1 second blocktimes is to simply make it so that the timestamp increments by 1 and change nothing else about how time is managed within the protocol. This could be introduced via a hardfork and chains that opt in could have their blocktime change to 1 second. There are some chains that support OP Stack based L3s, which would break if they moved to 1 second. There have not been any hardforks yet that chains have opted out of and introducing this sets a precedent. If we wanted to prevent the need for backwards compatibility concerns, then we can allow a chain operator to set their blocktime via the SystemConfig. This guarantees backwards compatibility and allows chains to modify their blocktime as they see fit, but is much more complex then simply hardforking in 1 second blocktime.

Another way to think about supporting 1 second blocktimes is to change the way that time is managed in the OP Stack. Right now every block timestamp is deterministic and known ahead of time. This is similar to L1 after proof of stake. During Ethereum proof of work, the timestamp could be chosen by the miner but it had constraints on what it could be. Allowing for this could enable a more flexible design space with blocktime where its not necessarily enshrined into the protocol. We could change the gas limit as defined in the SystemConfig to be the epoch level gas limit rather than the block gas limit. The sequencer could have the right to produce blocks with the same timestamp and choose the timestamp for its blocks but the timestamp must be within a range so that it doesn't fall too far ahead or behind. The block building software now has flexibility with choosing the blocktime now, it becomes a configuration parameter of the sequencer rather than a protocol level config.

Having an epoch level gas limit doesn't play well with when the sequencer loses its connection to L1. That would mean that the sequencer has a liveness failure more more quickly compared to the existing max sequencer drift rules. The epoch gas limit gets used up and the sequencer must observe the next L1 origin to be able to produce more gas. Perhaps a way around this would be to make the epoch level gas limit instead be a timestamp level gas limit and keep the existing timestamp drift rules. With a cap on the max number of blocks that can be produced with the same timestamp, it forces the same progression of timestamps, which can still move forward building on the same L1 origin until the sequencer drift kicks in.

Allowing the sequencer to choose the timestamp means that it can bias RNG. Application developers should already be aware at this point that the timestamp isn't good for creating on chain RNG.

[tynes]

Allowing the sequencer to control the timestamp will mean the timestamp will need to be batch submitted. This could be optimized by submitting a timestamp diff rather than the full timestamp. This would require a new batch version and we would want to keep the semantics of the current batch version the same, where the timestamp auto increments by a hardcoded amount specific to the network

[ajsutton]

Note that using an epoch level gas limit would mean restricting the total gas for the epoch to something that can be proven in a single cannon/op-program run (ie the ephoch gas limit could not be larger than the maximum block gas limit that could be safely supported). This is because the sequencer may choose to create a single block that uses the entire epoch gas limit so in effect the epoch limit is the gas limit.

Not a blocker, just something to factor in to designs to ensure it remains fault provable.

[tynes]

Another consideration here is "lazy block production". It should be possible for a sequencer to build blocks more slowly if they are not seeing a lot of throughput. Decoupling the timestamps helps enable this. To be able to build blocks slower than the base chain, we would need #416. The tradeoff with allowing the sequencer to build blocks arbitrarily slowly is that it could delay deposits. There would need to be a rule where blocks can be produced lazily when there are no deposits and then progression is forced when a deposit is observed.

After thinking about this more, I am much more in favor of a timestamp based gas limit than an epoch based gas limit. We could keep the exact same timestamp rules with sequencer drift and have a cap of 4 blocks with the same timestamp and overload the definition of gas limit to mean "gas limit of blocks with same timestamp". This guarantees progression of the timestamp and opens up innovation at the block builder layer, which we are already seeing with rbuilder/rollup boost. Its a complex optimization problem to build blocks that are cheap to batch submit and also earn more fees.

We would also need a way to determine the total ordering of blocks with the same timestamp, to which @protolambda has previously suggested we could overload the block header's nonce field for this.

The op-node could at first implement a naive block building process that updates the timestamp in a very simple way and we can then build blocks faster in the future without needing to introduce any protocol changes.