[WIP] All You Need to Know About One-Round Finality

# [WIP] All You Need to Know About One-Round Finality *TL;DR: Finalizing in one voting round is possible. This write-up gives an overview of the progress over the last two decades; explains why it might be particularly beneficial to Ethereum, and which challenges we are currently working on.* Ethereum currently takes about **16 minutes** to finalize a block: two epochs of 32 slots at 12 seconds each (≈12.8 min), plus half an epoch of waiting time in expectation (≈3.2 min). That's 16 minutes before bridges can safely relay a transaction, 16 minutes before an L2 can consider an L1 anchor settled, and 16 minutes of uncertainty for high-value transfers. Cutting this time is one of the most impactful improvements we can make to Ethereum's user experience and ecosystem. Recently, a wave of new protocols have shown that it's possible to finalize in a *single voting round*: [Alpenglow](https://drive.google.com/file/d/1Rlr3PdHsBmPahOInP6-Pl0bMzdayltdV/view?pli=1) & its academic twin [Kudzu](https://arxiv.org/abs/2505.08771), [Hydrangea](https://eprint.iacr.org/2025/1112), and [Minimmit](https://arxiv.org/abs/2508.10862), to name a few. In this post, we explain the core trick behind all of these protocols, trace how the idea evolved over the years, and discuss why Ethereum is uniquely positioned to benefit from it. ## Why Two Rounds? Most BFT consensus protocols work with [two voting rounds](https://decentralizedthoughts.github.io/2025-11-22-three-round-BFT/). Depending on the protocol, the first round is called *prepare*, *justify*, or *notarize*, and the second *commit* or *finalize*. We'll use *notarize* and *finalize* throughout.  ![](https://notes.ethereum.org/_uploads/ryxrGuhuw-x.png) Why two rounds? Intuitively, the first round establishes that enough validators have *seen* the block (a lock), and the second round establishes that enough validators *know that everyone has seen it* (a commit). This two-step dance is what makes it safe for validators to act on a decision, even if the network hiccups or the leader turns out to be malicious. If someone tells you their protocol can finalize in one round, you are right to be sceptical. Most protocols today require [two voting rounds](https://decentralizedthoughts.github.io/2023-04-01-hotstuff-2/).[^bounds] [^bounds]: In the standard model with fault tolerance of $n = 3f + 1$, this is not possible in the presence of an adversary. The exact lower bounds on the resilience required for one-round finality have been established by [Martin and Alvisi (2006)](https://www.cs.cornell.edu/lorenzo/papers/fab.pdf), [Dutta, Guerraoui and Vukolic (2005)](https://lpdwww.epfl.ch/upload/documents/publications/567931850DGV-feb-05.pdf), [Abraham et al. (2021)](https://eprint.iacr.org/2021/1138.pdf), and [Kuznetsov et al. (2021)](https://dl.acm.org/doi/pdf/10.1145/3465084.3467924). But here's the key observation: we design distributed systems to tolerate up to $f$ malicious validators. In Ethereum's case, safety is guaranteed as long as fewer than $f = 33\%$ of validators are malicious. And if safety *is* violated (e.g., a conflicting block is finalized), the protocol guarantees that at least $33\%$ of stake can be identified and [slashed](https://eth2book.info/capella/part2/incentives/slashing/) --- a property known as [accountable safety](https://arxiv.org/abs/1710.09437). [^accountable] This economic deterrent is a cornerstone of Ethereum's security model. [^accountable]: Other seminal work in this area include [Polygraph](https://eprint.iacr.org/2019/587.pdf), [BFT protocol forensics](https://dl.acm.org/doi/pdf/10.1145/3460120.3484566), and the [availability-accountability dilemma](https://arxiv.org/pdf/2105.06075). Most of the time though, validators [are online and behaving well](https://beaconcha.in/charts/participation_rate). We can expect to receive far more votes than just the $n - f = 67\%$ minimum. In practice, the beacon chain typically sees attestations from **more than 95%** of all validators in each epoch! This gap between the *worst case* we design for and the *common case* we observe is exactly what fast consensus exploits. ## Three Ways to Finalize in One Round Fast protocols can provide full economic finality guarantees in a single voting round. There are three ways [^options] to achieve this: [^options]: Here we consider only the standard BFT model. Different fault models (e.g., [corrupt-but-alive](https://arxiv.org/pdf/1904.10067)) expand the number of possible trade-offs.  1. **Same security, very optimistic.** We keep $f = 33\%$ tolerance, but finalize in one round only when *all* $100\%$ of votes arrive. If we only get $67\%$, we fall back to two rounds, as usual. 2. **Weaker adversary, always fast.** We lower our tolerance to $f < 20\%$, in which case we can always finalize in one round. 3. **Somewhere in between.** We pick a trade-off between safety, liveness and fast-path. For example, we can tolerate a slightly weaker adversary (e.g., $f = 30\%$), and in return finalize in one round under realistic conditions (e.g., when $95\%$ of votes arrive). When fewer votes arrive, we fall back to two rounds, or try to finalize again next round. Option (3) is an interesting option for Ethereum: most of the time a majority of validators participate, and if they don't, we might have a good reason to be cautious and not finalize. Therefore in this write-up we will focus on (3). ## The Core Idea So how does it work? The idea is surprisingly simple: every validator votes for the block it received. If *enough* votes for the same block arrive (the *optimistic condition*), you finalize immediately. If not, fall back to the standard two-round protocol. ![](https://notes.ethereum.org/_uploads/rJrXd3uwZl.png) The threshold for "enough" is controlled by a parameter $p$: the number of votes that can be *missing* and still allow the fast path to work. The fast path triggers when $n - p$ votes are collected for the same block. In pseudocode: ``` // fast path if n - p votes are received for B: finalize B // slow path (fallback) if n - f votes are received: let B = block with the most votes run standard consensus on B finalize the result ``` This dual-path approach was introduced by [Kursawe (2002)](https://ieeexplore.ieee.org/abstract/document/1180196), [Dutta, Guerraoui and Vukolic (2005)](https://lpdwww.epfl.ch/upload/documents/publications/567931850DGV-feb-05.pdf), [Martin and Alvisi (2006)](https://www.cs.cornell.edu/lorenzo/papers/fab.pdf) and [Song and van Renesse (2008)](https://research.cs.cornell.edu/projects/Quicksilver/public_pdfs/52180438.pdf). Every recent protocol builds on the same foundation; the improvements are in the details.[^sync] [^sync]: This write-up focuses on partially synchronous protocols. There exist cousins in the synchronous model too, such as [Thunderella](https://eprint.iacr.org/2017/913.pdf) and [OptSync](https://eprint.iacr.org/2020/458.pdf). ## Why Is This Safe? This is the crucial question. If one validator fast-finalizes a green block, but others didn't see enough green votes and fell back to slow consensus, could they finalize a *different* block? Let's walk through a concrete example with $n = 4$ validators, $f = 1$, and $p = 0$ (meaning we need all $n - p = 4$ votes to fast-finalize). ### The happy case The proposer sends the green block to everyone. All four validators vote green. One validator collects all 4 green votes and fast-finalizes. ![](https://notes.ethereum.org/_uploads/ryxG4d3_wZg.png)  But what about the other validators? Before running the fallback, every honest validator receives at least 3 votes. Out of these, at most one can be malicious. Thus every honest validator will observe a majority of green votes. When they enter the fallback, they all propose the green block. Since all honest validators propose the same value, green is decided. ![](https://notes.ethereum.org/_uploads/HJg5Vunuwbe.png)  The key insight: if *any* validator sees $n - p$ votes for green (fast-finalizing it), then *every* honest validator must have seen a majority of green votes. This means the fallback can never contradict the fast path. Safety is preserved. In PBFT-like protocols, for example, the fallback would consist of a *view change*: a rotation to the next pre-determined leader. Each validator broadcasts a view-change message containing its latest vote, and the protocol requires the new leader to propose whichever block accumulated the most votes across those messages. Since every honest validator has seen a majority of green votes, the new leader is forced to propose green --- fast-finalized and slow-finalized values are guaranteed to agree.  ## How the Idea Evolved The basic idea has been refined over two decades. Here we highlight one key contribution per line of work.  ### Parametrization: [FaB Paxos](https://www.cs.cornell.edu/lorenzo/papers/Martin06Fast.pdf) and [DGV](https://infoscience.epfl.ch/server/api/core/bitstreams/19ce5930-31af-4489-9551-d5d014b8c1f1/content) [Martin and Alvisi](https://www.cs.cornell.edu/lorenzo/papers/Martin06Fast.pdf) established the parametrization still commonly used today. They show: - If $n \geq 5f + 1$ (so $f < 20\%$), we can safely fast-finalize with just $n - f$ votes, no extra threshold needed. - More generally, with the parameter $p$: as long as $n \geq 3f + 2p + 1$, we can fast-finalize after $n - p$ votes. This gives system designers a tunable knob: trade adversary tolerance for a more achievable vote threshold. In addition, [Dutta, Guerraoui and Vukolic](https://lpdwww.epfl.ch/upload/documents/publications/567931850DGV-feb-05.pdf) provide a more general parametrization in the Paxos model and notice that resilience can actually be improved, as we will see in the next section. ### Better Resilience: [Kuznetsov, Tonkikh, and Zhang](https://dl.acm.org/doi/pdf/10.1145/3465084.3467924) and [Abraham et al.](https://arxiv.org/pdf/2102.07240) Can we do even better than FaB, that fast finalizes a block after seeing 4 out of 4 votes? Can we fast finalize after just 3 out of 4 votes? ![](https://notes.ethereum.org/_uploads/BklrHd2uw-l.png)  At first glance, no. A node might see 3 green votes and fast finalize the green block. If the proposer is malicious and sends different blocks to different validators, a node might see 1 green and 2 red votes in the same execution, and would naively propose the majority color to the fallback. The fallback might decide red, leading to a safety violation: ![](https://notes.ethereum.org/_uploads/rJb3Bd3uvZe.png)  The fix is elegant: **equivocation detection**. If a validator sees votes for *both* a valid red and a valid green block, that's irrefutable evidence the proposer is Byzantine. The validator can wait for one more vote to break the tie, and then act correctly: ![](https://notes.ethereum.org/_uploads/rJVUd3uvbg.png)  This yields a tighter lower bound: we can fast-finalize after $n - p$ votes, as long as $n \geq 3f + 2p - 1$.[^bound] [^bound]: This requires $p \geq 1$, to not go against the BFT lowerbound. In other words, we get a better fast path "for free".  ### Linear Complexity: [SBFT](https://arxiv.org/abs/1804.01626) Over the years, many protocols added a fast path ([Zyzzyva](https://dl.acm.org/doi/pdf/10.1145/1658357.1658358), [Aliph](https://dl.acm.org/doi/pdf/10.1145/1755913.1755950), [Zelma](https://arxiv.org/pdf/1801.10022), among others). [SBFT](https://arxiv.org/abs/1804.01626) showed how to achieve the fast path with **linear message complexity**, by using signature aggregation at the leader. Approaches like these are essential for large validator sets like Ethereum's. ### Simplex Integration: [Banyan](https://arxiv.org/abs/2312.05869), [Kudzu](https://arxiv.org/abs/2505.08771), and [Alpenglow](https://www.anza.xyz/alpenglow-1-1) The [Internet Computer Consensus](https://eprint.iacr.org/2021/632) and [Simplex](https://eprint.iacr.org/2023/463) protocol family introduce the idea that every node exits each view with a certificate, which makes the protocol simpler and easier to reason about. [Banyan](https://eprint.iacr.org/2024/1227) renewed general interest in one-round finality by showing that a fast path is possible for the ICC protocol in the $3f + 2p - 1$ model, and showed practical benefits. [Kudzu](https://arxiv.org/abs/2505.08771), based on Simplex, achieves a simpler protocol with improved message complexity, and is the first protocol to combine one-round finality with erasure-coded broadcast [^kudzu], critical for both latency and throughput. [^kudzu]: Kudzu inherits its propagation mechanism from [DispersedSimplex](https://eprint.iacr.org/2023/1916.pdf), which itself builds on a long line of work on [erasure coded broadcast](https://decentralizedthoughts.github.io/2024-08-08-vid/), popularized by [Turbine](https://solana.com/news/turbine---solana-s-block-propagation-protocol-solves-the-scalability-trilemma). [Alpenglow](https://www.anza.xyz/alpenglow-1-1) uses a similar voting scheme but extends erasure-coded dissemination to PoS, and decouples it from voting. The added latency is compensated by leveraging the gained equivocation detection (assuming granular synchrony) to tolerate $20\%$ crash faults on top of 20\% Byzantine faults. ### Crash Faults: [Hydrangea](https://eprint.iacr.org/2025/1112) Real networks don't just have malicious nodes, they have nodes that crash, lose connectivity, or fall behind. [Hydrangea](https://eprint.iacr.org/2025/1112) extends the model to include crash faults. When the number of nodes is larger than $3f+2k+c+1$, the fast path tolerates $p=(c+k)/2$ faults, and the slow path can handle both $f$ byzantine and $c$ crashed nodes.  ### No Slow Path at All: [Minimmit](https://arxiv.org/abs/2508.10862) [Minimmit](https://arxiv.org/abs/2508.10862), another Simplex based protocol, takes option (2) to its logical conclusion: if we accept $f < 20\%$, we can *always* finalize in one round and don't need a slow path at all. Without a slow path, the notarization quorum only has to intersect with the fast finalization quorum of $n - f$. This means notarization only requires $2f + 1$ votes (compared to $3f + 1$ in Kudzu). The result is faster block production, at the cost of potentially slower finalization when the optimistic conditions aren't met. ### Sharding: [Consensus on Demand](https://arxiv.org/pdf/2202.03756) and [Mangrove](https://arxiv.org/pdf/2509.06616) Going back to the dual-path design from the [Core Idea](#the-core-idea) section, it was noted that the fallback can be executed [on Demand](https://arxiv.org/pdf/2202.03756), i.e., only when it's needed, instead of always incurring its cost. [Mangrove](https://arxiv.org/pdf/2509.06616) extends this idea to provide one-round finality in a fully sharded (horizontally scalable) system, and shows that the fast path can even work for cross-shard transactions.  ## Why Ethereum Is Uniquely Positioned ### Voting Rounds Dominate Latency Ethereum has the [largest validator set (and node count)](https://dl.acm.org/doi/epdf/10.1145/3771572) of any blockchain. Even with vote propagation parallelized across 64 subnets, a voting round currently takes more than **6 minutes**. We expect that this number can be considerably improved through novel networking primitives. In most other systems, block propagation takes comparable time to voting, so saving one voting round yields at most a $33\%$ improvement [^imp]. In Ethereum, voting dominates, so saving a round could yield up to a **40% speedup** in finalization time (in expectation finalization moves from 2.5 to 1.5 voting rounds). [^imp]: Some protocols (like Alpenglow) run the fast and slow paths simultaneously, waiting for whichever completes first. In geo-decentralized settings the fast path typically wins, but if many nodes are co-located, two voting rounds among a smaller validator set (e.g., $60\%$) can be faster than one round among a larger set (e.g., $80\%$). In such cases, a fast path does not improve latency. Ethereum's design, with fixed-duration slots, means voting rounds happen sequentially rather than concurrently.  ![](https://notes.ethereum.org/_uploads/H1RsI6Rq-g.png) Nodes willing to participate in many subnets might be able to collect attestations faster than regular (bandwidth restricted) nodes. With one-round finality, these supernodes can potentially spread an certificate of finality even before the voting round is over. In other words, one-round finality also allows for optimistic networking designs that can cut time to finality further. ![](https://notes.ethereum.org/_uploads/H10-vpR5Zg.png) ### High Participation Rates Ethereum slots have a fixed duration, in part to give even remote validators the chance to send a vote in time. This means that Ethereum already consistently captures **[more than 95% of attestations](https://lab.ethpandaops.io/ethereum/consensus/overview)** per epoch. This is exactly the regime where the fast path shines: option (3) from above works when most validators participate, and Ethereum already satisfies this condition in practice.  ### Finalization Thresholds and Veto Power Ethereum's current finality threshold is $67\%$, meaning $33\%$ of validators can block finalization. Raising this threshold (e.g., to $80\%$ or $83\%$) can actually be desirable, as Vitalik pointed out [here](https://x.com/VitalikButerin/status/1993439679081857433) and [here](https://x.com/VitalikButerin/status/2029994081582207235). The intuition: a $17$--$20\%$ minority could halt finality in response to a critical bug or a controversial fork, serving as a safety valve. A minority could also halt finality in the face of censorship, forcing a period of non-finality in which two chains compete. In other words, raising the finality threshold can make finality *stronger*, not weaker. It does come with drawbacks that we are working to overcome, we will share exciting progress soon. Crucially, a higher threshold also *improves* the trade-off for one-round finality. The reduced liveness means we get to in turn improve economic safety, or obtain a simpler protocol. We are actively exploring these two directions.  ## What's Next? With these principles in mind, we have been working on new flavors of one-round finality specifically tailored for Ethereum --- one piece of a broader effort, alongside other consensus and networking improvements, as well as validator consolidation, to dramatically cut Ethereum's finality time. Integrating one-round finality into a finality gadget — one that also handles fork-choice interaction and the ebb-and-flow construction required by Ethereum — is an active area of research, and the right design choices here are still being worked out. The design space is rich. Here is a preview of what we have been working on: - **Economic security trade-off.** Do we need to give up any economic security for a faster finality? We have been working on a new parametrization that improves the trade-off — stay tuned. - **Raising the finality threshold.** What happens when the threshold goes to $80\%$ or above? Can we provide some safety during periods of non-finality? - **Ebb-and-flow interaction.** How can a one-round finality gadget best be combined with an available chain? - **The path to deployment.** What are the right intermediate steps to bring fast finality to Ethereum, and in which order? We'll have more to say on this soon. **Watch out for what's ahead --- and let's ship Fast Finality for Ethereum!** --- *Thank you to Francesco D'Amato, Vitalik Buterin, Ben Edgington, Roberto Saltini, and Luca Zanolini from the EF Consensus Team, as well as Ittai Abraham, Kartik Nayak, Alejandro Ranchal-Pedrosa, and Roger Wattenhofer for their valuable comments and feedback.*

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.