Blockchain consensus algorithms

Blockchain consensus algorithms

• 1.
  Blockchain Consensus Algorithms Anurag Dashputre
• 2.
  Agenda ● What isa Consensus Algorithm? ● Why we need them in Blockchain? ● Few popular consensus algorithms ● Consensus Algorithms - Comparative study
• 3.
  What is aConsensus Algorithm? Consensus: A generally accepted opinion or decision among a group of people. Algorithm: A set of rules for accomplishing a task in a certain number of steps. Combining the two, you get: a set of rules and number of steps for accomplishing a generally accepted decision among a group of people.
• 4.
  Why we needthem in Blockchain? Consensus algorithms are put in place to ensure a group of people agree that all transactions are validated and authentic. Consensus algorithms ensure a network of random people can achieve consensus about transactions in the network. People have to cooperate and grow accustomed to these new decentralized networks that have no central authority, unlike the governments, institutions, and businesses we are used to. Consensus mechanisms secure a blockchain’s transactions by preventing the double-spending problem. At its very basic, double-spending is much like sending a photo to someone digitally. You do not send the original picture, but a copy and now two people have the same picture. Imagine if someone could do this with cryptocurrencies.
• 5.
  Few popular consensusalgorithms Algorithm Description PoW A Proof of Work is a piece of data which is difficult (costly, time-consuming) to produce but easy for others to verify and which satisfies certain requirements. Producing a proof of work can be a random process with low probability so that a lot of trial and error is required on average before a valid proof of work is generated. PoS Proof of Stake (PoS) concept states that a person can mine or validate block transactions according to how many coins he or she holds. This means that the more Bitcoin or altcoin owned by a miner, the more mining power he or she has. PoA Proof of Authority consensus protocols are used when participants are known to each other and there is a level of trust between them. PBFT Practical Byzantine Fault Tolerance (pBFT) is a specific case and the optimization of the Byzantine Fault Tolerance network ability. Byzantine Fault Tolerance is the ability of a network to unmistakably reach a consensus despite malicious nodes’ attempts to propagate false data to other peers. IBFT Byzantine Fault Tolerant (leader is not trusted). Each block requires multiple rounds of voting RAFT Raft is a consensus algorithm for managing a replicated log. It is CFT consensus, as opposed to BFT because in Raft the leader is assumed to always act correctly (honestly).
• 6.
  RAFT RAFT is aCFT (crash fault tolerant) consensus algorithm which relies on a trusted leader to form consensus and apply changes to ledger. Node can be in 1 of 3 states: Follower, Candidate or Leader. And has these processes 1. Leader Election - All nodes start in the follower state. If followers don't hear from a leader then they can become a candidate. The candidate then requests votes from other nodes. The candidate becomes the leader if it gets votes from a majority of nodes. Leader election process: Follower ⇒ Election Timeout happens ⇒ Become Candidate ⇒ Get Majority Votes ⇒ Become Leader, send heartbeat messages ⇒ After Heartbeat Timeout ⇒ Become Follower (other follower goes to same cycle to become Leader) 2. Log Replication - All changes to the system now go through the leader. Each change is added as an entry in the node's log, which is uncommitted at the moment. To commit the entry the node first replicates it to the follower nodes in next heartbeat and waits until a majority of nodes have written the entry. The entry is now committed on the leader node and notifies it to follower about the successful commit.
• 7.
  POA • PoA relieson a set of trusted nodes called Authorities that use a simplified messaging algorithm to achieve better performance • Each block signed by only one signature – that of the proposer’s. • Forking will happen in a network with more than 4 authorities.
• 8.
  PBFT • The PBFTmodel primarily focuses on providing a practical Byzantine state machine replication that tolerates "f" Byzantine faults (malicious nodes) in system with "3f +1" nodes. E.g if f =1, total nodes = 4, faulty node = 1. • Essentially, all of the nodes in the PBFT model are ordered in a sequence with one node being the primary node (leader) and the others referred to as the backup nodes. Leader is selected on round robin basis (or few other protocols). • The amount of malicious nodes in the network cannot simultaneously equal or exceed ⅓ of the overall nodes in the system • The algorithm effectively provides both liveness and safety as long as at most (n-⅓), where n represents total nodes, are malicious or faulty at the same time. • Each round of PBFT consensus (called views) comes down to 4 phases. This model follows more of a “Commander and Lieutenant” format than a pure Byzantine Generals’ Problem, where all generals are equal, due to the presence of a leader node. The phases are below. 1. A client sends a request to the leader node to invoke a service operation. 2. The leader node multicasts the request to the backup nodes. 3. The nodes execute the request and then send a reply to the client. 4. The client awaits f + 1 (f represents the maximum number of nodes that may be faulty) replies from different nodes with the same result. This result is the result of the operation.
• 9.
  PBFT (Continued) Sequence ofsteps 1. Request - From Client to Leader node 2. Follows 3 phase protocol a. Pre-Prepare - Leader sends Pre-Prepare message to all. Nodes accept message if it is valid node. b. Prepare - If node accepts Pre-Prepare message, it sends Prepare message to everyone else and accepted if nodes are valid. c. Commit - Nodes sent commit to messages to all nodes. 3. Reply - From all nodes to Client
• 10.
  IBFT The IBFT consensusmechanism comprises the following components: ● A PBFT inspired group consensus model. ● A process by which members can be added/removed from the validating group. Its ideal if nodes belong to your fiercest competitors, or may be susceptible to compromises. Its is one of the many flavours of PoA and provides the following benefits: ● Immediate block finality. There’s only 1 block proposed at a given chain height. The single chain thus removes forking, uncle blocks, and the risk that a transaction may be “undone” once on the chain at a later time. ● Reduced time between blocks. The effort needed to construct and validate blocks is significantly reduced (in particular with respect to PoW), greatly increasing the throughput of the chain. ● High data integrity and fault tolerance. IBFT uses a group of validators to ensure the integrity of each block being proposed. A super-majority (~66%) of these validators are required to sign the block prior to insertion to the chain, making block forgery very difficult. The ‘leadership’ of the group also rotates over time — ensuring a faulty node cannot exert long term influence over the chain. ● Operationally flexible. The group of validators can be modified in time, ensuring the group contains only full-trusted nodes.
• 11.
  IBFT - ConsensusModel IBFT uses a pool of validating nodes (Validators) operating on an Ethereum network to determine if a proposed block is suitable for addition to the chain. One node of the Validators is arbitrarily selected as the Proposer and is responsible for constructing a block at the block-interval and sharing said block with the group. If a super-majority of the Validators deem the block to be valid it is added to the blockchain. At the completion of the consensus round, the Validators may select a new Proposer which will be responsible for providing the candidate Block at the next block interval. The members of the validation group may change over time through a voting mechanism. Members can be added or removed through a majority ((N/2) + 1) vote.
• 12.
  Consensus Algorithms -Comparative study Algorithm Public/ Private/ Both No. of Validators Finality Malicious / Malfunctioning Nodes Trust Level Energy Usage PoW Public Many Probabilistic <50% Trustless Huge PoS Public Many Probabilistic <50% Trustless Low PBFT Private Many, with periodic leader rotation OR vote based election Instant (N-1)/3 Some trust Low IBFT Private Many, with periodic leader rotation Instant (N-1)/3 Some trust Low POA (Clique) Both 1 Probabilistic (within (N/2)+1 blocks) None All trusted nodes Low RAFT Private 1 Instant None All trusted nodes Low