Espresso has detailed a core redesign of HotShot, its HotStuff-based consensus protocol, with the main goal of cutting finality latency. In the older version of HotShot, a block proposed in view v could gather a quorum of votes and still fail to finalize immediately. Its certificate had to be included in the proposal for view v+1, and the certificate for view v+1 then had to be included in view v+2 before the original block satisfied the protocol’s commit rule.
That chained structure had been well studied and gave the protocol a compact pipeline: each view produced one proposal and one round of voting, with certificate costs spread across multiple blocks. But the cost was delay. A block’s finality depended not only on how quickly its own voting round completed, but also on whether later views progressed smoothly. If a later leader was slow, offline, or Byzantine, every block waiting in that commit chain could be held up even if those blocks had already received the votes they needed.
Espresso said this coupling between a block’s finality and the liveness of future leaders had become the main obstacle to sub-second finality for HotShot, whose stated role is to provide fast data finality for many downstream chains. In its view, improving implementation alone would not solve that problem; the commit rule itself had to change.
From chained commit to finality inside one view
The new protocol finalizes inside a single view. It uses two consecutive rounds of network-wide voting instead of the older pattern of one leader-aggregated voting round followed by chained commit across multiple views.
- A leader proposes a block and uses erasure coding to split it into smaller pieces for all validators.
- After receiving their shares, validators broadcast first-round votes to all other validators rather than sending them to the next leader.
- Any node that collects a quorum of first-round votes can assemble certificate 1, lock the block, and immediately broadcast a second-round vote.
- Any node that collects a quorum of second-round votes can assemble certificate 2, at which point the block is finalized.
Espresso compared this structure to the two-phase commit logic used in classical BFT systems such as PBFT: one preparatory round locks a value, and one commit round finalizes it. That preserves the standard safety property that an honest quorum cannot lock two conflicting blocks at the same time.
The important distinction is where those two rounds sit in the protocol. In the older design, the equivalent logic was spread across different views, each with its own leader and proposal, which created multiple places where progress could stall. In the new design, both voting rounds happen inside the current proposal view. Whether a block finalizes depends only on validator votes for that block, not on the state of any later leader.
Network-wide voting replaces leader-side aggregation
Another structural change is the message pattern.
The old protocol used a linear, leader-centric aggregation model. Validators sent votes to a single leader, which aggregated them into a certificate. The rest of the network could only see that certificate after it was included in the leader’s next proposal. This kept bandwidth costs low, with message complexity of O(n) per round, but it introduced a single-point delay and liveness risk. The leader responsible for aggregation had to be honest, online, and responsive, or the whole round could stall.
The new protocol switches to network-wide voting. Each validator broadcasts votes to every other validator, and any node that observes a quorum can assemble the certificate on its own. Message complexity rises to O(n²), but the vote-aggregation bottleneck disappears, along with one class of liveness failures caused by a single faulty node.
Espresso also said the old view-sync subprotocol, which existed to handle these stalls, is no longer needed. In the network-wide model, a node that misses some votes can still make a decision after receiving a certificate assembled by someone else. Only when a leader is actually offline or malicious does the protocol need a simple timeout certificate.
At roughly 100 validators, the company said vote messages are small enough that O(n²) overhead remains manageable. It described that as a tradeoff suited to HotShot’s current validator set. If the validator count grows by another order of magnitude, the protocol would need supporting optimizations such as committee sampling, aggregated signatures, or hierarchical vote forwarding. Espresso framed that as a scaling issue tied to decentralization, separate from the finality-latency problem addressed here.
Data availability without a separate DA committee
The redesign also changes how data availability is handled. In the older version, HotShot relied on a dedicated data availability, or DA, committee. Before consensus voting began, that committee received the block payload, voted on it, and issued a DA certificate. The point was to provide a faster fallback path if a leader withheld data and the network otherwise had to reconstruct the block through VID.
In the new protocol, data availability is handled entirely through VID because block reconstruction has become much faster. The leader generates erasure-coded shares for each validator according to stake weight, and validators only send first-round votes after receiving their assigned shares.
That means a quorum of first-round votes already proves that the network holds a set of shares sufficient to reconstruct the block. If validators representing two-thirds of stake have voted, then two-thirds of stake holds the corresponding shares, and erasure coding guarantees those shares are enough to recover the full block.
As a result, the DA committee is removed entirely, cutting out a full round of voting and payload distribution. Data availability no longer requires a separate negotiation path; it is built directly into the same path that leads to finality.
How Espresso compares HotShot with Gasper and CometBFT
Ethereum’s Gasper
Espresso contrasted HotShot with Ethereum’s Gasper, which combines LMD-GHOST fork choice with Casper FFG finality. Gasper is designed for a validator set far larger than HotShot’s and explicitly supports ordinary stakers running on modest hardware and low bandwidth. Its finality comes from epoch-boundary checkpoints rather than block-by-block certificates.
Those choices make Ethereum finality a matter of minutes rather than milliseconds. The article points to fixed slot times, signature aggregation across tens of thousands of validators, and a finality layer built on top of fork choice rather than a unified BFT commit path. Espresso said that is not a design flaw but a different optimization target: Ethereum prioritizes validator participation and censorship resistance over settlement latency. HotShot, by contrast, assumes a manageable validator set and a stake-based model, and was designed from the start for fast data finality.
CometBFT
The article also compares the new HotShot with CometBFT, the Tendermint-based consensus engine used by public blockchains. CometBFT can already deliver fast single-block finality through a leader-proposal and validator-voting structure with prevote and precommit rounds. In that sense, both the old and new HotShot designs belong to the same two-phase BFT family.
The main difference, according to Espresso, is what the votes carry. In CometBFT, each round broadcasts and votes on the full block. In the new HotShot, the network broadcasts erasure-coded shares, and the votes themselves serve as data-availability proof. Espresso said that distinction matters because HotShot is meant to finalize blocks for many independent downstream chains at once, so data-availability guarantees must remain independent of the block size of any single downstream chain.
CometBFT also keeps a linear, leader-centered message pattern in each round. HotShot moves to network-wide voting specifically to remove dependence on the next leader from the critical path.
Target outcome: faster finality, same BFT safety bound
Espresso said the redesigned protocol has three direct properties. First, block finality depends only on the validators voting on that block, not on later leaders. Second, data availability is guaranteed mathematically by the same quorum that finalizes the block, without a separate coordination step. Third, the new message pattern trades higher bandwidth costs for the removal of an entire class of liveness bottlenecks.
That combination, Espresso said, is what makes sub-second finality possible without weakening HotShot’s existing BFT safety guarantees. The protocol still tolerates malicious validators controlling less than one-third of stake, and it still prevents two conflicting blocks from obtaining two valid certificates at the same time.
