Hyperledger Consensus Algorithms

Hyperledger Consensus Algorithms

• 1.
  HYPERLEDGER CONSENSUS ALGORITHMS Mabel Oza
• 2.
  Byzantine General’s Problem- 1982 Enemy City Attack Retreat NOT! Let’s attack!
• 3.
  How does thisrelate 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.
  Consensus
• 5.
  Where that leadsus 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.
  Finding the RightConsensus 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.
  There isn’t onesolution 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.
  The Foundation: PracticalByzantine 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.
  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.
  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.
  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.
  Blockchain & HyperledgerConsensus
• 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.
  Plenum  Based offof 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.
  Apache Kafka • Publishingand 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.
  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.
  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.
  Opportunities Evaluating consensus algorithmsand 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.
  Questions?
• 20.
  Appendix