zyzzyva speculative byzantine fault tolerance
Download
Skip this Video
Download Presentation
ZYZZYVA: SPECULATIVE BYZANTINE FAULT TOLERANCE

Loading in 2 Seconds...

play fullscreen
1 / 30

ZYZZYVA: SPECULATIVE BYZANTINE FAULT TOLERANCE - PowerPoint PPT Presentation


  • 181 Views
  • 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

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

PowerPoint Slideshow about ' ZYZZYVA: SPECULATIVE BYZANTINE FAULT TOLERANCE' - abby


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

ZYZZYVA:SPECULATIVE BYZANTINEFAULT TOLERANCE

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

Best Paper Award at SOSP 2007

motivation
Motivation
  • 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
slide5
How?
  • 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
explanations
Explanations
  • 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
explanations1
Explanations
  • 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
comments
Comments
  • Zyzzyva-5 is a special version of Zyzziva requiring more replicas but having a lower overhead
conclusions
CONCLUSIONS
  • 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
ad