Commit to specific chain in batch & output submissions

[trianglesphere]

I think that we should be committing (i.e. reference a block hash of L1 or L2) to a specific L1/L2 chain in batch & output submissions. This is to handle re-orgs / missed submissions.

Batch Submissions

Batches are currently groups of transactions that are part of a block. As ethereum transactions are stateful, transactions can have very different behavior depending on the result of previous transactions. Approaches like nonces & chain ID limit what re-orgs can do to batch submissions, but it is possible to construct scenarios like the following.

Transaction A writes to a storage spot x. Transaction B reads from the storage spot x. If it is set, it exits, if not it uses up the rest of the gas in the block.
Suppose transaction A is included in batch 1 and transaction B as the first transaction in batch 2. If batch 1 is re-orged out & batch 2 included, the rest of the batch 2 is now invalid.

There are many similar problems, but the essence is that a set of transactions in the block may only be valid depending on the start state. As such, batches should commit to the start state (or previous batch which serves the same effect).

Output Submissions

Output submissions are currently the state root. If there is a re-org, you could challenge a previous valid state root (or it could go across chains if not using chain ID).

How to commit to a chain

There are two levels that we could do the chain commitment at

1. Inside the L1 transactions (i.e. commit to a specific L1 block). Note that this requires us to get the transaction included in a specific block or it is always invalid
2. As metadata in the commitment.

For metadata in the commitment, it would be something similar to: output root, L2 block hash or batch, previous L2 block. Note, we can either commit to an L1 block or and L2 block, but committing to an L2 block in effect commits to an L1 block.

Open Questions

Which commitment method is sufficient with the least overhead?
Is committing to an L2 block good enough? - I think so, but need to think through the mechanics more carefully.

[norswap]

Batch Submission

Someone corrects me if I'm wrong, but I think we're fairly committed to the fact we want to drop as few transactions as possible whatever happens.

Arbitrum also makes a big deal about this, see for instance this thread by Daniel Goldman.

To replay in case of a L1 reorg, it suffices to resubmit the batches. If we stick a L1 blockhash in there, only the sequencer is allowed to do this. Alternatively, if we give each batch his own hash, we could also have each batch reference the previous batch. Then anyone would be able to resubmit batches.

Note that the sequencer-only solution has the advantage that the sequencer can now make different batches.

In any case, if we accept the premise that we want to at least try replaying, then we can't really avoid the kind of problems you're mentionning. The issue is that after a re-org, people are free to stick new deposits on-chain, and therefore change the chain state for the replay batches.

In the sequencer-only solution, we can at least avoid transactions "falling off the end of a block". However, we can't avoid deposits changing the state, which causes batch tx to consume much more gas, which causes the basefee to increase and causes subsequent batch tx to fail because the maxfee is exceeded.

Another question is whether we want to make this replay a "guarantee". The sequencer-only solution offers no guarantee (it depends on the sequencer being honest). The permissionless replay does, because if the sequencer changes a batch following another batch, then someone can post the old batch, and the sequencer can be slashed for this offence.

Personally I like the permissionless replay solution better: it offers a guarantee that we'll try a best-effort approach to try to replay existing transactions, in the order in which they initially appeared.

Deposits and damn MEV

Quick remark here, it's that in the case of a re-org, it becomes very interesting to do MEV via deposits sent before the batches can be replayed. This not only allows "stealing" MEV opportunities on L2, but furthermore enables more, because it allows sticking transaction within the chain history, where the subsequent transaction (from the replayed batches) are already known.

This is made extra bad by the fact because we stick deposits in the first block of an epoch. We could consider sticking them at the end instead, and that would at least prevent deposits to front-run transactions whose batches land in the same block as the deposit. Only a small mitigation, doesn't actually solve/prevent the underlying issue.

Output Submission

I don't see why committing to the blockhash of the last L2 block in the last epoch wouldn't be sufficient. May want to add the epoch number for simplicity, but not strictly necessary since it is contained within the L2 block.