Fast finality for rollups

One of Celestia's main goals is to scale rollups by providing maximal data throughput. When scaling data throughput, light node requirements can become bloated by faster block times. Since a tradeoff exists between block times and light node overhead, a happy medium needs to be found. For Celestia, the search for that happy medium led to a current block time of 15 seconds.

The consequence of slightly slower block times is that rollups inherit it for their finality. But some applications may require faster finality for their features or performance. Rollups can only be as slow as Celestia's block times, right? Not quite.

Single sequencer

First, there are two notions of finality that a rollup transaction can experience.

  • Soft finality: Confirmation from a sequencer or group of sequencers that your transaction will get included in a block on Celestia.
  • Firm finality: Confirmation from Celestia that your transaction was included in a finalized block.

The guarantee that soft finality can provide users is that a sequencer promises to include your transaction in a block on Celestia. If they don't include your transaction, then they will get punished in some fashion.

Right now, rollups with single sequencers can easily provide soft confirmations – they are the only block producer. These confirmations can be provided by sequencers in under a second. However, if there is no accountability mechanism for the sequencer to get punished if it acts dishonestly, the soft confirmation can only provide a weak form of soft finality. Since virtually no rollups have staked sequencers, they can’t get punished if they give a soft confirmation for a transaction and don’t include it in the next block.

But single sequencers are only an intermediate step. Soft confirmations for faster finality is more relevant (and interesting) in the context of a decentralized rollup.

Decentralized sequencers

There’s a wide design space for sequencer decentralization. For now, I’m going to look at soft confirmations for two decentralized sequencer mechanisms.

PoS leader election

Quick background, PoS leader election works exactly as it sounds. Each node stakes some tokens to participate in the sequencer set. The sequencers come to consensus on the leader schedule in advance. When it is a sequencer’s turn to produce a block, as determined by the schedule, it will build its block and submit it to Celestia. There is no BFT consensus among the validators once a new block gets built. We’re implementing something similar in the first version of decentralized sequencers for Rollmint.

In this scenario, the sequencer can provide a soft confirmation for a user once it builds a block with their transaction. The soft confirmation acts like a promise that they will include it in a Celestia block. Since the sequencers are now staked, they can be held accountable if they provide a soft confirmation and don’t end up including the user’s transaction in the next block.

One way that the soft confirmations could work is that the sequencer builds a block and propagates it through the rollup p2p network. At some point, the sequencer will also publish the block to Celestia. Nodes can verify a mismatch between the block they verified on the p2p network and the block that got published to Celestia. The mismatch proves that the sequencer signed two blocks, so they could get punished via slashing.

Now applications can get economic guarantees behind their soft confirmations, allowing them to operate under fast finality.

BFT consensus

An alternative mechanism for decentralizing sequencers is to use an existing BFT consensus mechanism, like Tendermint. If Tendermint were used to provide firm finality on the rollup, its security would be no different than an L1 that relies on honest majority consensus. The rollup should use a modified version of Tendermint so that it is only responsible for soft confirmations. By doing so, the rollup still relies on fraud/validity proofs and Celestia for security.

In this scenario, a sequencer builds a block and proposes it to the rest of the sequencers. The sequencers conduct some number of rounds of voting on the block. If a user received a soft confirmation for their transaction and it didn’t get included in a Celestia block, then the votes are evidence of double signing. Since they are also staked, the sequencers can get slashed.

The tradeoff between using PoS leader election and BFT consensus mostly encompasses sequencer overhead vs implementation time. A PoS leader election mechanism is much leaner and poses less overhead for sequencers than BFT consensus. But decentralizing the sequencers via an existing consensus mechanism could be implemented quicker than the custom leader election mechanism.

What applications might require fast finality?

There may exist a few types of applications that require fast finality. Two come to mind:

  • DEXs are the most obvious since finality has implications across the whole trading dynamic. Faster finality allows trades to clear quicker, and searchers can conduct more frequent arbitrages, resulting in better execution prices for users and more accurate asset prices.
  • Lending protocols may also want faster finality so that liquidations can get cleared quicker. Faster liquidations reduce the amount of time asset prices can move, which means less likelihood of the lending protocol accruing bad debt. The longer it takes to finalize a liquidation, the greater the potential for an asset price to drop, which could leave the protocol with bad debt.

Most applications don't require fast firm finality (think sub-second). There's likely only a small niche of applications that may require fast finality, and most of those should be suitable for the notion of fast finality that a rollup can provide.