Zyzzyva speculative byzantine fault tolerance
1 / 30


  • Uploaded on

ZYZZYVA: SPECULATIVE BYZANTINE FAULT TOLERANCE. R.Kotla, L. Alvisi, M. Dahlin, A. Clement and E. Wong U. T. Austin. Best Paper Award at SOSP 2007. Motivation. Why implement Byzantine Fault-Tolerant replication? Increasing value of data and decreasing cost of hardware

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Zyzzyva speculative byzantine fault tolerance


R.Kotla, L. Alvisi, M. Dahlin, A. Clement and E. WongU. T. Austin

Best Paper Award at SOSP 2007


  • Why implement Byzantine Fault-Tolerant replication?

    • Increasing value of data and decreasing cost of hardware

    • More non-stop-fail behaviors than believed

    • BFT is becoming cheaper

    • Cost of 3-way non-BFT replication close to cost of BFT replication

Zyzzyva i
Zyzzyva (I)

  • Uses speculation to reduce the cost of BFT replication

    • Primary replica proposes order of client requests to all secondary replicas (standard)

    • Secondary replicas speculatively execute the request without going through an agreement protocol to validate that order (new idea)

Zyzzyva ii
Zyzzyva (II)

  • As a result

    • States of correct replicas may diverge

    • Replicas may send diverging replies to client

  • Zyzzyva’s solution

    • Clients detect inconsistencies

    • Help convergence of correct replicas to a single total ordering of requests

    • Reject inconsistent replies


  • Clients observe a replicated state machine

  • Replies contain enough information to let clients ascertain if the replies and the history are stable and guaranteed to be eventually committed

  • Replicas have checkpoints

Byzantine agreement i
Byzantine agreement (I)

  • No solution for less than four entities

Byzantine agreement ii
Byzantine agreement (II)

  • To achieve agreement in the presence of f failed nodes (“traitors”) we need

    • 3f + 1 entities

Practical bft i
Practical BFT (I)

  • Practical Byzantine Fault-Tolerant protocol (PBFT) [Castro and Liskov 1999]

Practical bft ii
Practical BFT (II)

Replicas decide on correct ordering

Practical bft iii
Practical BFT (III)

  • Client sends signed request to primary replica

  • Primary assigns a sequence number to the request and sends to all other replicas aPRE-PREPARE message

  • Secondary replicas validate the message and send a PREPARE message to all replicas

  • Replicas that can collect 2fPREPARE messages send a COMMIT message to all replicas

  • Replicas that can collect 2f+ 1COMMIT message send a REPLY to the client

A shortened version
A shortened version

Faster agreement is achieved thanks toa more complex view change protocol

The explanation i
The explanation (I)

  • "No replicated service that uses the traditional view change protocol can be live without an agreement protocol that includes both the prepare and commit full exchanges"

  • "The traditional view change protocol lets correct replicas commit to a view change and become silent in a view without any guarantee that their action will lead to the view change."

The explanation ii
The explanation (II)

  • Zyzzyva

    • Adds an extra phase to its view change protocol

    • Guarantees that a correct replica will not abandon a view unless every other correct replica does it

Zyzzyva agreement i
Zyzzyva Agreement (I)

  • Common case: no faulty replicas


  • Secondary replicas assume that

    • Primary replica gave the right ordering

    • All secondary replicas will participate in transaction

  • Initiate speculative execution

  • Client receives 3f + 1mutually consistent responses

Zyzzyva agreement ii
Zyzzyva Agreement (II)

  • With a faulty replica

Explanations i
Explanations (I)

  • Client receives 3f mutually consistent responses

  • Gathers at least 2f + 1 mutually consistent responses

  • Distributes a commit certificate to the replicas

  • Once at least 2f + 1 replicas acknowledge receiving a commit certificate, the client considers the request completed

Explanations ii
Explanations (II)

  • If enough secondary replicas suspect that the primary replica is faulty, a view change is initiated and anew primaryelected

Explanations i1
Explanations (I)

  • Each replica maintains

    • A history of the requests it has executed

    • A copy of the max commit certificate it has received

      • Let it distinguish between committed history and speculative history

Explanations ii1
Explanations (II)

  • Each replica constructs a checkpoint every CP_INTERVAL requests

  • It maintains one stable checkpoint with a corresponding stable application state snapshot

  • It might also have up to one speculative checkpoint with its corresponding speculative application state snapshot

Explanations iii
Explanations (III)

  • Checkpoints and application state become committed through a process similar to that of earlier BFT agreement protocols

    • Replicas send signed checkpoint messages to all replicas when they generate a tentative checkpoint

    • Commit checkpoint after they collect f + 1 signed matching checkpoint messages


  • Two-phase protocol

  • Elects a new primary

  • Guarantees that it will not introduce any changes in a history that has already completed at a correct client


  • Zyzzyva-5 is a special version of Zyzziva requiring more replicas but having a lower overhead


  • Systematically exploiting speculative execution results in a protocol much faster than conventional BFT agreement protocols.

  • Observe that Zyzzyva is optimized for the most frequent case but provides the correct result in all cases

    • A good rule to follow