!! Problems to solve ! ! ! ! There is no one size that fi ts - PDF document

The next 700 BFT protocols Guerraoui, Rachid, Nikola Kne ž evi ć , Vivien Quéma, and Marko Vukoli ć ! In Proceedings of the 5th European conference on Computer systems, pp. 363-376. ACM, 2010 !! Problems to solve ! ! ! ! • There is no “one size that fi ts all” BFT protocol ! ! ! ! ! ! Heavily affected by actual network, message size, contention, etc ! ! ! ! ! ! • Dif fi cult to develop, test on existing protocol ! ! Modern BFT protocol has about 20,000 lines of complex code ! ! Correlation, change one part may affect another part • Difference from the required paper ! ! This paper: Aims to improve the state-of-the-art BFT protocol ! ! Required paper: fi rst BFT protocol, baseline for practical BFT implementation

Key techniques and insights ! • ! Abortable Byzantine faulT-toleRant stAte maChine ! ! ! ! replicaTion (Abstract) ! ! ! ! ! ! !! ! An instance of Abstract looks like BFT state machine replication, but may abort a ! ! ! !! ! client’s request. ! ! ! ! !! ! View BFT protocols as a composition of instances of our abstraction, each ! ! !! ! instance targeted and optimized for speci fi c system conditions. ! • Example: Aliph !! ! Number of replicas: 3f+1 !! ! Three instances: !! ! ! Quorum: handle normal cases, low latency !! ! ! Chain: not exactly the same one we see before, handle contention, high !! ! ! throughput, use MAC to ensure correct reply !! ! ! Backup:handle failures and asynchrony, guarantee k >= 1 commits, wrap !! ! ! over PBFT !! Static Order: Quorum->Chain->Backup->Quorum->Chain->Backup->Quorum… ! ! !! Switching: abort requests and send a unforgeable abort history to next instance Compare with required paper • Not a new algorithm to tolerate Byzantine failures, ! ! ! leverage techniques in required paper ! ! ! ! ! • Abstract provides modularity and fl exibility, phases ! ! ! can be designed, tested and proved independently ! ! ! ! ! • Uses simple protocols to handle easy cases and thus improves performance ! ! ! Quorum only requires 2 one-way message delays in common cases, while ! Zyzzyva requires 3 one-way message delays ! ! ! Chain uses a pipeline pattern that reduces number of MAC operations at the ! bottleneck server, and optimizes network usage: servers send/receive messages ! to/from a single server.

! Evaluation on Aliph ! Latency • • Throughput Throughput for 0/0 benchmark (f=1) Throughput under dynamic workload ! Take away ! ! ! ! ! • Composite different protocols(instances) , each specializes ! ! ! at different situations and improves overall performance ! ! ! ! ! • ! Design, test and run each subprotocol independently ! ! ! ! ! • ! We can dynamically adapt k in Backup to fi t the ! ! ! ! system condition ! ! ! ! • ! We could dynamically switch between instances to ! improve performance

Thank you!