Four

random

Ethereum

<div class="light-yellow-block">
 <h2 id="strong-key-takeaways-strong"><strong>Key Takeaways</strong></h2>
 <ul>
  <li><strong>Today’s expected finality time: about 16 minutes</strong></li>
  <li><strong>Head-vote committee: about 512 validators per slot</strong></li>
  <li><strong>EIP number 8453 proposed; draft still unmerged</strong></li>
  <li><strong>2027 upgrade slot floated as stretch goal</strong></li>
 </ul>
</div>
<p>Ben Edgington, who describes his role as coordinating Ethereum’s fast-finality work, opened the <a href="https://github.com/ethereum/EIPs/pull/12566" rel="noopener noreferrer nofollow">Decoupled Consensus pull request</a> on October 21. He co-wrote the draft with Francesco D’Amato, Roberto Saltini, Yann Vonlanthen and Mikhail Kalinin.</p>
<p>His note on the pull request says “many aspects remain TBD” and that the immediate aim is an EIP number. A reviewer in the EIPs repository proposed 8453 the same day and asked the authors to open a discussion thread on Ethereum Magicians, the forum where proposals are debated. The pull request remains open and unmerged.</p>
<h2 id="why-finality-still-takes-about-16-minutes">Why finality still takes about 16 minutes</h2>
<p>Finality marks the point before which Ethereum’s validators will not reverse blocks. Reaching it takes two voting rounds, one to justify a checkpoint and one to finalise it, and each round lasts an epoch of 32 twelve-second slots. In a <a href="https://consensus.ethereum.foundation/blog/upgrading-finality-edition-1" rel="noopener noreferrer nofollow">May 11 post</a> on the Ethereum Foundation’s protocol consensus blog, Edgington put the minimum at 768 seconds and the expected time for a transaction at about 960, with 63 to 95 of the latest blocks unfinalised under normal conditions.</p>
<p>Those recent blocks can still be reorganised: nodes may switch to a competing sequence of blocks, sending transactions from the dropped ones back to the mempool to be included again. Finalised blocks are far harder to touch. Reversing one would require attackers holding more than a third of all stake, and it would cost them at least one-third of all staked ETH through slashing.</p>
<p>The same post describes a fast confirmation rule designed to give an earlier signal. When the network runs smoothly and no attacker is too powerful, it should show within about 13 seconds that a block will not be reorganised. It carries no economic penalty for attackers and does not tolerate network delays, so during network trouble it falls back to full finality, when services need certainty most.</p>
<p>Services that act on Ethereum transactions therefore choose how much of the finality wait to accept. The post lists several examples, including Circle’s Cross-Chain Transfer Protocol (CCTP) for USDC:</p>
<div style="overflow-x: auto; margin: 24px 0;">
 <table style="width: 100%; border-collapse: collapse; font-size: 15px; line-height: 1.5;">
  <thead>
   <tr style="background: #0f2a3d; color: #ffffff;">
    <th style="padding: 11px 14px; text-align: left;">Service</th>
    <th style="padding: 11px 14px; text-align: left;">What it waits for</th>
    <th style="padding: 11px 14px; text-align: left;">Trade-off</th>
   </tr>
  </thead>
  <tbody>
   <tr style="border-bottom: 1px solid #d6e2ea;">
    <td style="padding: 11px 14px;"><strong>CCTP, standard route</strong></td>
    <td style="padding: 11px 14px;">Ethereum finality, about 15 minutes</td>
    <td style="padding: 11px 14px;">Slowest option, with full settlement</td>
   </tr>
   <tr style="border-bottom: 1px solid #d6e2ea; background: #f4f8fa;">
    <td style="padding: 11px 14px;"><strong>CCTP, fast route</strong></td>
    <td style="padding: 11px 14px;">Two block confirmations, about 20 seconds</td>
    <td style="padding: 11px 14px;">Caps on USDC in transit and a fee</td>
   </tr>
   <tr style="border-bottom: 1px solid #d6e2ea;">
    <td style="padding: 11px 14px;"><strong>Arbitrum chains</strong></td>
    <td style="padding: 11px 14px;">Unrealised justification, an early finality stage about 8.5 minutes sooner</td>
    <td style="padding: 11px 14px;">Lacks finality’s full guarantees</td>
   </tr>
   <tr style="border-bottom: 1px solid #d6e2ea; background: #f4f8fa;">
    <td style="padding: 11px 14px;"><strong>OP Stack chains</strong></td>
    <td style="padding: 11px 14px;">A few slots</td>
    <td style="padding: 11px 14px;">An Ethereum reorg could reorganise the layer 2</td>
   </tr>
   <tr>
    <td style="padding: 11px 14px;"><strong>Centralised exchanges</strong></td>
    <td style="padding: 11px 14px;">A set number of block confirmations</td>
    <td style="padding: 11px 14px;">Some deposit risk to credit funds sooner</td>
   </tr>
  </tbody>
 </table>
 <p style="margin: 8px 0 0; font-size: 13px; color: #5b6b78;">Source: Ben Edgington, Ethereum Foundation protocol consensus blog, May 2026</p>
</div>
<p>Faster finality would narrow the gap between those routes, both for stablecoin bridges and for newer tokenised products such as the <a href="https://coindoo.com/jpmorgan-brings-bank-deposits-to-ethereums-tokenized-markets/" rel="noopener noreferrer nofollow">bank deposits JPMorgan is bringing to Ethereum</a>. Edgington expects cross-chain bridging to show the most visible gains.</p>
<h2 id="one-attestation-becomes-two-messages">One attestation becomes two messages</h2>
<p>Ethereum’s current consensus design, Gasper, packs two votes into each validator attestation. One feeds LMD GHOST, the <a rel="noopener noreferrer nofollow">fork</a>-choice rule that tells the next proposer which block to build on. The other feeds Casper FFG, the slower process that finalises checkpoints. Because the two travel together, fork choice draws on attestations from about 30,000 validators per slot, though the researchers behind the draft say far fewer would do.</p>
<p>The <a href="https://github.com/ethereum/EIPs/blob/2ac60ef5fb900fe7c62de0892b0f78c4488e3290/EIPS/eip-draft_decoupled_consensus.md" rel="noopener noreferrer nofollow">draft EIP</a> turns those votes into separate messages that travel across the network and are processed independently:</p>
<div style="display: flex; flex-wrap: wrap; gap: 16px; margin: 24px 0;">
 <div style="flex: 1 1 260px; padding: 18px 20px; border: 1px solid #cfd8e3; border-top: 4px solid #1d6fb8; border-radius: 6px;">
  <p style="margin: 0 0 10px; font-size: 13px; letter-spacing: 0.06em; text-transform: uppercase; color: #1d6fb8;"><strong>Head votes</strong></p>
  <p style="margin: 0 0 10px;"><strong>Who votes:</strong> a committee of about 512 validators per slot, drawn with odds proportional to each validator’s effective balance, the stake the protocol credits to it.</p>
  <p style="margin: 0;"><strong>What it decides:</strong> which block is the head of the chain and which recent blocks are confirmed.</p>
 </div>
 <div style="flex: 1 1 260px; padding: 18px 20px; border: 1px solid #cfd8e3; border-top: 4px solid #8a4fbf; border-radius: 6px;">
  <p style="margin: 0 0 10px; font-size: 13px; letter-spacing: 0.06em; text-transform: uppercase; color: #8a4fbf;"><strong>Finality attestations</strong></p>
  <p style="margin: 0 0 10px;"><strong>Who votes:</strong> the entire validator set.</p>
  <p style="margin: 0;"><strong>What it decides:</strong> which blocks are justified and finalised, in rounds on their own schedule, with each step requiring at least two-thirds of active stake.</p>
 </div>
</div>
<p>With its own schedule, the finality round can use bandwidth across the whole voting period and be shortened later without redesigning how slots work. The authors’ initial target is at least a fourfold reduction in time to finality, subject to parameters they have yet to specify. Applied to today’s 16-minute expectation, a fourfold cut would mean roughly four minutes, although the draft itself gives no figure.</p>
<h2 id="where-the-fourfold-cut-fits-in-a-longer-plan">Where the fourfold cut fits in a longer plan</h2>
<p>In the same May post, Edgington set out the longer-term ambition: bringing time to finality down from about 1,000 seconds to about 10. He presented it as his personal view rather than an official roadmap.</p>
<p>He wrote that earlier designs such as single-slot and three-slot finality foundered because they required solving every problem at once. The new approach stages the work. “Decoupled finality is the big unlock,” he wrote, expecting that step alone to bring a low single-digit speedup, in line with the draft’s fourfold target. Further gains would come from separate upgrades:</p>
<ul style="list-style: none; margin: 24px 0; padding: 0;">
 <li style="margin: 0 0 14px; padding: 2px 0 2px 16px; border-left: 3px solid #0e8f80;"><strong>Validator consolidation:</strong> since the Electra upgrade, large operators can merge up to 64 validators into one, cutting the number of finality votes. Edgington called progress slow.</li>
 <li style="margin: 0 0 14px; padding: 2px 0 2px 16px; border-left: 3px solid #0e8f80;"><strong>Batching votes at the source:</strong> operators running many validators behind one node would combine their votes before broadcasting them.</li>
 <li style="margin: 0 0 14px; padding: 2px 0 2px 16px; border-left: 3px solid #0e8f80;"><strong>Rotating the validator set:</strong> only a subset of validators would take part in finality at any time, without excluding or capping anyone.</li>
 <li style="margin: 0 0 14px; padding: 2px 0 2px 16px; border-left: 3px solid #0e8f80;"><strong>Faster networking and aggregation:</strong> peer-to-peer upgrades and SNARK-based aggregation would move votes more efficiently.</li>
 <li style="margin: 0; padding: 2px 0 2px 16px; border-left: 3px solid #0e8f80;"><strong>Single-round finality:</strong> one voting round instead of two would nearly halve the wait, at the cost of lowering fault tolerance from a third of stake to perhaps 20% or 17%.</li>
</ul>
<p>The draft itself includes none of these steps. By Edgington’s arithmetic, four improvements that each deliver a threefold gain would come close to the 100-fold ambition. He also noted that the Strawmap roadmap listed decoupled consensus as a headliner candidate for the upgrade provisionally labelled I*, likely in 2027, as a stretch goal.</p>
<h2 id="why-ethereum-won-t-halt-to-go-faster">Why Ethereum won’t halt to go faster</h2>
<p>Classic Byzantine fault-tolerant protocols such as Tendermint finalise blocks quickly but stop producing them when too many validators go offline. Researcher Luca Zanolini argued in a <a href="https://ethresear.ch/t/why-ethereum-needs-a-dynamically-available-protocol/24418" rel="noopener noreferrer nofollow">March post</a> on the Ethereum Research forum that halting is incompatible with Ethereum’s design. He pointed to a proven limit known as the availability-finality dilemma: no single protocol can keep growing while participation rises and falls and also stay safe through a network split. Ethereum’s answer is one layer that keeps building blocks with whichever validators are online and a second that finalises behind it.</p>
<p>Zanolini cited the network’s record. In May 2023, bugs in the Prysm and Teku clients, which together ran more than half of validators, disrupted finality and set off Ethereum’s first mainnet inactivity leak. Block proposals never dropped below roughly 90% of slots and transactions kept processing. By contrast, Solana produced no blocks for five hours during its February 2024 halt, leaving DeFi protocols on the network unable to operate.</p>
<p>Decoupled Consensus keeps that arrangement. Finality still needs the two-thirds quorum, so a large enough outage can stall it while the remaining validators keep building blocks. Most applications can keep running, but anything requiring final settlement has to wait. If participation does not recover, the inactivity leak gradually reduces offline validators’ stake until finality can resume. How the leak would work under the new design is still to be written.</p>
<h2 id="the-post-quantum-reason-comes-first">The post-quantum reason comes first</h2>
<p>Faster finality draws the attention, yet it is third on the authors’ list. The pull request names a foundation for a later post-quantum transition first and fork-choice security second, and the draft’s motivation follows the same order.</p>
<p>The connection is signature aggregation. Validators sign with BLS, a scheme that lets many signatures be merged into one compact signature. Zanolini wrote that no post-quantum scheme offers comparable aggregation at practical sizes. A head-vote committee of a few hundred validators avoids the problem because its signatures can be sent side by side. He argued this could allow a post-quantum version of the block-producing layer before anyone solves aggregation for finality votes from the full validator set. The draft prepares for that path but does not select a post-quantum signature scheme.</p>
<div class="read-more pb-3 pt-3 pt-md-2 px-3 my-4 border bg-light">
 <h5 class="text-uppercase border-bottom mb-3 pb-1 d-none d-md-block">READ MORE:</h5><a href="https://coindoo.com/us-banks-object-to-new-stablecoin-rewards-rule/" rel="noopener noreferrer nofollow">
  <div class="contentRight col-4"><span><img src="https://coindoo.com/wp-content/uploads/2025/03/stablecoin543.png"></span>
  </div>
  <div class="contentLeft col-8">
   <h4 class="title mb-0">US Banks Object to New Stablecoin Rewards Rule</h4>
  </div></a>
</div>
<h2 id="new-defences-come-with-a-smaller-target">New defences come with a smaller target</h2>
<p>Today’s fork choice keeps each validator’s latest vote with no age limit. According to the draft, that lets attackers withhold votes and release them at strategic moments to tip nodes toward a chosen branch. Under the proposal, fork choice counts only votes from a recent slot, with specified cutoffs for when they must arrive.</p>
<p>Locks protect blocks the chain has confirmed. A block becomes fast-locked when at least half of that slot’s committee sends timely head votes for it, with no validator voting both ways. Locks expire, and recent votes for a competing block can move a lock back to an earlier block, letting the chain recover as conditions change. Proposers would also carry recent votes in their blocks to bring validators’ views into line. This technique, called view-merge, replaces proposer boost, the extra fork-choice weight currently given to a timely block, and targets balancing and reorg attacks.</p>
<p>The smaller committee is the trade-off. Fewer voters means less signature work in each slot, but it raises the chance that a random draw hands an attacker an outsized share of a committee and gives attackers a smaller group to knock offline with denial-of-service attacks. Choosing committees privately through a verifiable random function is one option under study. The size is not settled either: earlier research posts sketched about 256 validators, and the draft leaves both its 512 figure and the selection method open.</p>
<h2 id="what-must-happen-before-any-upgrade">What must happen before any upgrade</h2>
<p>Activating Decoupled Consensus would take a consensus-layer hard fork, with consensus and validator clients supporting new voting duties, block and state formats and fork-choice rules. Rewards and penalties, slashing conditions, timing and lock parameters, fork-transition rules, executable test cases and a full safety and liveness analysis are all still to be written. A <a href="https://github.com/ethereum/consensus-specs/tree/decoupled-consensus/specs/_features/dc" rel="noopener noreferrer nofollow">work-in-progress specification</a> sits in a feature branch of Ethereum’s consensus specifications. The draft keeps the total validator rewards budget unchanged, though payments could shift between head voting and finality duties.</p>
<p>The bigger trade-off lies beyond this draft. Edgington has written that he wants fast-enough finality without excluding home stakers, solo stakers or those in remote locations, and that the community may at some point have to weigh even faster finality against staking diversity.</p>
<div style="margin: 28px 0 0; padding: 20px 22px; background: #f7fafb; border: 1px dashed #8fa3b3; border-radius: 6px;">
 <h3 style="margin: 0 0 12px; font-size: 18px;" id="what-to-watch-next">What to watch next</h3>
 <ul style="margin: 0; padding-left: 20px;">
  <li style="margin-bottom: 8px;"><strong>EIP status:</strong> whether the pull request merges as a Draft under number 8453 and a discussion thread opens on Ethereum Magicians.</li>
  <li style="margin-bottom: 8px;"><strong>Specification work:</strong> progress on the rewards, slashing and inactivity-leak sections still marked TBD.</li>
  <li><strong>Upgrade scoping:</strong> whether core developers pick decoupled consensus as a headliner for I*. Missing that list would push the 2027 stretch goal back.</li>
 </ul>
</div>
<p>The post <a href="https://coindoo.com/ethereums-16-minute-settlement-wait-could-drop-to-four/" rel="noopener noreferrer nofollow">Ethereum’s 16-Minute Settlement Wait Could Drop to Four</a> appeared first on <a href="https://coindoo.com" rel="noopener noreferrer nofollow">Coindoo</a>.</p>

Ethereum’s 16-Minute Settlement Wait Could Drop to Four

Table of Contents

Coindoo.com

Other articles published on Oct 22, 2026

Join our free newsletter for daily crypto updates!