SlideShare a Scribd company logo

SCP

•
•
Y
YongraeJo

SCP is a computationally scalable Byzantine consensus protocol that uses committees to achieve scalability. It partitions users into multiple committees, with each committee running a traditional BFT consensus protocol in parallel. This allows throughput to scale with increased computational power. SCP combines proof-of-work for identity generation and committee assignment with message passing-based BFT within committees. Evaluation shows SCP scales computationally with increased cores and has lower bandwidth consumption than Bitcoin.

Related slideshows

Dns
DnsDns
Dns
 
Virtualization security and threat
Virtualization security and threatVirtualization security and threat
Virtualization security and threat
 
Predicates and Quantifiers
Predicates and QuantifiersPredicates and Quantifiers
Predicates and Quantifiers
 
1 of 36
Download to read offline
SCP: A Computationally-Scalable Byzantine Consensus Protocol For Blockchains Loi Luu, Viswesh Narayanan, Kunal Baweja, Chaodong Zheng, Seth Gilbert, Prateek Saxena School of Computing, National University of Singapore IACR Cryptology ePrint Archive 2015 Yongrae Jo (20172938)
Traditional BFT is Not scalable : Heavy message passing based consensus → Network bandwidth quickly exhausted → Communication efficient protocol
Breakthroughs in BFT Oral Message Algorithm (1982) O(N^f) Fast distributed agreement (1985) O(N^3) or O(Nf^2) PBFT (1999) O(N^2) Randomized BA (2013) O(N polylog(N)) Exponential Polynomial (cubic) Quadratic Sub-linear
My previous seminar(Algorand)
My previous seminar(Algorand) Computation based consensus Message passing based consensus
Computation based consensus ● Reaching consensus via (heavy) computation rather than communication(e.g. PoW) ● Computationally scalable – As the computation power increases in the network, throughput increases as well – Bitcoin is not computationally scalable ● More computing power doesn’t increase its throughput ● SCP is an attempt to find computationally scalable consensus algorithm while keeping the advantages of message passing based consensus
Finding the sweet spot Sweet Spot More Computation More Message passing CPU power Slow Scalable Secure Network bandwidth Fast Not scalable Not secure(in open network)
SCP in a Nutshell PoW Subset Committee Protocol (or Scalable Consensus Protocol) ● Generating identities ● Forming committees ● Shared public randomness ● Prevent sybil attack BFT ● Reaching consensus on a value in normal committee or a block in final committee ● Parallel consensus via committee C1 C2 C3 (Final committee) ● Each committee runs traditional BFT. ● Integrated into single ordered blockchain in final committee Run BFT C4 Stellar Consensus Protocol?
Subset Committee Problem (1) ● Problem Definition: Subset Consensus – Agreement over a subset of transactions – Description ● Assumption – Let there be n identity-less processors, f(< n/3) of which are controlled by a byzantine adversary – Each processor has integer input(x), output(y) and constraint function(mapped to 0 or 1) ● Then, the following condition holds.(next slide)
Subset Committee Problem (2) P1 P2 P3 P4 x1 x2 x3 x4 y1 y2 y3 y4 Subset Consensus Protocol 0 or 1 0 or 1 0 or 1 0 or 1 X Constraint Func. y1 = y2 = y3 = y4 (with prob. p)
SCP Protocol Protocol proceeds in epoch. In each epoch, following steps executed Step1. Committee Formation Step2. Committee Overlay Joins Step3. Intra-committee consensus Step4. Final Consensus Broadcast Step5. Generating Shared Randomness
Committee Formation (1) ● Establish processor’s (virtual) identity via local computation – Generating (IP addr / Public Key / Private Key) – Broadcast (IP addr, Public Key) ● Establish committee – Committee that the processor participates in a epoch – Allocate the identity to random committee via PoW Step 1
Committee Formation (2) 0 0 0 0 0 0 1 1 0 10 0 0 000000...1111 s-bits# of leading zeros Public Key IP Addr. Shared random seed Committee Identity PoW Solution Broadcast (IP, PK, nonce, s-bits) 2s = # of committee SHA256 Step 1
Committee Overlay Join (1) ● Once identities and their committees are established, committee members need a way to establish point-to- point connections with their committee peers ● Directory committee – The first c identities created in the network – All subsequent identities created will contact the directory members to announce their committee membership – Keeps track of the committee membership – When their list for a committee reaches size c, they multicast it to all members of that committee Step 2
Committee Overlay Join (2) Established first c identities 1 Broadcast channel Established Point to Point Channel 2 When new identity is generated, it firstly contacts directory committee 3 Contact When c/2 + 1 messages are received, It accepts the member lists of the committee which it belongs to 4 Receive member list Step 2 First c identities forms directory committee
Intra-committee Consensus (1) ● Runs traditional BFT to agree on a value ● After reaching consensus on a value, send that value to final committee – O(c2) ● Partitioned transactions(values) into independent set for parallelism ● (There was no description on how to partition transactions into independent committee and end-to- end message flow on client’s request) → Let’s assume :) Step 3
Intra-committee Consensus (2) C1 C2 C3 Run BFT C4 Run BFT Run BFT Run BFT Step 3 Each committee runs BFT protocol → O(c2 )
Final Consensus Broadcast (1) ● Merge the results of committees – Set union of all inputs – Create a cryptographic digest (a digital signature) of the final agreed result ● Run the same intra-committee algorithm(BFT) to get verifiable result by at least c/2 + 1 Step 4
Final Consensus Broadcast (2) C1 C2 C3 Run BFT C4 (final committee) Run BFT Run BFT Step 4 Each committee member runs BFT protocol (sames previous intra-committee consensus)
Final Consensus Broadcast (3) C1 C2 C3 C4 (final committee) v1 v2 v3 Step 4 All normal committee members multicast agreed value to members in final committee → O(nc)
Final Consensus Broadcast (4) C1 C2 C3 C4 (final committee) Run BFT Step 4 Final committee runs BFT to check that its members get the same values from normal committee
Final Consensus Broadcast (5) C1 C2 C3 C4 (final committee) Agreed result Agreed result Agreed result Step 4
Generating Shared Randomness (1) ● Final committee generates a set of random strings for PoW in the next epoch ● Two rounds of communication – First round ● Each member of the final committee chooses a random string u consisting of r random bits and broadcasts a hash H(u) to everyone. This serves as a commitment to the random string. – Second round ● Each member of the final committee broadcasts a message containing the random string u itself to everyone ● Users XORs the set of valid random strings received Step 5
Generating Shared Randomness (2) C1 C2 C3 C4 (final committee) H(u1 ), ... H(uc ) H(u): Hash of random string u First Round Send broadcast commitment first H(u1 ), ... H(uc ) H(u1 ), ... H(uc ) Step 5
Generating Shared Randomness (3) C1 C2 C3 C4 (final committee) u1 ...uc H(u): Hash of random string u Second Round Broadcast random string u u1 ...uc u1 ... uc Step 5
Generating Shared Randomness (4) C1 C2 C3 C4 (final committee) Each user XORs over u1 ...uc to get shared random string for random seed for PoW in the next epoch u1 …⊕ ⊕uc u1 …⊕ ⊕uc u1 …⊕ ⊕uc u1 …⊕ ⊕ uc Step 5
In a given epoch, for each committee, we refer to the frst c identities that broadcast a valid proof-of-work for this committee as the members of this committee. (If more than one proof-of-work is broadcasted during the same round, they are ordered lexicographically, and the smallest one is picked.) Security Analysis Defnition 1 (Committee) We say that an epoch has good randomness if: (1) every user has a publically random string of r bits, verifably generated in the previous epoch, with at least r−c/2 bits of entropy, and (2) no user has access to such a verifable random string more than two communication rounds prior to the beginning of the epoch Defnition 2 (Good randomness)
Security Analysis In every epoch with good randomness, for every integer n’ among the frst n’ identities created, at most n’/2 are controlled by the adversary, with probability at least 1 − e(−27n’ /160) Lemma 3 (Good Majority) In every epoch with good randomness, for each committee, at least c/2 + 1 committee members will be honest with probability at least 1−e(−27c/160) . Moreover, the probability of generating c/2 + 1 malicious identities by the end of the epoch is also exponentially small. Lemma 4 (Committees Good)
Security Analysis In every epoch with good randomness, if the directory size is d, then for each committee, with probability at least 1 − e−27c/160 , all honest committee members will correctly adopt the (same) member list for the committee. Lemma 5 (Consistent Committees) In every epoch with good randomness, the honest members agree on a unique value with at least c/2+1 signatures, with probability at least 1− e (−27c/116) Lemma 6 (Consensus)
Security Analysis In every epoch with good randomness, the fnal committee its honest members will broadcast a combined value (from values from other committees) which has at least c/2 + 1 signatures, with probability at least 1 − 2s · (e−27c/160 ). → Termination of protocol(Liveness) Lemma 7 (Final Committee) In every epoch with good randomness, with probability at least 1 − e (−27c/160) : at the end of the epoch every user computes a random string of r bits that: (a) contains at least r −c/2 bits of entropy, and (b) can be verifed as validly generated in that epoch. Moreover, no user knows any of the random strings until at least two rounds prior to the end of the epoch. That is, if epoch e has good randomness, then epoch e+1 also has good randomness. Lemma 8 (Good Randomness)
SCP Blockchain Implementation ● Two layers of Blockchain – Two types of Block ● Consensus block (proposed by final committee) ● Data block (proposed by normal committee) Separating consensus data and transaction data Lazy broadcast Used in consensus protocol Immediate broadcast
Evaluation (Configuration) ● Local network ● SCP by modifying existing Bitcoin client code ● Authenticated BFT protocol for intra-committee consensus ● Committee size(c) = 50 ● 10 / 20 / 40 / 80 CPU cores ● (not known computer hardware spec and # of computer) Bitcoin SCP ● Amazon EC2 platform ● Nakamoto consensus ● Deploy instances in different geographical regions ● 20 / 40 / 80 CPU cores ● (not known # of instances and types of instances)
Evaluation (Computational Scalability) SCP is more computationally scalable Epoch time: 1 minute Block rate remains almost constant regardless of computation power in the network BitcoinBitcoin SCP (more computing power --> more identity, more committee --> more parallel)
Evaluation (Bandwidth consumption)
Conclusion ● SCP is committee based consensus, which partitions users into several committees to achieve scalability and parallelization ● By combining computation based consensus(PoW) and message passing based consensus(BFT), SCP finds sweet spot between the two.
Thanks

More Related Content

SCP

  • 1. SCP: A Computationally-Scalable Byzantine Consensus Protocol For Blockchains Loi Luu, Viswesh Narayanan, Kunal Baweja, Chaodong Zheng, Seth Gilbert, Prateek Saxena School of Computing, National University of Singapore IACR Cryptology ePrint Archive 2015 Yongrae Jo (20172938)
  • 2. Traditional BFT is Not scalable : Heavy message passing based consensus → Network bandwidth quickly exhausted → Communication efficient protocol
  • 3. Breakthroughs in BFT Oral Message Algorithm (1982) O(N^f) Fast distributed agreement (1985) O(N^3) or O(Nf^2) PBFT (1999) O(N^2) Randomized BA (2013) O(N polylog(N)) Exponential Polynomial (cubic) Quadratic Sub-linear
  • 5. My previous seminar(Algorand) Computation based consensus Message passing based consensus
  • 6. Computation based consensus ● Reaching consensus via (heavy) computation rather than communication(e.g. PoW) ● Computationally scalable – As the computation power increases in the network, throughput increases as well – Bitcoin is not computationally scalable ● More computing power doesn’t increase its throughput ● SCP is an attempt to find computationally scalable consensus algorithm while keeping the advantages of message passing based consensus
  • 7. Finding the sweet spot Sweet Spot More Computation More Message passing CPU power Slow Scalable Secure Network bandwidth Fast Not scalable Not secure(in open network)
  • 8. SCP in a Nutshell PoW Subset Committee Protocol (or Scalable Consensus Protocol) ● Generating identities ● Forming committees ● Shared public randomness ● Prevent sybil attack BFT ● Reaching consensus on a value in normal committee or a block in final committee ● Parallel consensus via committee C1 C2 C3 (Final committee) ● Each committee runs traditional BFT. ● Integrated into single ordered blockchain in final committee Run BFT C4 Stellar Consensus Protocol?
  • 9. Subset Committee Problem (1) ● Problem Definition: Subset Consensus – Agreement over a subset of transactions – Description ● Assumption – Let there be n identity-less processors, f(< n/3) of which are controlled by a byzantine adversary – Each processor has integer input(x), output(y) and constraint function(mapped to 0 or 1) ● Then, the following condition holds.(next slide)
  • 10. Subset Committee Problem (2) P1 P2 P3 P4 x1 x2 x3 x4 y1 y2 y3 y4 Subset Consensus Protocol 0 or 1 0 or 1 0 or 1 0 or 1 X Constraint Func. y1 = y2 = y3 = y4 (with prob. p)
  • 11. SCP Protocol Protocol proceeds in epoch. In each epoch, following steps executed Step1. Committee Formation Step2. Committee Overlay Joins Step3. Intra-committee consensus Step4. Final Consensus Broadcast Step5. Generating Shared Randomness
  • 12. Committee Formation (1) ● Establish processor’s (virtual) identity via local computation – Generating (IP addr / Public Key / Private Key) – Broadcast (IP addr, Public Key) ● Establish committee – Committee that the processor participates in a epoch – Allocate the identity to random committee via PoW Step 1
  • 13. Committee Formation (2) 0 0 0 0 0 0 1 1 0 10 0 0 000000...1111 s-bits# of leading zeros Public Key IP Addr. Shared random seed Committee Identity PoW Solution Broadcast (IP, PK, nonce, s-bits) 2s = # of committee SHA256 Step 1
  • 14. Committee Overlay Join (1) ● Once identities and their committees are established, committee members need a way to establish point-to- point connections with their committee peers ● Directory committee – The first c identities created in the network – All subsequent identities created will contact the directory members to announce their committee membership – Keeps track of the committee membership – When their list for a committee reaches size c, they multicast it to all members of that committee Step 2
  • 15. Committee Overlay Join (2) Established first c identities 1 Broadcast channel Established Point to Point Channel 2 When new identity is generated, it firstly contacts directory committee 3 Contact When c/2 + 1 messages are received, It accepts the member lists of the committee which it belongs to 4 Receive member list Step 2 First c identities forms directory committee
  • 16. Intra-committee Consensus (1) ● Runs traditional BFT to agree on a value ● After reaching consensus on a value, send that value to final committee – O(c2) ● Partitioned transactions(values) into independent set for parallelism ● (There was no description on how to partition transactions into independent committee and end-to- end message flow on client’s request) → Let’s assume :) Step 3
  • 18. Final Consensus Broadcast (1) ● Merge the results of committees – Set union of all inputs – Create a cryptographic digest (a digital signature) of the final agreed result ● Run the same intra-committee algorithm(BFT) to get verifiable result by at least c/2 + 1 Step 4
  • 19. Final Consensus Broadcast (2) C1 C2 C3 Run BFT C4 (final committee) Run BFT Run BFT Step 4 Each committee member runs BFT protocol (sames previous intra-committee consensus)
  • 20. Final Consensus Broadcast (3) C1 C2 C3 C4 (final committee) v1 v2 v3 Step 4 All normal committee members multicast agreed value to members in final committee → O(nc)
  • 21. Final Consensus Broadcast (4) C1 C2 C3 C4 (final committee) Run BFT Step 4 Final committee runs BFT to check that its members get the same values from normal committee
  • 22. Final Consensus Broadcast (5) C1 C2 C3 C4 (final committee) Agreed result Agreed result Agreed result Step 4
  • 23. Generating Shared Randomness (1) ● Final committee generates a set of random strings for PoW in the next epoch ● Two rounds of communication – First round ● Each member of the final committee chooses a random string u consisting of r random bits and broadcasts a hash H(u) to everyone. This serves as a commitment to the random string. – Second round ● Each member of the final committee broadcasts a message containing the random string u itself to everyone ● Users XORs the set of valid random strings received Step 5
  • 24. Generating Shared Randomness (2) C1 C2 C3 C4 (final committee) H(u1 ), ... H(uc ) H(u): Hash of random string u First Round Send broadcast commitment first H(u1 ), ... H(uc ) H(u1 ), ... H(uc ) Step 5
  • 25. Generating Shared Randomness (3) C1 C2 C3 C4 (final committee) u1 ...uc H(u): Hash of random string u Second Round Broadcast random string u u1 ...uc u1 ... uc Step 5
  • 26. Generating Shared Randomness (4) C1 C2 C3 C4 (final committee) Each user XORs over u1 ...uc to get shared random string for random seed for PoW in the next epoch u1 …⊕ ⊕uc u1 …⊕ ⊕uc u1 …⊕ ⊕uc u1 …⊕ ⊕ uc Step 5
  • 27. In a given epoch, for each committee, we refer to the frst c identities that broadcast a valid proof-of-work for this committee as the members of this committee. (If more than one proof-of-work is broadcasted during the same round, they are ordered lexicographically, and the smallest one is picked.) Security Analysis Defnition 1 (Committee) We say that an epoch has good randomness if: (1) every user has a publically random string of r bits, verifably generated in the previous epoch, with at least r−c/2 bits of entropy, and (2) no user has access to such a verifable random string more than two communication rounds prior to the beginning of the epoch Defnition 2 (Good randomness)
  • 28. Security Analysis In every epoch with good randomness, for every integer n’ among the frst n’ identities created, at most n’/2 are controlled by the adversary, with probability at least 1 − e(−27n’ /160) Lemma 3 (Good Majority) In every epoch with good randomness, for each committee, at least c/2 + 1 committee members will be honest with probability at least 1−e(−27c/160) . Moreover, the probability of generating c/2 + 1 malicious identities by the end of the epoch is also exponentially small. Lemma 4 (Committees Good)
  • 29. Security Analysis In every epoch with good randomness, if the directory size is d, then for each committee, with probability at least 1 − e−27c/160 , all honest committee members will correctly adopt the (same) member list for the committee. Lemma 5 (Consistent Committees) In every epoch with good randomness, the honest members agree on a unique value with at least c/2+1 signatures, with probability at least 1− e (−27c/116) Lemma 6 (Consensus)
  • 30. Security Analysis In every epoch with good randomness, the fnal committee its honest members will broadcast a combined value (from values from other committees) which has at least c/2 + 1 signatures, with probability at least 1 − 2s · (e−27c/160 ). → Termination of protocol(Liveness) Lemma 7 (Final Committee) In every epoch with good randomness, with probability at least 1 − e (−27c/160) : at the end of the epoch every user computes a random string of r bits that: (a) contains at least r −c/2 bits of entropy, and (b) can be verifed as validly generated in that epoch. Moreover, no user knows any of the random strings until at least two rounds prior to the end of the epoch. That is, if epoch e has good randomness, then epoch e+1 also has good randomness. Lemma 8 (Good Randomness)
  • 31. SCP Blockchain Implementation ● Two layers of Blockchain – Two types of Block ● Consensus block (proposed by final committee) ● Data block (proposed by normal committee) Separating consensus data and transaction data Lazy broadcast Used in consensus protocol Immediate broadcast
  • 32. Evaluation (Configuration) ● Local network ● SCP by modifying existing Bitcoin client code ● Authenticated BFT protocol for intra-committee consensus ● Committee size(c) = 50 ● 10 / 20 / 40 / 80 CPU cores ● (not known computer hardware spec and # of computer) Bitcoin SCP ● Amazon EC2 platform ● Nakamoto consensus ● Deploy instances in different geographical regions ● 20 / 40 / 80 CPU cores ● (not known # of instances and types of instances)
  • 33. Evaluation (Computational Scalability) SCP is more computationally scalable Epoch time: 1 minute Block rate remains almost constant regardless of computation power in the network BitcoinBitcoin SCP (more computing power --> more identity, more committee --> more parallel)
  • 35. Conclusion ● SCP is committee based consensus, which partitions users into several committees to achieve scalability and parallelization ● By combining computation based consensus(PoW) and message passing based consensus(BFT), SCP finds sweet spot between the two.