!! 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 fits all” BFT protocol

! !Heavily affected by actual network, message size, contention, etc ! ! !

Difficult 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: first 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 specific 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 flexibility, 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 under dynamic workload Throughput for 0/0 benchmark (f=1)

• !

! ! ! ! !

• !

! !

• !

! ! ! ! !

• !

!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 fit the !system condition ! !We could dynamically switch between instances to !improve performance

Thank you!