Why then another BFT protocol? Zyzzyva. Simplify, simplify. Simplify, simplify. Complex decision tree hampers BFT adoption. H.D. Thoreau. H.D.

Transcription

1 Why then another BFT protool? Yes No Zyzzyva Yes No Yes No Comple deision tree hampers BFT adoption Simplify, simplify H.D. Thoreau Simplify, simplify H.D. Thoreau Yes No Yes No Yes Yes No One protool that mathes or tops its ompetitors in lateny throughput ost of repliation

2 Replia oordination How it is done now All orret replias eeute the same sequene of ommands Command For eah reeived ommand, orret replias: Agree on s in the sequene Eeute in the agreed upon order Replies to the lient Agreement Eeution How Zyzzyva does it Stability Command A ommand is stable at a replia one its in the sequene annot hange RSM Safety RSM Liveness Agreement Eeution Corret lients only proess replies to stable ommands All ommands issued by orret lients eventually beome stable and eliit a reply

3 Enforing safety RSM safety requires: Corret lients only proess replies to stable ommands...but RSM implementations enfore instead: Corret replias only eeute and reply to ommands that are stable Servie performs an output ommit with eah reply Speulative BFT: Trust, but Verify Insight: output ommit at the lient, not at the servie! Replias eeute and reply to a ommand without knowing whether it is stable trust order provided by primary no epliit replia agreement! Corret lient, before proessing reply, verifies that it orresponds to stable ommand if not, lient takes ation to ensure liveness Verifying stability Command History Neessary ondition for stability in Zyzzyva: A ommand an beome stable only if a majority of orret replias agree on its in the sequene Client an proess a response for iff: a majority of orret replias agrees on s the set of replies is inompatible, for all possible future eeutions, with a majority of orret replias agreeing on a different ommand holding s ur rent H i,k = a hash of the sequene of the first ommands eeuted by replia i On reeipt of a ommand from the primary, replia appends to its ommand history Replia reply for inludes: the appliation-level response the orresponding ommand history k

4 Case 1: Unanimity r 1,H 1,k A majority of orret replias agrees on s (all do!), k, k, k r 2,H 2,k r 3,H 3,k r 4,H 4,k New primary determines k-th ommand by asking n f replias for their H Client proesses response if all replies math: r 1 =...= r 4 H 1,k =...= H 4,k A majority of orret replias agrees on s (all do!) New primary determines k-th ommand by asking n f replias for their H A majority of orret replias agrees on s (all do!) New primary determines k-th ommand by asking n f replias for their H

5 Case 2: A majority of orret replias agree A majority of orret replias agrees on s (all do!) r 1,H 1,k New primary determines s by asking n f replias for their H It is impossible for a majority of orret replias to agree on a different ommand for s, k, k, k r 2,H 2,k r 3,H 3,k At least 2f +1 replies math A majority of orret replias agrees on s New primary determines k-th ommand by asking n f replias for their H A majority of orret replias agrees on s New primary determines k-th ommand by asking n f replias for their H

6 A majority of orret replias agrees on s New primary determines k-th ommand by asking n f replias for their H A majority of orret replias agrees on s New primary determines k-th ommand by asking n f replias for their H A majority of orret replias agrees on s New primary determines k-th ommand by asking n f replias for their H A majority of orret replias agrees on s New primary determines k-th ommand by asking n f replias for their H

7 A majority of orret replias agrees on s New primary determines k-th ommand by asking n f replias for their H A majority of orret replias agrees on s New primary determines k-th ommand by asking n f replias for their H Case 2: A majority of orret replias agree A majority of orret replias agrees on s r i,h i,k CC H 1,k,...,H 4,k New primary determines k-th ommand by asking n f replias for their H, k Not safe! Client sends to all a ommit ertifiate ontaining 2f +1 mathing histories

8 Case 2: A majority of orret replias agree, k r 1,H 1,k CC aks Client proesses response if it reeives at least 2f +1 aks Stability and ommand histories Certifiate proves that a majority of orret replias agreed on s New primary determines k-th ommand by ontating n f replias This set ontains at least one orret replia with a opy of the ertifiate Inompatible with a majority baking a different ommand for that Case 3: None of the above Stability depends on mathing ommand histories Stability is prefi-losed: If a ommand with sequene number n is stable, then so is every ommand with sequene number n <n r 1,H 1,k, k r 2,H 2,k, k, k Fewer than 2f +1 replies math Clients retransmits to all replias-hinting primary may be faulty

9 Zyzzyva reap Output ommit at the lient, not the servie Replias eeute requests without epliit agreement Command The Case of the Missing Phase Client verifies if response orresponds to stable ommand At most 2 phases within a view to make ommand stable Pre-prepare Prepare Commit Client proesses response if it reeives at least f +1 mathing replies after ommit phase The Case of the Missing Phase The Case of the Missing Phase Command Command Pre-prepare Pre-prepare Prepare Unanimity Majority

10 The Case of the Missing Phase View-Change: replaing the primary Command BFT In PBFT, a replia that suspets primary is faulty goes unilaterally on strike Stops proessing messages in the view Third Commit phase needed for liveness Pre-prepare Prepare Commit Where did the third phase go? Why was it there to begin with? View-Change: replaing the primary In PBFT, a replia that suspets primary is faulty goes unilaterally on strike Stops proessing messages in the view Third Commit phase needed for liveness In Zyzzyva, the replia goes on Tehnion strike Broadasts I hate the primary and keeps on working Stops when sees enough hate mail to ensure all orret replia will stop as well Faulty lients an t affet safety Faulty lients annot reate inonsistent ommit ertifiates Clients annot fabriate ommand histories, as they are signed by replias It is impossible to generate a valid ommit ertifiate that onflits with the order of any stable request Stability is prefi losed! Etra phase is moved to the unommon ase

11 Olly Olly Oen Free! or, faulty lients an t affet liveness Olly Olly Oen Free! or, faulty lients an t affet liveness Faulty lient omits to send CC for Replias ommit histories are unaffeted! Later orret lient who establishes > is stable frees as well Stability is prefi losed Optimizations Bathing Chekpoint protool to garbage ollet histories Optimizations inlude: Replaing digital signatures with MAC Separating agreement from eeution Bathing requests for higher throughput Zyzzyva5: fast despite f failures

12 Bathing Throughput Only one history digest for all requests in the bath-amortizes rypto operations Throughput Paved with good intentions No BFT protool should rely on synhrony for safety FLP: No onsensus protool an be both safe and live in an asynhronous system! All one an guarantee is eventual progress

13 Paved with good intentions No BFT protool should rely on synhrony for safety FLP: No onsensus protool an be both safe and live in an asynhronous system! All one an guarantee is eventual progress Handle normal and worst ase separately as a rule, beause the requirements for the two are quite different: the normal ase must be fast; the worst ase must make some progress -- Butler Lampson, Hints for Computer System Design The Byzantine Empire under Justinian ( AD) Synhronous, no failures Asynhronous Synhronous, with faults! Reasting the problem Reasting the problem Misguided Maimize performane during graious eeutions where Dangerous the network is synhronous all lients and servers behave orretly Futile Misguided it enourages systems that fail to deliver BFT Dangerous Futile

14 Reasting the problem Reasting the problem Misguided it enourages systems that fail to deliver BFT Dangerous it enourages fragile optimizations Futile Misguided it enourages systems that fail to deliver BFT Dangerous it enourages fragile optimizations Futile it yields diminishing return on ommon ase A new approah BFT: From Z To A Build BFT systems around a mai-min priniple: maimize the system s performane during univil eeutions Definition An eeution is univil iff the eeution is synhronous Zyzzyva up to f servers and an arbitrary number of lients are Byzantine all remaining lients and servers are orret

15 BFT: From Z To A Throughput Aardvark Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults Revisiting onventional wisdom Signatures are epensive - use MACs View hanges are to be avoided Revisiting onventional wisdom Signatures are epensive - use MACs Faulty lients an use MACs to generate ambiguity Aardvark requires lients to sign requests View hanges are to be avoided Hardware multiast is a boon Hardware multiast is a boon

16 Revisiting onventional wisdom Signatures are epensive - use MACs Faulty lients an use MACs to generate ambiguity Aardvark requires lients to sign requests View hanges are to be avoided Aardvark uses regular view hanges to maintain high throughput despite faulty primaries Hardware multiast is a boon Revisiting onventional wisdom Signatures are epensive - use MACs Faulty lients an use MACs to generate ambiguity Aardvark requires lients to sign requests View hanges are to be avoided Aardvark uses regular view hanges to maintain high throughput despite faulty primaries Hardware multiast is a boon Aardvark uses separate work queues for lients and individual replias The Long Marh: taking stok BFT is too slow The Long Marh: taking stok BFT is too slow High performane BFT prototypes for both graious and univil eeutions BFT is too repliation intensive BFT is too repliation intensive

17 The Long Marh: taking stok BFT is too slow High performane BFT prototypes for both graious and univil eeutions BFT is too repliation intensive Separate agreement from eeution The Long Marh: taking stok BFT is too slow High performane BFT prototypes for both graious and univil eeutions BFT is too repliation intensive Separate agreement from eeution So why has no one yet built a large sale BFT system? A fork in the road When you ome to a fork in the road, take it Yogi Berra