3-Slot-Finality Protocol for Ethereum

TL;DR

A partially synchronous finality gadget is introduced, which is combined with two dynamically available consensus protocols -- synchronous protocols that ensure safety and liveness even with fluctuating validator participation levels and results in secure ebb-and-flow protocols [SP 2021], achieving finality within three slots after a proposal and realizing 3-slot finality.

Abstract

Gasper, the consensus protocol currently employed by Ethereum, typically requires 64 to 95 slots -- the units of time during which a new chain extending the previous one by one block is proposed and voted -- to finalize. This means that under ideal conditions -- where the network is synchronous, and all chain proposers, along with more than two-thirds of the validators, behave as dictated by the protocol -- proposers construct blocks on a non-finalized chain that extends at least 64 blocks. This exposes a significant portion of the blockchain to potential reorganizations during changes in network conditions, such as periods of asynchrony. Specifically, this finalization delay heightens the network's exposure to Maximum Extractable Value (MEV) exploits, which could undermine the network's integrity. Furthermore, the extended finalization period forces users to balance the trade-off between economic security and transaction speed. To address these issues and speed up finality, we introduce a partially synchronous finality gadget, which we combine with two dynamically available consensus protocols -- synchronous protocols that ensure safety and liveness even with fluctuating validator participation levels. This integration results in secure ebb-and-flow protocols [SP 2021], achieving finality within three slots after a proposal and realizing 3-slot finality.

Figures (3)

• Figure 1: Example of justification. The figure illustrates the progression of justified checkpoints over four slots. The checkpoints are presented from left to right, indicating an increase in the checkpoint slot $c$. Within each checkpoint slot, the proposal slot $p$ decreases from top to bottom. This visualization is based on the assumption that all justifications occur through votes with consistent source and target, as shown by the arrows. Chains labeled $A, B, C,$ and $D$ are proposed in slots $0, 1, 2,$ and $3$, respectively, with each chain extending the previous one. Specifically, at slot 2, votes originating from the source checkpoint $(A,1)$ and targeting checkpoint $(B,2)$ result in the justification of both checkpoints $(B,2)$ and $(A,2)$. Slot 3 does not see any checkpoint justification. However, in slot 4, checkpoints containing chains $B, C,$ and $D$ are justified. This justification is achieved through votes with the source $(B,2)$ and the target $(D,4)$.
• Figure 2: The figure illustrates an example of surround voting, where the slashable votes are highlighted in red. In this scenario, from slot 4 to slot 3, the source checkpoint shifts "backwards" from $(C,3)$ to a lower checkpoint $(B,3)$. This instance of surround voting is unique to this protocol and does not occur in Casper-FFG casper, due to the two source checkpoints sharing the same checkpoint slot.
• Figure 3: Slot $t$ of the protocol, with its four phases.

Theorems & Definitions (199)

• Definition 1: Safe protocol
• Definition 2: Live protocol
• Definition 3: Secure protocol goldfish
• Definition 4: Dynamic Availability
• Definition 5: Reorg Resilience
• Definition 6: Accountable Safety
• Definition 7: $\eta$-secure ebb-and-flow protocol
• Definition 8: $\eta$ Asynchrony Reorg Resilience
• Definition 9: $\eta$ Asynchrony Safety Resilience
• Lemma 1