There's a question lurking underneath a lot of blockchain engineering that sounds almost too simple to be worth asking: when a transaction lands on a chain, how long until you can be sure it's never coming back off? Not "probably safe" but truly, irreversibly done.

For Ethereum today, the honest answer is somewhere around 13 to 16 minutes. For a Byzantine fault tolerant consensus engine like CometBFT, it's a second or two. That's an enormous gap, and it raises an obvious question: why doesn't Ethereum just do whatever CometBFT does and finalize fast too?

As it turns out, Ethereum desperately wants to. It has a multi-year research program and a string of planned hard forks aimed squarely at the goal, and it's finding the whole thing genuinely hard. The reason comes down to a single number. Ethereum has over a million validators; CometBFT-based chains run with a few hundred. The answer lives in a protocol called 3-Slot Finality, or 3SF, and in a stubborn physical bottleneck that turns out to be the whole story.

A Quick Recap on the Problem

To see why a million validators changes everything, it helps to hold the shape of Ethereum's finality story in your head. Its post-Merge consensus, Gasper, doesn't finalize a block the moment it shows up. A block earns a kind of provisional confirmation as votes pile up, but true, irreversible finality doesn't arrive until two of these voting cycles have passed, which is roughly 13 to 16 minutes. During that window, a block you thought was settled can still get reorganized away.

For sending tokens around, that delay is tolerable. For a rollup-centric future, where Ethereum is meant to be the settlement layer sitting underneath dozens of Layer 2s, it's a real bottleneck. As long as L1 takes fifteen minutes to finalize, any L2 sequencer or bridge offering faster "pre-confirmations" has to personally absorb the risk that those blocks get reorganized during that window. The fix everyone agrees on is to go after the problem at the protocol level: make the base layer itself finalize fast. The disagreement is about how.

Finalize in One Round

The intuitive answer is Single Slot Finality (SSF): take the vote-it-and-lock-it-in process that CometBFT already runs, and squeeze the whole thing into a single slot, so a block is proposed and finalized in one shot.

This is essentially what CometBFT pulls off, and Ethereum's proposed Minimmit design is its own version of the same one-round idea. CometBFT runs each block through a short, structured round of voting, and the block is final by the time it ends, with no waiting around for confirmations to accumulate. So if a one-round design like that is good enough to finalize blocks in a second on more than a hundred live chains today, the obvious question writes itself: why can't Ethereum just adopt it and be done?

A Million Validators

CometBFT-based chains typically run with somewhere between 50 and 175 validators. Ethereum's Beacon Chain has over a million.

That single difference changes everything, and the reason comes down to how voting works. For the network to agree on a block, validators have to tell each other how they voted. With a couple hundred of them, each one can just announce its vote to everyone else and nobody breaks a sweat. The trouble is that the number of messages doesn't grow gently as you add validators. It explodes. Think of a room where everyone has to shake hands with everyone else: five people is ten handshakes, but a thousand people is nearly half a million. A million validators all messaging each other directly would melt the network instantly.

So Ethereum doesn't let them. Instead, votes flow through aggregators, special nodes that work like a delegate for each table at a vast banquet. Rather than every guest shouting across the hall, each table's delegate collects the nearby votes, bundles them into one compact summary, and passes just that summary onward. Thousands of individual votes go in; one combined message comes out. That bundling is the only thing that makes agreement among a million validators thinkable at all.

Cost of Aggregation

Bundling solves the message explosion, but it quietly adds a delay, and that delay is the reason fast finality is so hard.

Think about what an aggregator actually has to do. First it waits to collect the votes coming in, which take time to travel across the network. Call one such network trip a delay, written Δ. Then it broadcasts the bundled-up result, which takes another Δ to reach everyone. So a round of voting that looks like it should cost one Δ really costs two, once you count both the gathering and the sending back out.

Now stack those costs up, as in the diagram above. A single-slot design needs a block proposed, then two separate rounds of voting (one to agree on the block, one to lock it in), and a final acknowledgment. With aggregation doubling each voting round, the whole thing comes to six network delays crammed into a single slot. And six Δ is a lot to fit into a few seconds. If the network slows even slightly, the slot runs out of time, the round fails, and the chain stalls. That's the trap that has kept true single-slot finality "great on paper, miserable in practice" for years. It's exactly the problem 3SF was built to escape.

Pipelining Trick

3SF's insight is to stop trying to fit everything into one slot. Instead of cramming all the voting into a single slot, it spreads the work across three consecutive slots and runs them like an assembly line, each block advancing to the next stage as a fresh one enters the first.

The clever part is how it avoids piling on extra messages. Older designs make every validator cast two separate votes per slot: one to pick the chain's head, one to push finality forward. 3SF folds them into a single vote that does both jobs at once: one message that says "this is the block I'm building on" and, at the same time, "I've seen enough agreement on the previous block to treat it as locked in." Half the traffic, same information.

Across the relay, a block moves through three stages. It's proposed and fast confirmed in the first slot, justified in the second as its votes get carried forward, and finalized in the third, written to irreversible history. Finality just trails the chain tip by a couple of slots.

There's a nice property hiding in that first step. Fast confirmation already makes a block economically safe well before it's technically final, because reversing it would require more than a third of all validators to vote two ways at once and get themselves penalized for enormous sums in the process. So for an everyday user, an exchange, or an L2 sequencer, the practical wait is short even though formal finality takes three slots.

One more trick keeps the relay from dropping the baton. Just before each vote, every validator briefly syncs to the same picture of the chain, handed over by the slot's proposer, so they're all judging from the same starting point.

The short version: everyone agrees on what they're looking at before they vote, so nobody can be tricked into voting on the wrong thing. Without this step, an attacker could feed different validators different information at just the right moments and keep them split between two competing chains indefinitely. Syncing everyone up first shuts that down: a built-in guarantee rather than the patchwork Ethereum leans on today.

The payoff is in the diagram above. 3SF runs one combined voting phase per slot instead of two, trimming the slot from SSF's 6Δ to 5Δ. And because the phases are pipelined rather than tightly coupled, a slowdown in the network delays finality for the affected blocks instead of halting the chain. That's the same "prefer delayed finality over a halt" instinct Gasper already has, worth contrasting with CometBFT's opposite call: it prioritizes correctness and pauses block production entirely if participation drops below a threshold. Different priorities, different failure modes.

The Catch That Sounds Familiar

For all its pipelining elegance, 3SF doesn't actually make the million-validator problem disappear. As the research candidly admits, that single voting phase still has to bundle over a million votes through peer-to-peer gossip within a few seconds, which still congests the network and saturates node bandwidth. Pipelining bought a smoother schedule; it didn't repeal the laws of networking.

So the 3SF research sets validator-set management aside as a separate problem. Two approaches are in play. Orbit uses a cryptographic lottery to pick a smaller committee to vote each slot rather than all million, cutting network load by an order of magnitude. Rainbow Staking instead splits stakers into "heavy" nodes that handle the bandwidth-hungry finality voting and "light" nodes that focus on censorship resistance without the constant signing burden. The current preference is to ship Rainbow Staking first, since it doesn't require reworking the consensus engine.

The punchline writes itself: to make finality fast at a million validators, Ethereum's leading proposals quietly involve not having a million validators vote every round.

Bigger Picture

3SF is one track of Lean Ethereum, a sweeping redesign that also folds in quantum-resistant signatures, SNARK-friendly execution, and a drop in the staking minimum from 32 ETH to 1 ETH. That last change would push the validator count even higher and make the bundling problem harder still, which is partly why these pieces have to ship together. As of mid-2026 it's all still research-and-testnet: the people building it describe full production as years out, with the caveat that better solutions may emerge along the way.

What's striking is the destination. The algorithms for fast finality have existed for years, and CometBFT runs one in production today. It's hard for Ethereum specifically because Ethereum chose a million validators, and the physics of bundling that many votes in seconds is a bottleneck no amount of protocol elegance erases. The most-researched consensus roadmap in the industry is arriving, committee by committee, at the same compact-set constraints smaller BFT chains started from years ago. Two philosophies meeting in the middle, from opposite ends.

About Reactive Network

Reactive Network is an EVM automation layer built around reactive contracts, event-driven smart contracts for cross-chain, on-chain automation. It runs on CometBFT consensus, providing instant finality and roughly 1-second block times while maintaining full EVM compatibility.

Reactive contracts subscribe to event logs across EVM chains and execute Solidity logic automatically when matching events occur, deciding autonomously when to send cross-chain callback transactions. This model supports conditional cross-chain state changes and continuous cross-chain workflows.

Website | Blog | X | Telegram | Discord | Docs

Build once — react everywhere!