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.

1. HYPERLEDGER
CONSENSUS
ALGORITHMS
Mabel Oza

2. Byzantine General’s Problem - 1982
Enemy City
Attack
Retreat
NOT!
Let’s
attack!

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. Consensus

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. 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. 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. 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. 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 & Hyperledger Consensus

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 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. 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. 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 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. Questions?

20. Appendix