Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
HYPERLEDGER
CONSENSUS
ALGORITHMS
Mabel Oza
Byzantine General’s Problem - 1982
Enemy City
Attack
Retreat
NOT!
Let’s
attack!
How does this relate to Blockchain?
Byzantine problem highlights the troubles of dealing
with a system filled with indepen...
Consensus
Where that leads us today?
Most blockchain systems are filled with malicious and faulty participants. How does it work?
Al...
Finding the Right Consensus
Consensus Goals
Basics in Evaluating a Consensus for your Project
1. How would you rank the fo...
There isn’t one solution that fits all
Type of Blockchain Description Example
Blockchain Projects
Types of Consensus Used
...
The Foundation: Practical Byzantine Fault
Tolerance (PBFT)
• Inspired several consensus algorithms, RBFT, dBFT, Plenum, et...
The Foundation: PBFT – Phase 1: Pre-Prepare
Client
Sends REQUEST:{Operation to
perform, time stamp, client}
Using P2P mess...
The Foundation: PBFT – Phase 2: Prepare
Replica 1 Replica 2 (f) Replica 3
Replicas accept pre-prepare message if:
- Signat...
The Foundation: PBFT – Phase 3: Commit
Replica 1
SendsCOMMIT: {view*,
sequence #, message digest,
replica id} to each othe...
Blockchain & Hyperledger Consensus
Redundant Byzantine FaultTolerance
(RBFT)
 Redundant (multiple) instances of a BFT protocol executed in parallel
 What i...
Plenum
 Based off of RBFT (Redundant Byzantine FaultTolerance)
 Used for Indy, Hyperledger’s identity management blockch...
Apache Kafka
• Publishing and Subscriber message queue architected as a distribution log
• It is crash fault tolerant but ...
B-Chain & Sumeragi
• There’s an A team (2f + 1 replicas) and a B team (the other replicas), the A
team confirms the transa...
Proof of ElapsedTime (PoET)
• Lottery based consensus
• Hardware based
• Used in Sawtooth Lake, a blockchain platform that...
Opportunities
Evaluating consensus algorithms and finding the right ones to fulfill business needs
Managing Consensus algo...
Questions?
Appendix
Upcoming SlideShare
Loading in …5
×

Hyperledger Consensus Algorithms

1,016 views

Published on

This presentation goes over consensus fundamentals, what consensus algorithms are used in Hyperledger blockchain projects today and how do they work. This presentation was presented at the April 2nd SF Hyperledger Meetup @ PubNub.

Published in: Technology
  • Visit this site: tinyurl.com/sexinarea and find sex in your area for one night)) You can find me on this site too)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area for one night is there tinyurl.com/hotsexinarea Copy and paste link in your browser to visit a site)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Girls for sex are waiting for you https://bit.ly/2TQ8UAY
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Meetings for sex in your area are there: https://bit.ly/2TQ8UAY
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Best site for flirting and sex in your area you can find there: https://bit.ly/2SlcOnO
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Hyperledger Consensus Algorithms

  1. 1. HYPERLEDGER CONSENSUS ALGORITHMS Mabel Oza
  2. 2. Byzantine General’s Problem - 1982 Enemy City Attack Retreat NOT! Let’s attack!
  3. 3. How does this relate to Blockchain? Byzantine problem highlights the troubles of dealing with a system filled with independent and untrustworthy nodes that need to collaborate together and come up with a…
  4. 4. Consensus
  5. 5. Where that leads us today? Most blockchain systems are filled with malicious and faulty participants. How does it work? Algorithms that aim to solve the Bzyantine’s General Problem, BFT (Byzantine FaultTolerant) consensus algorithms *Not all blockchains systems use BFT consensus algorithms, just most of them in Hyperledger do Consensus: Used to find agreement on the order and to validate the correctness of the transaction Consensus Algorithms: Tells the system what to do to achieve consensus • Tells us what steps will be needed to take place • Ex. Proof of Stake Consensus Protocols: Set of rules that determines how the system achieve consensus • Tells us how the algorithm will be used • Ex. Casper in Proof of Stake 1980 – 2000 (Internet) 2001 – 2015 (Distributed Systems) 2016 –Today (Blockchain)
  6. 6. Finding the Right Consensus Consensus Goals Basics in Evaluating a Consensus for your Project 1. How would you rank the following qualities?What are your tradeoffs? • Speed, scalability, and trust 2. What solution are you replacing?What was the existing technology stack? 3. What type of blockchain are you going to use? Permissionless, Permissioned, Federation/Consortium Liveness (Will it Deliver) Each non-faulty node will eventually receive every submitted transaction, assuming communication doesn't fail Safety (Consistency) Same results for same input, no two processes will decide differently
  7. 7. There isn’t one solution that fits all Type of Blockchain Description Example Blockchain Projects Types of Consensus Used Permissionless or Public Anyone can participate, so we don’t know anything about the nodes (generals) involved nor have any control over their actions Bitcoin Ethereum Proof ofWork Proof of Stake Federated or Consortium Chosen parties can only participate, so know something about the nodes (generals) involved but we still can’t influence their actions R3 – Corda EWF (EnergyWeb Foundation) Byzantine FaultTolerance (BFT) Permissioned Chosen parties can only participate, so know something about the nodes (generals) involved but we still can influence their actions Projects that involve sharing employee information across a large organization Byzantine FaultTolerance (BFT)
  8. 8. The Foundation: Practical Byzantine Fault Tolerance (PBFT) • Inspired several consensus algorithms, RBFT, dBFT, Plenum, etc. • Provides liveness & safety as long as less than (n-1)/3 of the machines aren’t faulty • Primary indicates to the other replicas the order to process requests • Nodes can’t freely join or leave, so it’s not perfect for open blockchain • All the nodes that aren’t participating in the pre-prepare phase are the faulty nodes • How does it work? 1. Client sends a request to invoke a service operation to the primary (general) 2. The primary multicasts requests to replicas (other generals) 3. Replicas execute the request and send the reply to the client 4. Client waits for f + 1, f being # of faulty replicas, to reply with the same results Primary Faulty Replica Client
  9. 9. The Foundation: PBFT – Phase 1: Pre-Prepare Client Sends REQUEST:{Operation to perform, time stamp, client} Using P2P messaging* Assigns a sequence # (Specifies the order) Appends to the log Primary Sends PRE-PREPARE:{view*, sequence #, message digest*} to replicas Replica 1 Replica 2 (f) Replica 3 *P2P Messaging: Messages can only be consumed 1 consumer *View: Succession of configurations replicas move through, each view has a primary replica and the rest are backups *Message Digest: the encrypted message *Must be between h & H to prevent primary from exhausting space of sequence # by selecting large ones
  10. 10. The Foundation: PBFT – Phase 2: Prepare Replica 1 Replica 2 (f) Replica 3 Replicas accept pre-prepare message if: - Signature in request and pre-prepare message are correct - It’s in the same view - It hasn’t accepted message with the same view and sequence # - Sequence # is between h and H* (Does the sequence # make sense?) Waiting for 2f prepare messages Sends PREPARE:{message, view*, sequence #, replica id} to each other Appends messages to the log *P2P Messaging: Messages can only be consumed 1 consumer *View: Succession of configurations replicas move through, each view has a primary replica and the rest are backups *Message Digest: the encrypted message *Must be between h & H to prevent primary from exhausting space of sequence # by selecting large ones
  11. 11. The Foundation: PBFT – Phase 3: Commit Replica 1 SendsCOMMIT: {view*, sequence #, message digest, replica id} to each other Replica 2 (f) Replica 3 Replica 0 Appends messages to the log Each executes the operations requested, ensures safety Client All replicas send a digest of the results and one replica sends the actual request *P2P Messaging: Messages can only be consumed 1 consumer *View: Succession of configurations replicas move through, each view has a primary replica and the rest are backups *Message Digest: the encrypted message *Must be between h & H to prevent primary from exhausting space of sequence # by selecting large ones
  12. 12. Blockchain & Hyperledger Consensus
  13. 13. Redundant Byzantine FaultTolerance (RBFT)  Redundant (multiple) instances of a BFT protocol executed in parallel  What if the primary in PBFT is malicious?  They need to be accountable  All instances order the request, but only the master orders are executed  Every master has a replacement (backup) keeping them in check  Performance for every master is closely monitored and compared to its backup  Client requests go to all nodes, when a node receives 2f + 1 copies of the client request it knows that every correct node will eventually receive the request Latency X Scalability X X Trust X X X Secure Backup Master Confirming Request
  14. 14. Plenum  Based off of RBFT (Redundant Byzantine FaultTolerance)  Used for Indy, Hyperledger’s identity management blockchain platform  Difference between RBFT & Plenum: RBFT Plenum Communicates using MAC (Message Authentication Code), fast and less computationally expensive Communicates usingCurve25519 (Elliptic Curve Digital SignatureAlg.), highly secure All nodes should receive the request Only faulty # of nodes + 1 should receive the request Implementation decides on the primary election process Provides a deterministic and non- deterministic election process Implementation decides on blacklisting strategies Provides blacklisting strategies Each replica communicates its message in to each other in a Point 2 Point fashion Replicas can gossip their message Latency X X Scalability X X X Trust X X X Secure
  15. 15. Apache Kafka • Publishing and Subscriber message queue architected as a distribution log • It is crash fault tolerant but not Byzantine FaultTolerant, so we must trust all parties • Used for Fabric, foundational blockchain framework and a plug and play implementation • Has 3 phases endorsement, ordering and validation • Follows an execute, order, validate, update state approach versus a traditional order, execute, update state so transactions don’t have to execute sequentially Latency X X X Scalability X X Trust X Easy to Use Kafka Cluster
  16. 16. B-Chain & Sumeragi • There’s an A team (2f + 1 replicas) and a B team (the other replicas), the A team confirms the transaction and B team peers are the bench warmers • Voting based consensus • Self recovering, chain-based BFT protocol, where the replicas are organized in a chain • Used for Iroha, C++ mobile friendly blockchain platform • The order of processing A verifies the transaction and orders it into the queue nodes is determined by Hijiri, server’s reliability • How does it work? 1) Client sends transaction 2) Leader validation peer signs it and broadcasts it other A replicas 3) A replicas validate the signature(s) and contents of transaction 4) Commits it to A & B after receiving 2f + 1 signs from A 5) Updates the merkle root of the global state 6) Broadcast an ordered list of transactions 7) Valid parts of the merkle tree are shared until the roots match, when nodes are synced with each other Latency X X X Scalability X Trust X Mobile Friendly
  17. 17. Proof of ElapsedTime (PoET) • Lottery based consensus • Hardware based • Used in Sawtooth Lake, a blockchain platform that can accommodate several validators with minimal resource consumption • Uses aTEE (Trusted Execution Environment), i.e. Intel SGX • App code can only be put into the enclave through an SDK • How does it work? 1) Every validator requests a wait time from an enclave a (trusted function) • Validator with the shortest time wins, they’re chosen as the leader 2) Enclave provides them with a timer 3) Enclave checks the timer, to see if they waited their specified time, and if they did they can claim leadership Latency X Scalability X XX Trust X Scalable
  18. 18. Opportunities Evaluating consensus algorithms and finding the right ones to fulfill business needs Managing Consensus algorithms, how do we know it’s doing it’s job? Experiences and takeaways from working with these algorithms
  19. 19. Questions?
  20. 20. Appendix

×