Hydrangea++: Enhancing Hydrangea with Optimistic Proposals

Consensus lies at the heart of state machine replication (SMR), the fundamental abstraction that powers fault-tolerant distributed systems, replicated databases, and modern blockchains. The goal of a Byzantine Fault Tolerant (BFT) SMR protocol is simple yet profound: ensure that a group of distributed parties agree on a single, consistent sequence of operations, even when some participants are faulty, slow, or actively malicious.

For more than a decade, researchers and practitioners have pursued both low latency and strong fault tolerance in consensus protocols, all within the partially synchronous model that reflects real-world Internet conditions. Achieving either goal on its own is straightforward, but achieving both simultaneously has long remained out of reach.

Our Hydrangea consensus protocol shattered this long-standing barrier. It demonstrated, for the first time, that a protocol can commit in two communication rounds in the optimistic case while tolerating strictly more faults than earlier two-round protocols.

With Hydrangea++, we push this frontier even further.

Hydrangea++ enhances Hydrangea by introducing optimistic proposals, reducing proposal latency to a single network delay and substantially improving both throughput and end-to-end decision latency. By combining the optimistic proposal techniques pioneered in our Moonshot consensus with Hydrangea’s strong fault-resilience guarantees, Hydrangea++ delivers a protocol that is simultaneously latency-optimal and highly fault tolerant.

This blog post explores the motivation behind Hydrangea++, details its design, and highlights its performance gains, showing why Hydrangea++ represents the next major step forward in BFT consensus.

The Challenge: Latency vs. Resilience in BFT Consensus

One of the big goals in consensus design is keeping commit latency as low as possible. This is basically the number of communication steps honest nodes need to finally agree on a value under synchronous network conditions and an honest leader. Classic theory tells us something unfortunate: if we want to tolerate the maximum number of Byzantine faults (f<n/3) in the partially synchronous model, we’re stuck with at least three rounds.

Because of this limitation, many “optimistic” consensus protocols such as SBFT, FaB, Kudzu, Alpenglow, have tried to go faster by committing in two rounds under optimistic conditions. However, these protocols sacrifice resilience to get there. These protocols typically assume a system size of n=3f+2p+1, where f is the upper bound on Byzantine faults and p is a tuning knob that controls how optimistic you want to be. They give you fast, two-round commits only when the number of Byzantine faults stays within p<f. If the faults grow all the way up to f, the protocol slows back down to three rounds. In other words, you can get faster commits, but only by accepting weaker fault tolerance.

This led to a long-standing open question in consensus research:

Can we achieve optimistic two-round commit without reducing fault tolerance?

With Hydrangea, we showed that the answer is yes.

Hydrangea: Breaking the Barrier

Hydrangea introduced a new resilience model accounting simultaneously for Byzantine faults (f), crash faults (c), and a tunable parameter (k).

In a system of n=3f+2c+k+1 parties:

• Hydrangea achieves optimistic two-round commit when at most p = ⌊ (c + k) / 2 ⌋ parties are faulty (any mix of Byzantine or crash).
• In more adversarial conditions, with up to f Byzantine and c crash faults, Hydrangea guarantees three-round commit.
• Crucially, Hydrangea tolerates strictly more faults than prior two-round protocols.

Hydrangea resolved the long-standing tension between latency and fault tolerance.

But one bottleneck remained.

Hydrangea’s Remaining Limitation: Proposal Delay

Hydrangea retains a proposal delay of 2δ between consecutive honest leaders’ proposals, even when the network is fully synchronous where δ represents a single network delay. This is because a leader of view v+1 must first collect a block certificate from view v before proposing the next block, leading to following drawbacks:

Drawbacks

• Proposals can only occur every 2 message delays.
• Throughput suffers because fewer blocks enter the pipeline.
• End-to-end latency increases, even when everything is working perfectly.
• Geo-distributed systems feel the pain more acutely.
  

Hydrangea optimizes commit latency, but it does not optimize proposal latency. Proposal latency directly affects how long a client’s transaction must wait in the queue before it is included in a block and proposed. The longer this delay, the higher the overall end-to-end latency becomes.

In this blog post, we focus on end-to-end latency as the sum of proposal latency and commit latency which represents the time a client transaction may experience from submission to finalization.

Introducing Hydrangea++: Faster Proposal Pipelining

Hydrangea++ eliminates Hydrangea’s 2δ proposal delay. It introduces optimistic proposals, inspired by Moonshot’s design, enabling: a proposal every δ in the good case. This is the lowest possible bound, matching the physical network latency.

Hydrangea++ achieves this without sacrificing:

• Hydrangea’s two-round optimistic commit
• Hydrangea’s three-round good-case commit
• Hydrangea’s improved resilience model
  

Optimistic Proposals

In the Moonshot protocol, optimistic proposals enable consecutive honest leaders to issue new proposals without waiting for the usual round-trip synchronization, cutting the proposal latency down to a single network delay δ under good conditions. Instead of waiting for a block to be certified, Moonshot allows the leader of view v+1 to proactively propose as soon as the previous leader’s block has been received. This breaks the traditional 2δ barrier that most chain-based BFT protocols inherit from HotStuff-style pipelining.

Hydrangea++ builds directly on this idea. By incorporating optimistic proposals into Hydrangea’s safety framework, a leader can extend the block the moment it receives the previous leader’s proposal. This reduces Hydrangea’s proposal delay from 2δ to the theoretical minimum of δ, dramatically improving pipeline efficiency. Crucially, Hydrangea++ achieves this without sacrificing any of Hydrangea’s latency or fault-tolerance guarantees: it preserves two-round optimistic commits, three-round worst-case commits, and improved resilience, while gaining Moonshot-style fast-path responsiveness. The result is a protocol that is not only safer and more resilient, but also significantly faster in practice, especially in geo-distributed deployments.

More Challenges
Integrating optimistic proposals into Hydrangea introduces several design challenges. Optimistic proposals only succeed when the previous leader is honest—if a faulty leader proposes an invalid or conflicting block, that proposal may fail, causing the next optimistic proposal to fail as well. In such cases, the protocol must fall back to a slower recovery path that requires two message delays, similar to traditional approaches. Moonshot addresses this by introducing multiple vote types to distinguish between votes for optimistic proposals and standard proposals. Bringing these ideas into Hydrangea is more complex, because Hydrangea supports two distinct commit paths (optimistic two-round and fallback three-round), and the interaction of multiple vote types must be carefully designed to avoid breaking safety. Hydrangea++ resolves these challenges through a refined voting and certificate-ranking mechanism; we direct readers to our technical paper for the full details of this integration and its correctness proof.

Comparison with Minimmit

We compared Hydrangea++ with Minimmit, a recent state-of-the-art protocol designed to reduce end-to-end latency. Minimmit operates in an n=5f+1 setting (meaning it can tolerate only 20% Byzantine faults) and commits in two rounds when it collects n−f votes (about 81% of the replicas). Its key optimization is the ability to propose earlier than prior protocols. In particular, Minimmit allows a leader to propose the next block in view v+1 as soon as the block in view v gathers 2f+1 votes. This condition naturally holds when the previous proposer is honest and the network is synchronous. Prior BFT protocols in the same setting, by contrast, typically require a stronger quorum of 3f+1 votes before a new leader can safely propose.

Under similar optimistic conditions (when the previous leader is honest) Hydrangea++ is even more aggressive. It can issue the next proposal as soon as the previous block is received. In other words, while Minimmit speeds up proposal timing relative to earlier protocols, Hydrangea++ goes further: it safely pipelines proposals at the theoretical minimum delay without sacrificing the higher fault tolerance that Hydrangea already provides.

We implemented both Hydrangea++ and Minimmit and evaluated their performance in a geo-distributed deployment of 51 nodes across 10 Google Cloud regions, spanning the US, Canada, Europe, Australia, and the Middle East. To ensure a fair comparison, we instantiated Hydrangea++ in the n=3f+k+1 setting with c=0 and k=2f, so that both protocols operate under the same fault tolerance. In this configuration, Hydrangea++ can commit in two rounds when it receives roughly 81% of the votes, and in three rounds when it receives 61% of the votes in the second round and 41% in the third.

Across all experiments, Hydrangea++ consistently outperforms Minimmit in end-to-end latency. On average, Hydrangea++ achieves about 11% lower end-to-end latency than Minimmit. This improvement stems from Hydrangea++’s ability to propose more aggressively and to commit blocks using either of its commit rules, whichever finishes first. Interestingly, we also observe that in many cases the three-round slow commit rule ends up being faster in practice as it requires fewer messages (61% vs 81%), making it more efficient under geo-distributed network conditions.

Moreover, Hydrangea++’s aggressive proposal strategy not only lowers latency but also improves its throughput by approx. 35% compared to Minimmit. This improvement makes Hydrangea++ not only faster in terms of responsiveness, but also significantly more capable in handling higher transaction loads, making it the most performant protocol.