Skip to content
Blockchain LabTHE VENTURE STUDIO

LibraryConsensus2007Design paperCorpus record

Zyzzyva: Speculative Byzantine Fault Tolerance

Zyzzyva. Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement and Edmund Wong.

Replicas execute the leader's request speculatively and reply. If every replica agrees, the client is done. A disagreement starts a slower path that looks more like PBFT.

A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.

A finality gadget that shows the user a result before a quorum certificate should say so, the way this paper does.

The five-minute read

The defect

PBFT pays three rounds even when no one is faulty, which is almost always.

The rule

Replicas execute the leader's request speculatively and reply. If every replica agrees, the client is done. A disagreement starts a slower path that looks more like PBFT.

How it is put together

The fast path needs all replicas, not merely a quorum. The client is part of the protocol. It notices disagreement. Speculation means the reply can be ahead of a committed certificate.

Where the claim stops

A fast path that needs every replica stalls when one is slow.

One action, walked through

  1. The leader orders a request.
  2. Replicas execute and reply to the client.
  3. The client accepts if the replies match. Otherwise it demands a view change or a commit proof.
  4. Does the fast path require every replica?

The argument, unpacked

Why it is still on the desk

A finality gadget that shows the user a result before a quorum certificate should say so, the way this paper does.

After the text

Speculative BFT became a standard idea. Production chains usually wait for a certificate because rollback of a public ledger is the whole problem.

What has to be true

  • A fast path that needs every replica stalls when one is slow.
  • The paper is crash-and-Byzantine in a known set, not a chain.
  • Speculative execution can be rolled back. The application has to allow that.

What happened after the paper

Speculative BFT became a standard idea. Production chains usually wait for a certificate because rollback of a public ledger is the whole problem.

What to check before you use the idea

  • Does the fast path require every replica?
  • Who detects a split in the replies?
  • Can an executed request be undone?

Terms

Speculative execution
Doing the work before a commit certificate exists.
Complete quorum
A reply set that includes every replica.

The problem the paper names

PBFT pays three rounds even when no one is faulty, which is almost always.

What the design proposes

  • The fast path needs all replicas, not merely a quorum.
  • The client is part of the protocol. It notices disagreement.
  • Speculation means the reply can be ahead of a committed certificate.

How the mechanism is specified

  • The leader orders a request.
  • Replicas execute and reply to the client.
  • The client accepts if the replies match. Otherwise it demands a view change or a commit proof.

What this page does not treat as proven

  • A fast path that needs every replica stalls when one is slow.
  • The paper is crash-and-Byzantine in a known set, not a chain.
  • Speculative execution can be rolled back. The application has to allow that.

Why a venture studio still reads it

A finality gadget that shows the user a result before a quorum certificate should say so, the way this paper does.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.