Finality

Table of Contents

The Celo L2 provides two layers of economic security - the Celo-economic security and Ethereum-economic security. Celo-economic security is the security the L2 blockchain provides until data has been written to a L1 block and that block has been finalized. In order to provide reorg resistance at Celo-economic security in the L2 design, we need to address two sources of possible reorgs:

  1. Avoid discrepancies in what the sequencer shares over the p2p network and posts to the L1.
  2. Avoid those caused by Ethereum reorgs.

Finality and Reorgs in Optimism

Optimism L2 blocks have three levels of finality:

  • Unsafe: Blocks are shared by the sequencer over the p2p network and can be reorged with no penalty.
  • Safe: Blocks are deterministically derived from inputs and L2 data posted to not-yet-finalized Ethereum blocks. These blocks are susceptible to Ethereum reorgs.
  • Finalized: Blocks are derived from finalized blocks on Ethereum and can practically not be reorged without massive economic costs. This is Ethereum-economic security.

Once a L2 block is finalized, it has the same security guarantees as the underlying L1 and are highly unlikely to be reorged. Therefore, our focus lies on avoiding reorgs at the unsafe and safe levels.

Unsafe head reorgs could happen in the following scenarios:

  • The sequencer shares an unsafe block on the p2p network but misses the sequencing window to post the corresponding transaction data to Ethereum. As a result, there won’t be a valid block data for that height, and the safe head will reorg to use a generated empty block.
  • The sequencer distributes an unsafe block on the p2p network but posts a different transaction data for the same block height to Ethereum, the safe head will reorg to use the data on Ethereum.

These cases are controlled by the sequencer. So if the user trust the sequencer and it's actions it can follow unsafe blocks. If not, it can completely avoid those blocks by only following safe blocks.

Safe head reorgs can occur in the following situations:

  • An L1 block is reorged, then the corresponding sequencing epoch’s blocks will need to be updated to account for the changes in the L1 origin (specifically, deposit transactions). This situation can also cause an unsafe head reorg.
  • If Ethereum reorgs such that transaction data posted either no longer exists or now falls outside of the sequencing window, then the corresponding (previously safe) L2 block will become an empty block.

Mitigating Ethereum Reorgs

Essentially, we need to mitigate Ethereum reorgs that affect L1 deposit transactions to prevent reorgs on Celo L2.

To do this, we modify the L1 origin used in the sequencer to follow only finalized blocks on Ethereum. This behavior can be opted into by setting the --sequencer.use-finalized flag on the op-node instance that sequences new blocks. In the sequencer, the L1 origin will still be incremented in steps of one, so that all invariants relying on this behavior in the Optimism codebase are kept.

Only using finalized blocks has the downside of increasing the time for user-deposited and (native) bridging transactions to be included in the L2 from currently 4 blocks (48 seconds) to at least 2 Ethereum epochs (64 slots, 12.8 mins). This doesn’t apply to optimistic bridges, so it most likely won’t hurt user experience in general.

There is also a possible problem if the Ethereum L1 fails to finalize blocks. In that case the sequencer would continue to create unsafe L2 blocks. Therefore, in that case the sequencer must stall and avoid producing blocks until L1 finalization catches up to below some threshold.