Unit 2
Unit 2
DESIGN KIT-061
Unit-2
By-
Shrankhla Saxena
Assistant professor
CSIT Dept.
Requirements for the consensus
protocols
• The consensus problem requires agreement among a number of processes (or
agents) for a single data value. Some of the processes (agents) may fail or be
unreliable in other ways, so consensus protocols must be fault tolerant or
resilient. The processes must somehow put forth their candidate values,
communicate with one another, and agree on a single consensus value.
• The consensus problem is a fundamental problem in control of multi-agent
systems. One approach to generate consensus is for all processes (agents) to
agree on a majority value. In this context, a majority requires at least one more
than half of available votes (where each process is given a vote). However, one or
more faulty processes may skew the resultant outcome such that consensus may
not be reached or reached incorrectly.
Requirements for the consensus
protocols
• Protocols that solve consensus problems are designed to deal with limited
numbers of faulty processes. These protocols must satisfy a number of
requirements to be useful. For instance, a trivial protocol could have all processes
output binary value 1. This is not useful and thus the requirement is modified
such that the output must somehow depend on the input. That is, the output
value of a consensus protocol must be the input value of some process. Another
requirement is that a process may decide upon an output value only once and
this decision is irrevocable. A process is called correct in an execution if it does
not experience a failure. A consensus protocol tolerating halting failures must
satisfy the following properties.
• Termination: Eventually, every correct process decides some value.
• Integrity: If all the correct processes proposed the same value v then any correct
process must decide v
• Agreement: Every correct process must agree on the same value.
Requirements for the consensus
protocols
• In evaluating the performance of consensus protocols two factors of interest
are running time and message complexity. Running time is given in Big O notation in
the number of rounds of message exchange as a function of some input parameters
(typically the number of processes and/or the size of the input domain). Message
complexity refers to the amount of message traffic that is generated by the protocol.
Other factors may include memory usage and the size of messages.
• Formal requirements for a consensus protocol may include:
• Agreement: All correct processes must agree on the same value.
• Weak validity: For each correct process, its output must be the input of some correct
process.
• Strong validity: If all correct processes receive the same input value, then they must all
output that value.
• Termination: All processes must eventually decide on an output value
Proof of Work
• The idea for Proof of Work(PoW) was first published in 1993 by Cynthia Dwork
and Moni Naor and was later applied by Satoshi Nakamoto in the Bitcoin paper in
2008.
• Proof of Work consensus is the mechanism of choice for the majority of
cryptocurrencies currently in circulation.
• The term “proof of work” was first used by Markus Jakobsson and Ari Juels in a
publication in 1999.
Proof of Work
• Proof of Work(PoW) is the original consensus algorithm in a blockchain network. The
algorithm is used to confirm the transaction and creates a new block to the chain. In this
algorithm, miners (a group of people) compete against each other to complete the
transaction on the network.
• The process of competing against each other is called mining. As soon as miners successfully
created a valid block, he gets rewarded. The most famous application of Proof of Work(PoW)
is Bitcoin.
• Producing proof of work can be a random process with low probability. In this, a lot of trial
and error is required before a valid proof of work is generated.
• The main working principle of proof of work is a mathematical puzzle which can easily prove
the solution. Proof of work can be implemented in a blockchain by the Hashcash proof of
work system.
• A block is composed of a block number, data field, cryptographic hash associated with it and
a nonce. The nonce is responsible for making the block valid.
Proof of Work
• In the puzzle game, bitcoin software creates a challenge, and there is a game begins.
• This game involves all miners competing against each other to solve the challenges,
and this challenge will take approximately 10 minutes to be completed.
• Every single miner starts trying to find the solution to that one Nonce that will satisfy
the hash for the block.
• At some specific point, one of those miners in the global community with higher
speed and great hardware specs will solve the cryptography challenge and be the
winner of the game.
• Now, the rest of the community will start verifying that block which is mined by the
winner. If the nonce is correct, it will end up with the new block that will be added to
the blockchain. The concept of generating a block provides a clear explanation of
proof of work(PoW).
Proof of Work
• Main issues with the Proof-of-Work consensus: The Proof-of-Work consensus
mechanism has some issues which are as follows:
• The 51% risk: If a controlling entity owns 51% or more than 51% of nodes in the network,
the entity can corrupt the blockchain by gaining the majority of the network.
• Time consuming: Miners have to check over many nonce values to find the right solution
to the puzzle that must be solved to mine the block, which is a time consuming process.
• Resource consumption: Miners consume high amounts of computing power in order to
find the solution to the hard mathematical puzzle. It leads to a waste of precious
resources(money, energy, space, hardware). It is expected that the 0.3% of the world’s
electricity will be spent to verify transactions by the end of 2018.
• Transaction confirmation takes about 10–60 minutes. So, it is not an instantaneous
transaction; because it takes some time to mine the transaction and add it to the
blockchain thus committing the transaction.
Scalability Aspects of Blockchain
Consensus Protocol: Factors
• Cost & Capacity: The cost and capacity factor in scalability implies the
requirement of storing a large quantity of data on the blockchain. You have to
store data starting from the genesis block to the most recent transactions.
However, every node in the blockchain network does not have the adequate
resources and capacity for storing such a massive amount of information.
• Networking: In the case of every transaction on the blockchain, it is broadcasted
across all nodes. Subsequently, a block is again transmitted to all nodes when it is
mined. Therefore, the process can consume substantial network resources
alongside increasing propagation delay. Therefore, it is important to have a
reliably efficient mechanism for data transmission.
• Throughput: Another important aspect in the context of the blockchain scalability
problem refers to throughput. Blockchain throughput refers to the time required
for confirming one transaction and the size of the block for the transaction. With
more transactions, the size of blocks would increase thereby requiring additional
resources.
Scalability Aspects of Blockchain Consensus
Protocol: Factors Affecting Scalability
• Limitations : In event of processing a new transaction, each node adds
information regarding the transaction in the ledger. As a result, the increasing
transaction history could topple the overall system. In addition, blockchain
networks must maintain all data with accuracy to safeguard the levels of trust.
Furthermore, blockchain also experiences issues of limitations in terms of
hardware. Most of the issues in blockchain scalability problems arise due to
hardware limitations. As the blockchain network expands further, it is difficult to
set up and maintain the hardware required for operating nodes.
Permissioned Blockchains : Design goals
• The speed in which your blocks will need to be written into the blockchain. Consensus
formation can take time. If consensus is faster, the trust guarantees will be much lower
(and vice versa).
• What type of network will you be using? Is it synchronous, partially synchronous,
eventually synchronous or asynchronous?. For example, the Internet does not guarantee
message delivery and is generally considered to be eventually synchronous.
• How many miners, writers, or validators do you think you will need? These special
blockchain nodes are the ones which will select blocks to write to the chain.
• How “final” does a block need to be? Banks and other financial institutions most often
expect any transactions to be immediately final (that is, they cannot be rolled back). Some
consensus protocols treat block decisions to be conditional on future actions. In others,
blocks may eventually be final but are not immediately so.
• To what degree do you put your trust in the nodes/operators? Are you trying to protect
your blockchain from nodes that might crash, nodes that might actively attempt to hack
the blockchain, or both?
In a permissioned blockchain, choosing the
right consensus protocol for permissioned
blockchain depends on factors like the extent
of decentralization required (For example,
how much the participants in a network trust
each other, the number of permissions that
must be granted to all the participants to carry
out important tasks on the network etc).
Types of consensus protocol for
permissioned blockchain networks
• Permissioned blockchains cannot use the same type of
consensus models that are seen in permisionless
blockchains. There are numerous variants of such
consensus algorithms that are available today for
permissioned blockchains. The most popular ones that
are being implemented in many organizations around
the world are:
1. PBFT Consensus
• Permissioned blockchains usually use pbft algorithms. One of the
models that is used to facilitate consensus in blockchain is the
practical byzantine fault tolerance algorithm (PBFT).
• In this model, each node exists in an internal state, which means that
it will maintain an ongoing specific information or status). Each time
a node receives a message, they use the message with respect to
their internal state to perform a computation or operation.
• Consequently, this computation will send messages to other nodes to
ask if the transaction is valid. After receiving verification from all of
the other nodes, the first node will broadcast that decision with all
the other participants in the network.
• A consensus decision is achieved based on the total confirmations
submitted by all the nodes.
PBFT Consensus Contd…
• PBFT can be very beneficial for low latency storage systems,
This type of model is often used in digital assets backed
platforms that don’t need a great amount of capacity, but
carry out a large number of transactions.
• PBFT makes sure that the transaction records within the
network are accurate. A few examples of permissioned
blockchains that use this model are Hyperledger and Chain.
2. Federated Consensus
• In Federated Consensus, each node in the blockchain network puts
their trust in a set of signers who help them reach the consensus
stage.
• In order to carry out the process in an efficient manner, the block
signers use a single block generator, which receives, holds and filters
all the transactions.
• The generator’s signature is used to coordinate with the signers for
the block validation process. Each block signer will verify the block
which is signed by the block generator and which fulfills the certain
conditions set by the network.
• Once the block generator receives enough signatures from the
network, the block will get published to the network.
• This model guarantees security and transparency . It is ideal for use
cases such as cross border remittance, real time KYC etc.
Common examples of blockchains that use this model are Stellar and
Ripple.
3. Round Robin Consensus
• In Round Robin Consensus, validators take part in the consensus process by signing votes
for blocks. Usually, there are three main types of votes: a prevote, a precommit and a
commit.
• To receive more than two third of commits means to receive commits from a two third
majority of validators.
• A block is considered to be committed by the network when a two third majority of
validators have signed and broadcasted commits for that block.
• At each height of the blockchain a round-based protocol is run to determine the next block.
• Each round consists of three steps (Propose, Prevote, and Precommit), along with two
special steps Commit and NewHeight.
• The Propose, Prevote, and Precommit steps each take one third of the total time allocated
for that round.
• Each round is longer than the previous round followed by a small fixed increase of time.
• This allows the network to eventually achieve consensus in a limited concurrent network.
Round Robin Consensus Contd…
• Round robin consensus process doesn’t rely on a single
participant for the block validation process.
• In this model, several nodes play a major role in validating and
signing transactions. which makes this process more secure when
compared to other consensus processes.
• There are also lower chances of double spend attacks due to the
voting power distribution among trusted nodes.
• Round robin consensus mechanism is ideal for the trade, finance
and supply chain industries.
• Some well known permissioned blockchains that use the Round
Robin consensus method include Multichain and Tendermint.