# 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.
<!-- Diagram: PROPOSE → NOTARIZE → FINALIZE, showing the standard two-round pipeline -->
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.
<!-- TODO [diagram suggestion]: A 2x2-style diagram or table showing the three options:
Option 1: f=33%, need 100% votes (same security, very optimistic)
Option 2: f<20%, need 67% votes (weaker adversary, always works)
Option 3: f=30%, need 95% votes (slightly weaker adversary, realistic optimism)
With the axes being "adversary tolerance" vs "vote threshold needed" -->
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.
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.
<!-- Diagram: green block proposed → 4 green votes → checkmark at fast path -->
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.
<!-- Diagram: green block proposed, one red vote (malicious), but green still wins in fallback → checkmark -->
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.
<!-- More generally, in PBFT-like protocols, the view change mechanism can enforce this: the next leader must propose the block with the most votes, backed by the view change messages it received.-->
## How the Idea Evolved
The basic idea has been refined over two decades. Here we highlight one key contribution per line of work.
<!-- TODO [diagram suggestion]: A timeline visualization showing:
2002 Kursawe → 2004 Vukolic → 2006 FaB Paxos → ... → 2021 SBFT → ... → 2025 Kudzu/Alpenglow/Hydrangea/Minimmit
with the key contribution of each labeled -->
### 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?
<!-- Diagram: green block, only 3 green votes, checkmark at fast path -->
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:
<!-- Diagram: red block, red votes dominating, X mark (safety violation) -->
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:
<!-- Diagram: mixed red/green, dashed diamond (detected equivocation), then correct resolution → checkmark -->
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".
<!-- [^concurrent]: [Dutta, Guerraoui and Vukolic (2005)](https://infoscience.epfl.ch/server/api/core/bitstreams/19ce5930-31af-4489-9551-d5d014b8c1f1/content) have established similar bounds.!-->
### 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 inherts 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.
<!-- in the slow path examines crash fault tolerance in more detail, presenting a model that tolerates crash faults under partial synchrony alongside the fast path. -->
### 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.
<!--The fast path can even work for cross-shard transactions in sharded systems, where a fallback is only applied when needed (or [on Demand](https://arxiv.org/pdf/2202.03756)). -->
## 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 roughly a $33\%$ improvement. 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).
<!-- TODO [diagram suggestion]: A bar chart comparing time breakdown:
Current: [block propagation | voting round 1 | voting round 2] = ~13 min
With fast path: [block propagation | single voting round] = ~7 min
with supernode fast path: TODO -->
Supernodes can often collect attestations faster than regular nodes. With one-round finality, supernodes can potentially spread an certificate of finality even before the voting round is over.
In other words, it allows for optimistic networking designs.
### 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.
### Sequential Voting Maximizes the Benefit
Some protocols 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\%$).
Ethereum's design, with fixed-duration slots, means voting rounds happen sequentially rather than concurrently. This makes saving an entire round more valuable.
### Finalization Thresholds
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).
To recap: Firstly, a $17$--$20\%$ minority could halt finality in response to a critical bug or a controversial fork. Secondly, a minority could also halt finality in case of censorship, causing a period of non-finality, in which two chains are competing.
In other words, raising the finality threshold can make finality stronger! It does come at some drawbacks, which we are trying to overcome in our newest work, which we will share soon.
So to recap, we are considering a higher finalization threshold. This is really interesting, because a higher finalization threshold also *improves* the trade-off for one-round finality! The result is better economic safety, a more achievable fast path, and a cleaner protocol. We are actively exploring this direction, more to come soon.
<!-- TODO: expand on how the veto power / high threshold argument works in detail ? -->
## 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 (TODO: as outlined in Luca's post) — 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? We have a paper in the works on this too.
- **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 Luca Zanolini, Roberto Saltini, Ben Edgington, and Francesco D'Amato from the EF Consensus Team, as well as Ittai Abraham, Kartik Nayak, Alejandro Ranchal-Pedrosa, and Roger Wattenhofer for their valuable comments and feedback.*