L2 Block Timestamps

[trianglesphere]

The current design of the system is to have an L2 block every Config.Blocktime seconds. Note: the target block time is 2 seconds. This results in a steady stream of L2 blocks (even if they are empty). There is another way to do this where L2 blocks are only produced when there are non-empty blocks, but that has some issue with timestamps.

When looking to produce L2 blocks we create block every 2s in the following (half open) range)

minL2Time: L1Info.Parent.Timestamp
maxL2Time: L1Info.Timestamp

I would like to switch it to the following:

minL2Time: L1Info.Timestamp
maxL2Time: L1Info.Child.Timestamp

The downside to the second approach is that now a L2 block depends on a block after its L1 Info block for validity. The upside to the second approach is that timestamps are more natural: in the first the timestamp of the L2 block that includes the deposit will be less than the timestamp of the L1 block that the deposit was included in.

Note: neither approach handles the case in which the difference in L1 block times is less than the L2 block time.

To handle this the specs use the following formula:

min_l2_timestamp = prev_l2_timestamp + l2_block_time
max_l2_timestamp = l1_timestamp + l2_block_time

This is similar to the first approach in that the L2 time trails the L1 time. Note that it can collapse to an empty range if there are multiple L1 blocks in a row with a too short block interval

@norswap's proposal

max_l2_timestamp = (next_l1_timestamp - 1) % l2_block_time

[trianglesphere]

Ideas on handling short L1 block times:

• Force at least one L2 block per L1 block. Can (optionally) pull from L1 timestamp.
• The issue is that the L1 timestamp will not necessarily be aligned to the L2 block time
• Create L2 blocks on a timestamp after that?

The idea would be something like the following:

When creating an epoch of L2 blocks do the following:
- Create the range [L1 Info timestamp, L1 Info Child timestamp)
- If the first block of the epoch
  - if L2 parent timestamp + L2 Block time is out of the range
    - Create an L2 block with the timestamp L1 Info timestamps
    - End block production for the epoch.
  - Else continue with normal block timestamps
- Create blocks that are L2_blocktime after their parents

Note: we lose the fact that L2 blocks are always an integer multiple of the block time after the genesis.

[tynes]

I do think lazy block production is ideal, but we would likely have to implement a consensus engine for that. My main question here is what sort of protocol level guarantees can we give to application devs? If the timestamps are based on config, then we can alter that config arbitrarily and the security guarantees go out the window. On L1, miners can alter the timestamp but it has to be greater than the previous timestamp and within some threshold of time.Now.

[trianglesphere]

We can implement lazy block construction as long as it is deterministic from L1 (and easy enough for the sequencer to implement at the L1 chain tip). Sure we could mess with the timestamps on the sequencer, but the verifiers will reject them if they are not correct.

[norswap]

Block production is already lazy in the current design: we only create batches for blocks with transactions, the blocks in between still exist in the execution engine but are being derived lazily by the rollup-driver.

[norswap]

Let's consider the proposal where the first L2 block of epoch N has the same timestamp as L1 block N (and let's assume for simplicity's sake that both of these timestamps are always multiple of 2).

The fundamental problem, as I understand it, is that, from the point of view of the sequencer, when it attempts to build an L2 block, there is uncertainty as to whether that block's timestamp (2s past the timestamp of the previous block) will land before or after the next L1 block's timestamp.

@trianglesphere is that accurate?

I think this changes with the merge, where the block time becomes a fixed 12 secondes. So basically we can have 6 L2 blocks per L1 block at T+0, T+2, ...., T+10 (where T is the timestamp of the L1 block).

@protolambda Are there any caveats here that we need to be aware of? Block production can most definitely be delayed, but is it also possible that in the canonical L1 chain a block gets skipped?

I think the issue I see with this design is a strong need for synchronicity between the L2 and L1 chain. If the last block we saw had number N and timestamp T, then we will need to see L1 block N+1 at time T+12, or we can't produce the first L2 block of epoch N+1.

Even missing out on updates for a few seconds are T+12 becomes problematic for latency and throughput.

We can "fix" this problem by keeping a buffer of L1 blocks. So if the last L1 block has number N, we could add new sequence transactions to a block in epoch N-X (e.g. X = 10). This lets us preserve latency/throughput for up to X*12 seconds of L1 downtime.

I don't like this too much though, as I expect it to enable some weird arbitrages, especially once we add the ability to read from the L1 chain on L2 (and this ability is sort of kinda present from the start, with proofs against the latest L1 block root).

Also I'm not sure what we gain by setting such a relationship — it's neither intuitive nor particularly useful, but see next section for more thoughts on this.

On the other hand, the alternative design were the first block at epoch N has the timestamp of L1 block N-1 is just weird. If we're going to do that, we might as well disregard an explicit relationship between L1 and L2 timestamps.

I think we could instead set boundaries on the relationships, such as:

• L2 block timestamps are multiple of 2
• The timestamp of the first L2 block of epoch N is >= the timestamp of L1 block N
• There is a maximum of X L2 blocks per epoch.

This design lets us have variable length epochs, which lets us survive temporary loss of connectivity to L1.

You'd still get "weird arbitrages" sometimes when you have long epochs, but those would happen only when L1 connectivity is lost, which should be fairly seldom.

Am I missing something else that we absolutely need to consider?

Just a quick note because I was very temporarily confused by this: this discussion is completely distinct from any notion of "sequencer window". The sequencer window is for deriving the L2 chain from L1. Here we're talking about the sequencer building the blocks before posting batches to L1.

[trianglesphere]

I think configuring the rollup + new execution client to start at a specific block is easy. I'm not so sure about configuring the current client to stop.

[norswap]

Isn't this supposed to be an answer to #242 (comment) rather?

[trianglesphere]

Oh sorry, absolutely

[tynes]

where the block time becomes a fixed 12 seconds

If I understand correctly, it will be possible for the slot to be missed, meaning there is a "gap" and t[i+1] == t[i] + 24 where t is an ordered list of the L1 timestamps. There is an EIP that outlines an update to EIP 1559 to work with time instead of blocknumbers to account for this but I can't seem to find the link to it right now

[trianglesphere]

Just a quick note because I was very temporarily confused by this: this discussion is completely distinct from any notion of "sequencer window". The sequencer window is for deriving the L2 chain from L1. Here we're talking about the sequencer building the blocks before posting batches to L1.

Sequencer window yes, but we do need to consider the verifier.

The timestamps created by the sequencer need to be sanity checked and accepted by the verifiers.
Right now we can create empty batches on the sequencer side to force the two second block time, but the thing that is tricky is when batches are missing: the verifier needs to fill in the blocks in a deterministic way.

[trianglesphere]

1

Yes. This is a problem (but not insurmountable) with the sequencer forcing constant 2s block times.

To me, here are the requirements:

• We must include deposits
• We must not assume anything about L1 block times (less so in PoS, but block times are manipulable in PoW)
• The method of determining L2 blocks from L1 blocks should be fully deterministic on the verifier side (and the approach needs to enable the sequencer to produce blocks that the verifier will accept)

The crux of the problem is that L1 block times have variability (and TBH I am incredibly distrustful of relying on shared timestamps in distributed systems).

I like a solution similar to your proposed solution in point 3, with the addition that every L1 block is included in the L2 chain (which results in an uneven block time).

The other solution is to keep the 2s block time and roll multiple deposits together (but now deposits can be included in a block that has a wrong height), but it is fully deterministic. The hard problem there is that the validity of the deposit tx is dependent on more state that in previously was

[norswap]

Summary of today's discussions:

Some concerns with the current design, where the L1 timestamp in the L1 attributes deposit is >= the max L2 timestamp for that epoch:

• it's confusing that the L2 blocks have smaller timestamps that the L1 block they "build on"
  • the reason it's built like this is that otherwise (if the L1 timestamp in the L1 attributes deposit is the minimum L2 timestamp), there is an uncertainty/race between the next L1 block and the L2 block after the expected end of an epoch
    • after the merge, we should have one L1 block every 12s, but they can occasionally be skipped
    • therefore, if we don't see the L1 block coming in 12s after the previous one, we're not sure if the block is just delayed (because of networking or what not), or if the slot has been skipped -- so we're not sure in which epoch to build the next L2 block
• the L2 system goes down if we don't see an L1 block every 12s, which is a very tight coupling to L1 liveness

A proposal that would assuage these issues: remove the tight coupling between L1 timestamps and L2 timestamps. This allows the number of L2 blocks to fluctuate (instead of being fixed to 6 per epoch when L1 does not skip slots). We would impose two constraints:

• every L2 block timestamp is > than the timestamp of the L1 block in the last L1 attributes deposit
• the latest non-empty L2 block timestamp is < MAX_L1_L2_TIME_DIFF, a constant used to prevent L2 from running too far ahead of L1
  • empty L2 blocks (no sequenced transactions) are still allowed to maintain the one block per 2s invariant
    • for instance if L1 goes down for an extended period of time, there will be a bunch of epoch comprising 6 blocks with only deposits + empty blocks when L1 spins back up.
  • practically speaking, MAX_L1_L2_TIME_DIFF must be smaller than the time taken by a sequencing window

There are also things to be cautious about with this approach:

• MEV implications: the sequencer can arbitrarily delay user deposits and L1 attributes deposit (which people will use to read/prove the L1 state on L2), this could enable some forms of arbitrage
  • the sequencer already has immense MEV power, so it's not clear how much of a concern that is, but we should think about it
• In the case L1 goes down for a long time, the resulting epoch could have a huge amount of empty L2 blocks. Our current implementation puts all of the blocks for an epoch in an array. With this approach, we risk blowing up the memory, so care should be taken to harden the implementation to deal with this edge case.

So now the question is whether we want to go ahead with this design or if there are other issues with it that we haven't properly considered.

[maurelian]

First, I am concerned about the additional difficulty in reasoning about the L1 blocks/timestamps and L2 blocks/timestamps. Considering that we started with a simple 1 to 1 relationship between L1 blocks and L2 epochs (and each epoch starting with a deposit block), it feels like this increases the complexity in a way that makes me a bit uncomfortable.

OTOH, this change is nicely more intuitive:

every L2 block timestamp is > than the timestamp of the L1 block in the last L1 attributes deposit

---

With that said, TBH I don't have a good alternative suggestion at the moment, and so I will follow up with some questions and nits, because that's how we do.

1. Do we know what happens when L1 comes back? Do timestamps skip the downtime, or start where they left off?

2. practically speaking, MAX_L1_L2_TIME_DIFF must be smaller than the time taken by a sequencing window

I don't think this is necessarily true. If MAX_L1_L2_TIME_DIFF > SEQUENCER_WINDOW, it would just mean that the L2 blocks are truly empty (ie. there aren't even deposited tx in them). Though if blocks are truly empty, then one could argue that there's no point in producing them.
Either way, I think having MAX_L1_L2_TIME_DIFF == SEQUENCER_WINDOW might help to simplify the implementation of this proposal.

3. the sequencer can arbitrarily delay user deposits...

Assuming MAX_L1_L2_TIME_DIFF <= SEQUENCER_WINDOW, I don't see how this follows from the proposal.

---

update: I made a text diagram to compare the current design against the proposal. Doings so made me start to the like it more.

[norswap]

1. Do we know what happens when L1 comes back? Do timestamps skip the downtime, or start where they left off?

They "skip" the downtime. Except they don't really "skip" it, since in the canonical chain, we'd still have a bunch of empty blocks every two seconds.

I don't think this is necessarily true. If MAX_L1_L2_TIME_DIFF > SEQUENCER_WINDOW, it would just mean that the L2 blocks are truly empty (ie. there aren't even deposited tx in them).

I would think the opposite! If the time diff exceeds the sequencer window, then we force the start of a new epoch, with the inclusion of the deposits from a new L1 block. So any block that the sequencer produces after the sequencer window elapsed that does not reference this new epoch would be invalid.

I think maybe the confusion here is that there are two possible scenarios in which we can "lose" L1. One is that we lose connectivity to L1. Then things are as I wrote above, we can't produce valid blocks after the sequencer window has passed.

The second scenario is that L1 itself goes down. In that case, the time for the sequencer window to go by also increases indefinitely (since it is measure in blocks, and no new blocks are being produced).

I'm thinking of the first scenario, and simplifying to assume that we get one L1 block at every slot, which is very likely. Given that, it doesn't make sense to allow the sequencer to keep producing blocks that can't possibly be valid.

update: I made a text diagram to compare the current design against the proposal. Doings so made me start to the like it more.

It's pretty damn good! (though the sequencer windows will be much longer of course, something liek 64 blocks * 12s = 12.8 minutes)

First, I am concerned about the additional difficulty in reasoning about the L1 blocks/timestamps and L2 blocks/timestamps.

I feel you, but also I feel like this isn't really that more difficult than what we have currently? We have two rules instead of one, true, but we gain the nice intuitive property of L2 timestamps > deposited L1 timestamp, and we solve the racing issue.

[norswap]

New proposal, slightly modified from the above to allow for 1s L1 blocks.

I renamed MAX_L1_L2_TIME_DIFF to MAX_SEQUENCER_DRIFT. Can revert if people like the old name better, but using the term "drift" made the explanations flow a bit better.

Timestamps / Epoch Size Proposal

• Each L1 block is associated with an epoch comprising one or more L2 blocks.
• L2 blocks timestamps are a multiple of 2s, and there is an L2 block every 2s.
• The deposits in the L1 block are included in the first L2 block of the corresponding epoch.
• Epochs have no fixed size (but comprise at least one L2 block).
• Two constraints apply on L2 block timestamps:
  • L2_TIMESTAMP >= L1_TIMESTAMP where
    • L2_TIMESTAMP is the timestamp of an L2 block
    • L1_TIMESTAMP is the timetsamp of the L1 block associated with the the L2 block's epoch
  • L2_TIMESTAMP <= L1_TIMESTAMP + L1_1S_BLOCK_COUNT + MAX_SEQUENCER_DRIFT
    • MAX_SEQUENCER_DRIFT must be smaller than the expected sequencing window time (1)
    • in practice, pick the largest amoutn of time we're comfortable "drifting" from L1
    • L1_1S_BLOCK_COUNT is the number of L1 block whose timestamps are separated from their parents by only 1s, since the inception of Bedrock (2)
  • It is possible that these constraints are not satisfied, but that a L2 block nonetheless needs to be produced to satisfy the requirement that there is an L2 block every 2s. This can occur if there is a very large intra-L1 block time. In this case, we simply produce empty L2 blocks.

The goal of flexible epoch size is to deal with temporary loss of connection to L1 and natural latency issues. The flexibility is given by the two constraints. The sequencer is allowed to "run ahead" or "drift ahead" of L1 (i.e. create L2 block whose timestamp exceed the expected timestamp of the next epoch's L1 block), but within the limit given by MAX_SEQUENCER_DRIFT. The sequencer is also free to produce shorter epochs if it is already ahead of L1.

In practice, the concrete algorithm we will implement is that the sequencer will start a new epoch as soon as it is sees a new L1 block, hence trying to keep the drift as close to zero as possible. The drift will only increase when we lose connection to L1. Upon resuming connection, we will have multiple L1 blocks to process, which will all (except the last one) be mapped to an epoch with a single L2 block, hence reducing the drift.

Note: I think we should also think about a scenario where drift accumulates but we're still seeing L2 blocks at regular intervals (why/how could this happen?). One solution is to try to slow block production down proportionally to the drift. e.g. if the drift gets large, produce one L2 block every 4s of wallclock time instead of 2. The timestamps are still spaced by 2s as mandated by the spec, so this should naturally bring the drift down.

Note that there is no point in waiting for "confirmations" from the L1 chain: since the L2 chain is derived from L1, any reorg on L1 would cause a reorg on L2, such that the mapping between L1 blocks and L2 epochs (and in particular, the deposits at the start of the epoch) is always preserved. To process a withdrawal emitted in a given L2 epoch, economic bridges should however wait for a number of L1 confirmations starting from the L1 block corresponding to the epoch.

Post-merge, we expect every L1 block to be spaced by 12s, though it is possible for blocks to be skipped and hence for the inter-block distance to be larger. The constraints outlined above do work with larger L1 blocks, and also with shorter L1 blocks, should we need to support them.

(1) MAX_SEQUENCER_DRIFT must be smaller than the expected sequencing window time, because if we lose connection with L1 for longer than the sequencer window, it means we can't submit a batch in time, and so the whole epoch the sequencer built becomes invalid (as the sequencing window has passed, so the canonical chain will only have empty blocks for this epoch).

Note: this reasoning does not hold if L1 itself experiences an outage or if we have a very large intra-L1 block time (e.g. in case of a partial network outage / attack). It's impossible to tell the difference between loss of connection and full L1 outage. Partial outages could be detected and treated differently, allowing the sequencer to drift without limit. I'm not sure the added complexity is worth it, or that this behaviour is even desirable.

(2) The L1_1S_BLOCK_COUNT term allows us to deal with the special case of L1 blocks spaced by 1 second, which is shorter than the L2 block time. This term is necessary because otherwise a sequencer that has drifted to the maximum allowed would be unable to deal with new L1 blocks spaced by only one second. Without the term, the right side of the equation would increase by 1, while the left side would increase by 2, preventing us from creating a new block, which would contradict the rule that each L1 block is associated to an epoch of at least one block.

[norswap]

Feedback from conversation:

• the L1_1S_BLOCK_COUNT is very stateful, meaning we need to maintain this counter on either L1 on L2 and read during the derivation process. This is feasible, but not ideal.
• the L1_1S_BLOCK_COUNT only expands, and so risks expanding drift over time. Essentially, this "shifts" the L2 wallclock time permanently. Things still work, but L2 won't create new blocks at the real wallclock time already.
• in general, it's impossible to handle L1 blocks whose time is lower than the L2 block time on a consistent basis, without incurring such wallclock drift.

Decisions:

• assume we're designing for post-merge
  • but expand the "empty block" fallback rule so that it's still able to emit L2 block for new L1 block (with deposits but no any sequenced transactions) to avoid a complete breakdown of the L2 chain on a L1 that can have 1s inter-block time (it just won't be able to process any sequenced transactions until the drift is back under control)
• drop the L1_1S_BLOCK_COUNT term — we can still change the rules in a L2 hard fork if a L1 hard fork change the L1 block time assumptions

Open questions:

• waiting for confirmation CAN be useful, i.e. to reduce the chances of L1-induced L2 reorgs, i.e. "increase the economic security/finality" of the L2 blocks
  • the trade-off is thus between increased economic security, and instant deposits as well as having a "fresh" L1 hashcode to prove things against

[trianglesphere]

Here is my proposal from this morning to modify the maximum permissible L2 block time to handle the case that L1 block times are less than L2 block times.

Timestamps / Epoch Size Proposal

• Each L1 block is associated with an epoch comprising one or more L2 blocks.
• L2 blocks timestamps are a multiple of L2_BLOCKTIME, and there is an L2 block every L2_BLOCKTIME.
• The deposits in the L1 block are included in the first L2 block of the corresponding epoch.
• Epochs have no fixed size (but comprise at least one L2 block).
• The following constraints apply to L2 block timestamps:
  • MIN_L2_TIME <= L2_TIMESTAMP < MAX_L2_TIME where
    • L2_TIMESTAMP is the timestamp of an L2 block
    • MIN and MAX are defined below
  • MIN_L2_TIME := PREV_L2_TIMESTAMP + L2_BLOCKTIME where
    • PREV_L2_TIMESTAMP is the timestamp of the previous L2 block
    • L2_BLOCKTIME is a configurable parameter of the time between L2 blocks
  • MAX_L2_TIME := max(L1_TIMESTAMP + MAX_SEQUENCER_DRIFT, MIN_L2_TIME + L2_BLOCKTIME) where
    • L1_TIMESTAMP is the timestamp of the L1 block associated with the the L2 block's epoch
    • MAX_SEQUENCER_DRIFT is the most a sequencer is allowed to get ahead of L1
• During block derivation, the following rules shall apply:
  • All batches must have a valid timestamp as specified above
  • MAXIMUM_L2_FILL := max(HIGHEST_VALID_BATCH_TIMESTAMP, NEXT_L1_TIMESTAMP, PREV_L2_TIMESTAMP + L2_BLOCKTIME)
  • There shall be an L2 block every L2_BLOCKTIME in the range [MIN_L2_time, MAXIMUM_L2_FILL)

Notes

• This is extend from previous proposals to handle batch submission. I think all previous proposals where missing this
• There's probably a little bit to figure out with the exact range / timestamps
• When L1 block time stabilizes back to be larger than L2 block times, this does catch up back to normal drift (i.e. sequencers cannot push L2 arbitrarily far into the future without running into problems)
• There is a version that uses an if statement instead of a max for the MAX_L2_TIME, but it has identical results in the worst case scenario. I'm not sure what it does in a typical scenario.

[norswap]

Took me a while to figure out, but the key differences are:

• reframing things in terms of the previous timestamp
• the right max term in MAX_L2_TIME := max(L1_TIMESTAMP + MAX_SEQUENCER_DRIFT, MIN_L2_TIME + L2_BLOCKTIME), which allows the sequencer to drfit more than MAX_SEQUENCER_DRIFT if encountering a 1s L1 block

I do think I'd like to see L2_TIMESTAMP >= L1_TIMESTAMP asserted explicitly, which as far as I can see does not contradict this design. (Am I right?)

During block derivation, the following rules shall apply:

I have a slight pushback on this, shouldn't we only derive things for which we have complete sequencing windows?

But beyond that, this is a strictly better proposal than the previous one, and doesn't add implementation complexity.

Great job! I think we have a winner 🔥🔥🔥

[trianglesphere]

Took me a while to figure out, but the key differences are:

• reframing things in terms of the previous timestamp
• the right max term in MAX_L2_TIME := max(L1_TIMESTAMP + MAX_SEQUENCER_DRIFT, MIN_L2_TIME + L2_BLOCKTIME), which allows the sequencer to drfit more than MAX_SEQUENCER_DRIFT if encountering a 1s L1 block

Yep, both are correct. We might be able to switch a little bit away from the previous timestamp, but the critical new term is the MAX_L2_TIME being either a max of drift time / next time (or could be an if statement, but I'm suspicious that the if statement I created reduces to max)

I do think I'd like to see L2_TIMESTAMP >= L1_TIMESTAMP asserted explicitly, which as far as I can see does not contradict this design. (Am I right?)

I think I've got it half right wrt this condition. It's applied through the derivation step, but not at the sequencer step.
I originally tried to incorporate this condition into a max statement, but it needs to be an AND (thus requiring something about previous L2 block).

During block derivation, the following rules shall apply:

I have a slight pushback on this, shouldn't we only derive things for which we have complete sequencing windows?

Maybe we can change "block derivation", but we do need to specify what happens to timestamps if there are no batches, or missing batches. The short summary of this proposal is pick the FILL_TO_L2_TIME to be <= the MAX_L2_TIME. If there are batches, and the highest batch is greater than the next L1 time, use that batch. If there are no batches / the batches do not make it to the next L1 block time, then go up to the L1 block time (to keep the L2 block time). And if we need to force a batch in b/c L1 is running faster, do that as well.

But beyond that, this is a strictly better proposal than the previous one, and doesn't add implementation complexity.

Great job! I think we have a winner 🔥🔥🔥

Thanks

[norswap]

I think I've got it half right wrt this condition. It's applied through the derivation step, but not at the sequencer step.
I originally tried to incorporate this condition into a max statement, but it needs to be an AND (thus requiring something about previous L2 block).

I'd just be happy for us to state, in the spec, that the given conditions do imply L2_TIMESTAMP >= L1_TIMESTAMP.

Maybe we can change "block derivation", but we do need to specify what happens to timestamps if there are no batches, or missing batches. The short summary of this proposal is pick the FILL_TO_L2_TIME to be <= the MAX_L2_TIME. If there are batches, and the highest batch is greater than the next L1 time, use that batch. If there are no batches / the batches do not make it to the next L1 block time, then go up to the L1 block time (to keep the L2 block time). And if we need to force a batch in b/c L1 is running faster, do that as well.

In the current process, the absence of batch data for a specific epoch just implies that all the blocks for that epoch are empty.

Since we are letting epoch size float, the question is how we should determine the size of "empty epochs". Is this right?

MAXIMUM_L2_FILL := max(HIGHEST_VALID_BATCH_TIMESTAMP, NEXT_L1_TIMESTAMP, PREV_L2_TIMESTAMP + L2_BLOCKTIME)

Alright, so untangling this a bit. MAXIMUM_L2_FILL gives you the timestamp after the timestamp of the last L2 block in the epoch currently being derived. Since L2 block time is constant, this lets you figure the size of the epoch.

Explaining the terms:

• NEXT_L1_TIMESTAMP is the timestamp of the L1 block following the one associated with the epoch
• PREV_L2_TIMESTAMP is the timestamp of the latest (highest timestamp) L2 block derived from the last epoch
• HIGHEST_VALID_BATCH_TIMESTAMP (don't love this name) is the timestamp of the latest L2 blocks committed to by a batch for the current epoch in the current epoch's sequencing window

Interpretation of the definition:

• If there are any L2 block specified in batches for the current epoch, just stop at the latest one...
• .... unless it's smaller the timestamp of the "next L1 block" (see definition above), then emit empty L2 blocks until you match NEXT_L1_TIMESTAMP - L2_BLOCK_TIME .
• Otherwise, if the last L2 block (see definition above) is ahead of the timestamp of the next L1 block, just emit a single L2 block for the epoch.

Since MAXIMUM_L2_FILL is supposed to be an "exluded bound", I think the formula needs to be:

MAXIMUM_L2_FILL := max(HIGHEST_VALID_BATCH_TIMESTAMP + L2BLOCKTIME, NEXT_L1_TIMESTAMP, PREV_L2_TIMESTAMP + 2 * L2_BLOCKTIME)

Imho, it would be cleaner to make it an inclusive bound and to redefine it as:

MAXIMUM_L2_FILL := max(HIGHEST_VALID_BATCH_TIMESTAMP, NEXT_L1_TIMESTAMP - L2_BLOCKTIME, PREV_L2_TIMESTAMP + L2_BLOCKTIME)