Consensus Protocol

Prof. J. Ujwala Rekha

 Introduction
• A consensus protocol in blockchain is a set of
rules and procedures for attaining a unified
agreement (consensus) between the
participating nodes on the status of the
network.
 Byzantine Generals Problem
• Two Byzantine (Roman) armies led by different generals are preparing to
attack a fortified city.
• They are based on either side of the city. The city is strong enough to
withstand an individual attack of either army, but not strong enough to
defend itself from a coordinated attack by the two armies at the same time.
• In other words, the two armies must attack the city at the same time to win
the battle.
• The two generals, say General A and General B need to agree on the time
of the attack. The only way of communication is by sending messengers
through the city.
• The simplest way to send the message will be for one general to take the
leadership role and send a messenger through the enemy lines with a
proposed day and time.
• The second general, on receiving the message, sends back the
acknowledgment or agreement message back to the first general.
 Byzantine Generals Problem
Here are the issues that may hamper victory:
• General A will hesitate to attack at the appointed time if he does not get the
acknowledgment from General B.
• The enemies could capture General A’s messenger and the intercept the
message.
• General A’s message could be intercepted and replaced with a fake message.
• General B may hesitate to attack as he cannot verify the authenticity of the
message.
• General B may send an acknowledgment message, but there is no assurance
that General B’s messenger will not be caught by the enemies and the message
intercepted and/or replaced.
• One of the Generals could potentially be a traitor.
• The lack of confidence or doubt between the Generals may trickle down to the
soldiers in the army leading to some deserters, thus compromising the strength
of the army. The desertion can lead to defeat even if there is a coordinated
attack.
 Byzantine Generals Problem
• There is no way for either of the generals to guarantee that
their counterparts have received their message in Byzantine
Generals Problem.
• Here, the dilemma is between two generals or two
participants.
• In a distributed network, the dilemma is between all the
participants or nodes.
• All the participants need to verify and reach agreements
neutralizing corrupt parties and disseminating false and
unreliable information.
• Blockchain’s key feature of consensus mechanism or
consensus algorithms is seen as a solution to the Byzantine
Generals Problem.
 Objectives of Consensus Protocol
• Unified agreement: there should be a unified agreement on
which data is valid and accurate.
• Fault-tolerant: Even if some of the nodes are unresponsive,
the system must be functional.
• Collaborative and participatory: All nodes should
participate in the overall process.
• Egalitarianism: there should not be any discrimination
between nodes.
• Incentivization: incentivize the miners that validate new
transactions.
• Prevent double-spend: Digital currency or token must not
be spent more than once by falsification or duplication
 Consensus Algorithms
• Proof of Work
• Proof of Elapsed Time
• Proof of Stake
• Proof of Authority
• Practical Byzantine Fault Tolerance
• RAFT algorithm
 Proof of Work (PoW)
• Several nodes of the distributed ledger called miners compete to solve a
complicated mathematical problem based on a cryptographic hash
algorithm. The solution found is called PoW.
• Disadvantages:
– Time-consuming: Miners have to iterate over many nonces before
finding the right solution, which is a time-consuming process
– High energy consumption: Miners conduct significant work in
terms of processing power and electricity to find the nonce for
creating the winning hash. As only one miner can be successful, for
all other miners who competed, it is wasted energy.
– 51% risk: A person or a group gaining control of over 51% of the
network’s computing power can control the validation process.
 Proof of Elapsed Time (PoET)
• This aims to reduce the energy consumption associated
with PoW’s mining process.
• Each miner node in the blockchain network is provided
with a randomized timer object from a trusted code that
generates a random wait time.
• This method of randomization aims to circumvent any
attempt by a miner to get a timer with a shorter period.
• The miner who completes the designated waiting time
commits a new block to the blockchain and broadcasts
the relevant information across the blockchain network.
• The process is then repeated for the discovery of the
next block.
 Proof of Stake (PoS)
• In PoS, the mining nodes are called validators or forgers or
delegates.
• A forger has to commit some of his/her stake (cryptocurrency) in
the network as collateral to be in the running for a chance to
validate the transaction.
• An algorithm will randomly select a forger based on the
percentage stake or collateral he or she has put forward.
• Validating nodes can forge or create new blocks proportional to
the amount they have staked; i.e., a node with a 10% stake in the
network can validate 10% of transactions.
• Energy consumption is less here as compared to PoW consensus.
Also, the forgers are paid a transaction fee as against the block
reward of PoW consensus.
 Delegated Proof of Stake
• Delegated Proof of Stake (DPoS) is a variation of
the PoS consensus mechanism.
• Here, the network participants or nodes use their
cryptocurrency or tokens to vote for the delegates.
• Just as in PoS, the delegates are responsible for
validating transactions and maintaining the
blockchain ledger.
• These elected delegates are called witnesses. The
more the crypto-coins or tokens, the more the
voting power.
 Proof of Authority
• Unlike PoS/Dpos, instead of staking coins or tokens, the validators stake
their identity.
• The identities of the validators are public and verifiable by a reliable third
party, such as a public notary database.
• This incentivizes the validators to act in the best interest of the network, for
otherwise, their reputation is ruined.
• The validators are ideally limited to 25 or less to ensure the efficiency and
security of the network.
• The following conditions must be met to identify validators: –
– Validators must have a valid identity in the public domain that must
match the records found in the public notary database.
– The authority needs to be uniform and unbiased for all validators.
– Eligibility criteria for staking identity must be stringent to ensure the
trustworthiness of the validator.
Practical Byzantine Fault Tolerance
• It works on the format of the Byzantine Generals Problem, where all
“generals” (nodes) are considered equal and take their work instruction
from the leader node.
• The leader node is the primary node, and all other nodes are called
secondary or backup nodes.
• The leader is selected at random in a round-robin fashion.
• A node client sends a transaction request to the leader who then broadcasts
it to all the backup nodes.
• The leader and backup nodes will use the message with their internal state
to run computation and transmit the decision result to all the client nodes.
• The final decision is arrived at based on the agreement of the majority.
• A high hash rate is not required as pBFT relies on the minimum number of
backup nodes to confirm trust, namely (f+1), where f represents the
maximum number of faulty nodes. Hence, it is not computationally
intensive and as a result, there is substantial energy saving.
 RAFT
• Nodes can have three states: leader, follower, and candidate.
• RAFT uses randomized timers to elect the leader for each term.
• If a leader is not elected in a term, candidates will time out and start the election for
the next term.
• The leader candidates log must be more up-to-date than the follower logs.
• If a candidate’s log is less up-to-date than a potential follower, then the candidate is
rejected by the follower.
• A node starts as a follower expecting a “heartbeat” from a leader. If it does not
receive it within the “election time,” it assumes the leader is dead and takes the
candidate state to send out a “RequestVote.”
• If the candidate node receives majority approvals from follower nodes, it transitions
to a leader state.
• Only the leader can append log entries based on client requests. When the leader
node receives a request, it appends the entry to its log as a new entry and sends it to
all the follower nodes.
• After receiving the confirmation from the majority of the followers, the leader, in
turn, commits the message and sends a confirmation (heartbeat) message to the
client and followers.
• RAFT based consensus is used in Quorum for consortium settings.
Other Consensus Mechanisms
• Proof of Stake Anonymous (PoSA): Nodes are
incentivized for “cloaking” the transaction. The cloaking
nodes provide the transaction with inputs and outputs,
rendering it close-to-impossible to establish the identity of
the receiver or the sender of a transaction and ensuring
anonymity.
• Leased Proof of Stake (LPoS): In PoS, one needs a large
stake to get a chance to validate a block. Hence many users
with low balances do not get a chance to generate a block.
The LPoS mechanism enables users to sublet their balances
to staking nodes. This allows for small holders also to forge
a block of transaction in the blockchain. Any reward
received is shared proportionally.
Other Consensus Mechanisms
• Proof of Importance (PoI): The PoI works on the
principle that users with the highest balance or
users who provide maximum value to the network
should be incentivized.
• Proof of Storage: Instead of going through every
single transaction listed on the blockchain, the
user can only see the transactions that are of
particular importance to him.
• Proof of Burn: The node that burns more coins,
gets more change to mine blocks.
Other Consensus Mechanisms
• Proof of Activity: It is a hybrid of PoW and PoS consensus
mechanisms. It starts with miners vying to be the first to solve the
cryptographic puzzle and claim their reward.
– However, the blocks being mined are not transactions but
templates with header information and the mining reward
address.
– Once the template block is mined, the PoS selects a random
group of validators to sign the block.
– Once all validators sign the block, it becomes part of the
blockchain. If the block remains unsigned by a few, it is
discarded, and the next winning block template is used.
– Proof of Activity reduces the risk of a 51% attack to zero.
– However, the energy consumption issue is not eased.
Other Consensus Mechanisms
• Proof of Capacity (PoC): In the PoC mechanism, the
miners will first “plot” their hard drives, i.e., they will
create a list of all possible nonce values through
repeated hashing of data, including a miner’s account.
– In other words, the miners will compute the solutions and
store them ahead of time.
– Once the actual mining starts, the miner with the fastest
solution wins the block.
– Using hard drives is said to be 30 times more energy-
efficient than ASIC (application-specific integrated circuit)-
based mining.
– It is also more decentralized as anyone can own a basic
hard drive.
Other Consensus Mechanisms
• Directed Acyclic Graph (DAG): In PoW
consensus, it takes around 10 minutes or more
to create a block, and blocks cannot be created
simultaneously. With DAG, transactions can
run on different chains simultaneously.