BLOCKCHAIN

ARCHITECTURE
KCA041
Unit 2
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 generating 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 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 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.
Scalability Aspects Blockchain
Consensus Protocol: Factors
Affecting Scalability
• Transaction Fees: The next critical factor which leads to major scalability
challenges in blockchain refers to the high transaction fees. The growing
popularity of blockchain networks has led to more complexities in processes for
validating transactions due to the demand for higher computation power for
mining. Users have to pay a specific fee for the verification of their transactions.
With the continuously expanding blockchain networks, users are eager to pay
higher transaction fees for the verification of their transactions. However, it is
also important to note that many other transactions remain in the queue
without processing for a long time.
Scalability Aspects Blockchain
Consensus Protocol: Factors
Affecting Scalability
• Block Size: Block size is also a notable aspect for understanding why is scalability
an issue for blockchain. The increasing number of transactions in blockchain
networks leads to a time-intensive process for executing transactions. For
example, every block in the Bitcoin blockchain network had the size of 1 Mb in
the initial days and they contained almost 2,020 transactions. On the other hand,
the growing number of transactions in the network has led to increasing block
size thereby affecting scalability.
Scalability Aspects Blockchain
Consensus Protocol: Factors
Affecting Scalability
• Response Time: All transactions in the blockchain network should pass a
validation process. Generally, transactions have to wait for long periods of time
for validation, considering the number of transactions in the queue. For example,
the Bitcoin network implies the need for almost 10 minutes for building a new
block. The wait time for transaction validation increases during peak times. The
response time is directly related to high transaction fees as one of the notable
factors resulting in the blockchain scalability problem.
• Therefore, the prominent factors which lead to the blockchain scalability
challenge imply that the growing number of transactions and users is definitely
problematic for blockchain networks. If networks cannot expand in terms of
capacity for accommodating the new transactions and users, then they can risk
a lot in terms of possibilities for widespread adoption. So, the search for
blockchain scalability solutions has been increasing profoundly in recent times.
Scalability Aspects Blockchain
Consensus Protocol: Possibilities
• Proof-of-Work-based permissionless blockchain networks are
capable of offering a transaction throughput of almost 10
transactions every second. Furthermore, some technical
modifications could help in improving the transaction
throughput to almost 100 transactions every second. Most
importantly, the technical modifications would not affect the
security aspects of the open and decentralized blockchain
networks.
• Permissioned blockchain networks could also serve as promising
answers for the blockchain scalability problem. The
consensus mechanisms in the permissioned blockchain networks
could offer improved speed. At the same time, permissioned
blockchain networks do not offer any clarity regarding
decentralization with predetermined validators effectively
Scalability Aspects Blockchain
Consensus Protocol: Trilemma
• The scaling trilemma is a loose concept which implies that blockchain networks
could have only two out of the three crucial traits of decentralization, security,
and scalability. Let us understand the connection between the three distinct
components in this trilemma to find better solutions for the blockchain scalability
challenge.
• The blockchain network must reach an agreement regarding the validity of the
transaction for its settlement. In the case of a system with a large number of
participants, the network may require more time for reaching an agreement.
Therefore, it is clearly evident that scalability reduces with the rise in
decentralization. Think of two different Proof-of-Work-based blockchain
networks with similar levels of decentralization and assume security as the hash
rate in the blockchain. In event of a higher hash rate, you will have a lower
confirmation time alongside prominent growth in scalability in with security..
Scalability Aspects Blockchain
Consensus Protocol: Trilemma
• So, with decentralization being constant, you can have a directly proportional
relation between security and scalability. Therefore, the blockchain scalability
trilemma basically implies that a blockchain network could not optimize
decentralization, scalability, and security simultaneously. As a result, you can
look at the need for making trade-offs.
Scalability Aspects Blockchain
Consensus Protocol: Solutions
• Better Consensus Mechanisms: One of the most commonly recommended
solutions for the blockchain scalability challenge refers to improving
consensus protocols. Renowned blockchain networks such as Bitcoin presently
use the Proof of Work consensus protocol. Even if the Proof of Work consensus
mechanism offers reliable security, it is considerably slow. Therefore, many
blockchain networks are looking towards the Proof-of-Stake consensus
mechanism as a promising solution for blockchain scalability issues. The PoS
consensus mechanism does not require miners to solve cryptographic algorithms
by using massive computational power. On the contrary, it ensures consensus
through the selection of validators according to stakes in the network. The
adoption of PoS consensus could substantially boost the capacity of Ethereum
networks alongside improving security and decentralization.
•.
Scalability Aspects Blockchain
Consensus Protocol: Solutions
• Sharding: Sharding is one of the conventional choices for addressing
the blockchain scalability problem as an on-chain scaling solution. Based on
distributed databases, sharding is presently one of the notable layer-1 scaling
solutions for blockchain networks. Sharding involves breaking down transactions
into smaller data sets which are referred to as ‘shards’. The network then
processes the shards simultaneously in parallel, thereby enabling sequential
work on multiple transactions. With the help of sharding, the information could
be divided among different nodes while ensuring consistency of information.
Shards serve as proof for the mainchain while ensuring interaction with each
other for sharing addresses, general state, and balances by leveraging cross-shard
communication protocols.
Scalability Aspects Blockchain
Consensus Protocol: Solutions
• Nested Blockchain
• Another promising answer for resolving scalability challenges in blockchain would refer to the
nested blockchain. It is basically a decentralized network infrastructure leveraging the main
blockchain for establishing parameters for the larger blockchain network. In addition, it also
ensures the execution of transactions over an interconnected network of secondary chains.
Nested blockchain is one of the promising entries among layer-2 solutions aimed at resolving
the blockchain scalability problem.
• While it is good to hear about promising solutions for blockchain scalability, the solutions are
still in the experimental stages. It is quite clear that scalability is a profound limitation for
blockchain networks. Developers are trying to resolve the problem of scalability through
different perspectives. For example, increasing block size could increase scalability. However,
such principles have not found mainstream popularity. At the same time, the addition of
another layer over the existing blockchain network with layer 2 solutions is also a promising
solution for scalability. On the other hand, it is too soon to round up conclusions regarding
the most feasible solutions for scalability.
Scalability Aspects Blockchain
Consensus Protocol: Solutions
• Bottom Line: The future of blockchain seems to be quite bright with the
feasibility of its applications in diverse sectors. However, the increasing number
of users would obviously imply the need for larger blockchain networks. An in-
depth understanding of the blockchain scalability challenge shows how scalability
is represented in cost & capacity, networking, and throughput.
Distributed Consensus
• A distributed consensus ensures a consensus of data among nodes in a distributed system
or reaches an agreement on a proposal.
• In public blockchains in open networks and private blockchains in permissioned networks,
this consensus problem has once again received much attention and needs to be
considered from a new perspective.
• Nodes in distributed systems are trying to achieve some common goal (maybe processing
a large computation). Then they need some kind of coordination among them. They need
to know the effect of their doings to the whole system. That’s where distributed systems
need a consensus protocol. In any distributed consensus protocol a node can say “I
SUGGEST value v. Do you all agree?” Only after all of the other nodes AGREED. on v, each
node (including suggesting node) can carry on their work keeping “v is decided” in their
mind. Another node can also say “I prefer w.” and SUGGEST another value(w) before the
system decides v. Then the distributed system should choose either v or w. In such a case,
achieving consensus is a bit complicated process.
Distributed Consensus
• Common use cases of distributed consensus are,
1.Electing a leader among nodes
• Processes elect a single process (i.e., a leader) to make decisions.
• The leader proposes the next valid output value.
2. Taking a commit decision
3. Replicating data into nodes
Distributed Consensus: Types of
Failures
1.Crash failures: Crash failure is a situation where a node abruptly crashes and
stops responding to other nodes. This is a common issue in any distributed
system.
2.Byzantine failures: Byzantine failure is a situation where a node is malfunctioning
such that data sent by the node is contradictory or completely meaningless. In
other words, a Byzantine faulty node is a lying node. For example, a hacked node
may act as a Byzantine faulty node. The name Byzantine comes from the
Byzantine General’s Problem.
It is clear that having Byzantine nodes in the distributed system is the worst
possible case of the consensus problem. So, if a consensus algorithm can tolerate
Byzantine failures it can tolerate every possible error that can occur in a
distributed system.
3. Network Partitioned Faults: A network fault occurs (say the link failure) and the
network gets partitioned.
Distributed Consensus: Properties
• To achieve consensus in a distributed system every node should follow the same
protocol when communicating with each other. There are three conditions that
should be satisfied by a consensus algorithm to achieve distributed consensus.
1.Agreement: the agreement condition means all the non-faulty nodes should AGREE
on the same value.
2.Validity: Validity says that the value a node agrees on should be a value SUGGESTED
by one of the nodes in the distributed system. This means if every non-faulty node
is suggesting v as the value, any non-faulty node should decide v.
3.Termination: According to the termination condition, every non-faulty node will
eventually decide some value. In other words, it says that if a single node is not
agreeing, the consensus in a distributed system cannot be achieved.
4.Integrity: Every correct individual must agree on same value.
Correctness of a Distributed
Consensus Algorithms
• These two properties can characterize the correctness of a distributed consensus algorithms:
• Safety: Correct individuals must not agree on an incorrect value. It means nothing bad will
happen in the system. This property ensures that the system will never convert to an incorrect
value or the correct individuals in the network will never convert to an incorrect value.
• Liveliness: Every correct value must be accepted eventually. It means something good eventually
happens. If someone is proposing some good values, that good value will be committed
eventually. Although, there can be some time lag or delay in reaching the consensus. But after the
consensus protocol terminates, expected to have a correct consensus value.
• These two correctness properties for a distributed consensus algorithm need to ensure whenever
we design a distributed consensus algorithms.
Distributed Consensus: Message
Passing System
• Synchronous Message Passing System:
• In a synchronous system, it is assumed that messages will be delivered within some
fixed, known amount of time.
• Synchronous message passing is conceptually less complex because users have a
guarantee: when they send a message, the receiving component will get it within a
certain time frame. This allows users to model their protocol with a fixed upper
bound of how long the message will take to reach its destination.
• However, this type of environment is not very practical in a real-world distributed
system where computers can crash or go offline and messages can be dropped,
duplicated, delayed, or received out of order.
• Asynchronous Message Passing System:
• In an asynchronous message-passing system, it is assumed that a network may delay
messages infinitely, duplicate them, or deliver them out of order. In other words,
there is no fixed upper bound on how long a message will take to be received.
Distributed Consensus: FLP
Impossibility
• In their 1985 paper “
Impossibility of Distributed Consensus with One Faulty P
rocess
,” researchers Fischer, Lynch, and Paterson (aka FLP)
show how even a single faulty process makes it
impossible to reach consensus among deterministic
asynchronous processes. Basically, because processes
can fail at unpredictable times, it’s also possible for
them to fail at the exact opportune time that prevents
consensus from occurring.
Distributed Consensus: Solutions to
Achieve in Synchronous
Environment
• Paxos
• Introduced in the 1990s, Paxos was the first real-world,
practical, fault-tolerant consensus algorithm. It’s one of
the first widely adopted consensus algorithms to be
proven correct by Leslie Lamport and has been used by
global internet companies like Google and Amazon to
build distributed services.
• Paxos works like this:
• Phase 1: Prepare request
• Phase 2: Accept request
• Phase 3: Learning phase
• There are three types of nodes, the proposer,
acceptor, and learner. However, everyone is a
learner in the network who learns what the
majority decision is.
• Proposer: The proposer proposes values, and
the consensus algorithm should choose that
proposed values.
• Acceptor: They form the consensus and accept
the values. Whenever they hear a certain
proposal from the proposer, the acceptors
either accept or reject the proposal.
• Learner: This learner will determine which value
has been chosen by each acceptor and
collectively accept that particular value.
Making a Proposal: Proposer Process

• The proposer initially prepares a

proposal number so that this number
needs to be good enough for the
proposal to be accepted by the
acceptors. The proposal number forms
a timeline, and the biggest number
considered up to date.
• For example, there are two proposers
P1 and P2, and P1 and P2 proposed
values are 100 and 101. The acceptor
always accepts a bigger proposal
number, so in this case, it is P2 rather
than P1.
Making a Proposal: Acceptor’s
Decision Making
• If the received proposal number is less or
equal to the already seen or received
proposal number, then it rejects else it
accepts. It means the acceptor compares
the recently received proposal number with
the currently known values for all
proposer’s received messages. If it gets the
higher number, then it accepts; otherwise,
it rejects.
Making a Proposal: Acceptor’s
Message
• Acceptor prepares the response, including
accept or decline status, biggest proposal
number, and accepted values.
• The acceptor can either accept or reject a
message based on the proposed algorithm.
• The acceptor includes the biggest number
that the acceptor has seen in the response
message.
• It also includes the values that the acceptor
has accepted to inform the proposer.
Accepting a Value: Proposer’s
Decision Making
• The proposer looks for the response’s status,
whether the majority of the acceptors
reject/accept the proposal. If they have
rejected the proposal, then the proposer
updates with the latest proposal number.
However, if most acceptors have accepted
values, then the proposer cannot be chosen
this value. In other cases, like the majority of
acceptors accepted the proposal and this value
was not chosen, then the proposer sends
accept messages to others.
• The basic idea is that whenever the majority of
the acceptors send to accept the response. It
means the value that the proposer has shared
that is coming to be a consensus.
Accepting a Value: Accept Message
• The final stage is accepted message, the
proposer sends the accept message to all
the acceptors and in the accept message,
the proposer includes the proposal
number.
• A similar to the prepare phase, the
proposal knows that his proposal has been
accepted, and the value is the proposal’s
single value.
Accepting a Value: Notifying Learner
• Whenever the acceptor accepts a
value from the proposer, it informs
the learner about this is the majority
voted value.
• So everyone learns that what is the
majority voting in the environment.
Handling Failure: Acceptor Failure
• Whenever a certain acceptor fails during the
prepare phase, the system does not have any
issue as the other acceptors can listen and vote
either for or against the proposal.
• If the acceptor fails during the accept stage, the
system does not have any issue because other
acceptors are there who have already voted for
the proposal.
• The only thing to ensure that not more than N/2
number of acceptors fails simultaneously in the
system. If that happens, then that violates the
majority voting principle, and the system cannot
come to a consensus.
Handling Failure: Proposer Failure
• If the proposer fails during the prepare phase, it is
just like no one is proposing for any value, so the
acceptor will keep on waiting for the state, and if
they are not getting any value, others will become a
proposer. It means, the acceptor waits for a certain
duration, and if they do not receive any proposal,
one of the acceptor becomes the proposal and
propose a new value.
• Suppose the proposal fails during the accept phase,
the acceptors who have already agreed upon
whether to choose or not choose the proposal value
based on the majority vote. As they have already
shared the majority vote among themselves, and
from there, they can find out that whether the
proposal has been accepted or not by the proposer.
Handling Failure: Dueling Proposers

• Proposer received confirmations to

her prepare message from majority
• Yet to send accept messages
• Another proposer send prepare
message with higher proposal
number
• Block the first proposer’s proposal
from being accepted

• For this used certain ordering

mechanisms for this deadlock i.e.,
Leader Selection Algorithm
Distributed Consensus: Solutions to
Achieve in Synchronous
Environment
• Raft
• In 2013, Ongaro and Ousterhout published a new consensus algorithm for a replicated state
machine called Raft, where the core goal was understandability (unlike Paxos).
• One important new thing we learned from Raft is the concept of using a shared timeout to
deal with termination. In Raft, if you crash and restart, you wait at least one timeout period
before trying to get yourself declared a leader, and you are guaranteed to make progress.]
• The Raft algorithm is a leader-based asymmetric model. A node in a system can only be in
one of the three states at any point in time: leader, follower, and candidate. In the initial
stage, all the nodes are followers. To become the leader, a node (follower) must become a
candidate and launch a round of electoral votes. If the node does not receive enough votes,
the node becomes a follower again. However, if it receives a majority of the votes, the node
becomes the leader. If the leader encounters failures and finds that a new leader is elected
after it recovers from failures, the original leader automatically goes back to the follower
state.
• The leader is responsible for state transition log replication across the followers
Raft Continued..
• The system starts up and has a set of follower
nodes.
• The follower nodes look for a leader. If a
timeout happens, there is no leader, and there
is a need to elect a leader in the system.
• A few candidates stand for a leader in the
election process, and the remaining nodes vote
for the candidate.
• The candidates who receive the majority votes
become the leader.
• The leader proposes a proposal, and the
followers can either vote for or against that
proposal.
Raft- Electing the Leader: Voting
Request Continued..
• The first part of the Raft is to elect a leader, and for
that, there should be some leader candidates.
• The nodes sense the network, and if there is no leader
candidate, then one of the nodes will announce that I
want to be a leader. The leader candidate requests
the votes. This voting request contains 2 parameters:
• Term: last calculated # known to candidate + 1
• Index: committed transaction available to the
candidate
• These algorithms work in multiple rounds, and the
term indicates a new voting round. If the last voting
finishes, then the next term will be old term number +
1; The index indicates committed transactions
available to the candidate. It is just like an increasing
number to distinguish between already committed
and new transactions.
Raft- Electing the Leader: Follower
Node Decision Making Continued..
• Once the nodes receive a voting request, their task is
to vote pro or against the candidate. So, this is the
mechanism to elect a leader in the Raft consensus
algorithm. Each node compares the received term
and index with the corresponding current known
values.
• The node(i) receives the voting request. It compares
the already seen term with the newly received term.
If a newly received term is less than the already seen
term, then it discards because the node considers
this request as an old request.
• The newly received term is greater than the already
seen term. It checks for the newly received index
number with the already seen index number. If the
newly received index number is greater than already
seen, it votes for the candidate; else, it declines.
Raft- Electing the Leader: Majority
Voting Continued..
• Every node sends their vote and candidates who
get majority vote becomes a leader, and commit
the corresponding log entry. in other words, If a
certain leader candidate, receives majority of
the vote from the nodes, then that particular
candidate becomes a leader and other becomes
the follower of that node.
• Use of Majority Voting
• Leader Selection
• Commit the log entry
Raft- Example: Multiple Leader
Candidate: Current Leader Failure
Continued.. • There is a leader, and three followers and the
current team is 10, and the commit index value
is 100.
• Suppose the leader node has failed or followers didn’t
receive a heartbeat message within the heartbeat
timeout period.
• After the timeout, one of the nodes will become a
leader candidate, initiates a leader election, and
becomes a new leader with team 11 and commit index
value 100. The new leader periodically sends the
heartbeat message to everyone to indicate his
presence.
• In the meantime, the old leader gets recovered, and he
also receives a heartbeat message from the new
leader.
• The old leader understands that a new term has
started.
• Then the old leader will change his status from leader
to follower.
• So this is the one way to handling a new leader by
utilizing the team parameter.
Raft- Example: Multiple Leader
Candidate: Simultaneous request
vote Continued.. • Let us understand a scenario where there is a leader,
and three followers and the current team is 20, and
the commit index value is 200.
• Suppose the leader node has failed or followers didn’t
receive a heartbeat message within the heartbeat
timeout period.
• It may be possible that multiple followers sense the
timeout period simultaneously and become a leader
candidate, and initiates the leader election procedure
independently.
• Two nodes send the request messages with team 21 at
the same time in the network.
Raft- Example: Multiple Leader
Candidate: Simultaneous request
vote Continued.. • There are two leader candidates, and both are sending
voting request messages, at the same time, for round
(term) 21. Then, they look for the majority voting.
• In this example, the first candidate receives two votes,
and the second candidate receives one vote, so based
on the majority voting, the first candidate is a winner.
• The node which gets the majority votes send a
heartbeat message to everyone. Another leader
candidate also received the heartbeat message from
the winner, and this leader candidate falls back to a
follower from the leader candidate
 Raft- Example: Committing Entry Log

• Let us consider that the current term value is 10, and

the index value is 100, which means most of the nodes
have seen and committed transaction index value
number 100.
• The leader proposes a new transaction, adds an entry
log with term 10 and the new transaction index value as
101. Further, the leader sends a message called append
entries to all the followers, and they collectively vote
either for or against this transaction.
Raft- Example: Committing Entry
Log Continued..
• The leader receives the vote for this transaction index
value 101.
• The followers’ node votes for or against this
transaction. If the majority says that they are fine with
committing this particular log. Then, the leader
considers that the transaction log is approved by the
followers.
• After successful acceptance of the entry log, the leader
sends an accept message based on the majority voting
to all the individual followers to update the committed
index to 101.
Raft- Example: Handling Failures
Continued..
• Multiple kinds of failures exist in the environment.
However, Paxos and Raft consensus algorithms only
support Crash or Network fault.
• The followers may have crashed, but the system can
tolerate up to N/2 -1, where N is the total number of
nodes in the environment, as it does not affect the
system due to the majority voting.
• This indicates that the majority of the followers are
non-faulty, and they can send a vote. The leader can
take the majority decision whether to accept or reject a
particular transaction.
Distributed Consensus: Solutions to Achieve in
Asynchronous Environment: Practical Byzantine
Fault Tolerance (PBFT)
• All the nodes in a PBFT system are ordered sequentially with one node being the leader node
and others considered as backup nodes. All the nodes in a system communicate with each
other and reach consensus based on the majority principle. Each PBFT consensus round is called
a view. The leading node is changed during every view and can be replaced with a protocol
called a view change if a certain amount of time has passed without the leading node
broadcasting the request. This replica timeout mechanism ensures that the crashed or malicious
leader can be detected and that a new view starts by re-electing a new leader.
• There are five phases experienced by the client launching requests to receiving responses. The
consensus process adopts the three-phase protocol. The following content briefly describes the
five phases:
Distributed Consensus: Solutions to Achieve in
Asynchronous Environment: Practical Byzantine
Fault Tolerance (PBFT)
1. Launch: The client (client c) initiates the service request m to the cluster.
2. Pre-prepare: The leader node (replica 0) verifies the validity of the request message m, assigns
the sequence number n to the request m in the view and broadcasts the assigned pre-prepare
message to all the backup nodes (replica 1-3).
3. Prepare: The backup nodes verify the validity of the request message m and accept the sequence
number n. If a backup node accepts the assignment scheme, it broadcasts the corresponding
prepare message to the other nodes. In this phase, all the replicas are required to reach a globally
consistent order.
4. Commit: Once the assignment agreement message is received from the cluster, all the nodes
(primary and secondary nodes) broadcast the commit message to all the other nodes. In this
phase, all the replicas have agreed on the order and confirmed the received request.
5. Execute and reply: After receiving the commit message from the cluster, the nodes execute the
request m and send replies to the client. The client awaits the same reply from f+1 different
nodes and considers that the request has been executed successfully. f represents the maximum
number of potential faulty nodes in the clusters. That all the nodes directly return messages to
the client is also to prevent the primary node from having problems during the request.
Distributed Consensus: Solutions to Achieve in Asynchronous
Environment: Practical Byzantine Fault Tolerance (PBFT)
Three Byzantine Generals Problem: Lieutenant Faulty
• This is the case when one of the Lieutenant is
faulty: The Commander sends a retreat message
to both the Lieutenants(1,2), and the Lieutenant
(2), who is faulty, sends an attack message rather
than an actual retreat message to Lieutenant (1).
But, in general, by integrity condition of the Army,
the Lieutenant (1) is bound to obey the
Commander message. Although Lieutenant (2) is
faulty, and the Commander is correct. Thus, the
entire system still works correctly.
Distributed Consensus: Solutions to Achieve in Asynchronous
Environment: Practical Byzantine Fault Tolerance (PBFT)
Three Byzantine Generals Problem: Commander Faulty
• This is the case when the Commander is faulty:
The Commander sends different messages to
different Lieutenants. He sends a retreat message
to Lieutenants(1) and an attack message to
Lieutenant (2). When Lieutenants exchange the
messages, then both may feel that the other one
is faulty. Then, they follow the integrity condition
of the Army, and both obey the Commander’s
message. Thus, this contradicts the agreement
condition and no solution for three generals,
including one faulty commander. Even the
majority principle wouldn’t work here because
both the Lieutenants had received two messages
{attack,retret} which may confuse both the
Lieutenants.
Distributed Consensus: Solutions to Achieve in Asynchronous
Environment: Practical Byzantine Fault Tolerance (PBFT)
Four Byzantine Generals Problem: Lieutenant Faulty
• In this case, there are four Byzantine Generals, and
one of the Lieutenant is faulty. They communicate
with each other using the message passing
technique.
• The Commander sends a message to all the
Lieutenant, and later the Lieutenants share the
received message. However, in this case,
Lieutenant(2) is faulty, so he/she may send the
incorrect message to others, whereas the remaining
Lieutenants exchange the correct message with each
other.
• If they go for the majority voting principle, they can
analyze and decide to retreat. This is illustrated as
follows:
Distributed Consensus: Solutions to Achieve in Asynchronous
Environment: Practical Byzantine Fault Tolerance (PBFT)
Four Byzantine Generals Problem: Lieutenant Faulty
• Lieutenant (1) = {Retreat, Attack, Retreat) = Retreat
• Lieutenant (3) = {Retreat, Attack, Retreat) = Retreat
• Lieutenant (1) receives two retreat messages from
Lieutenant (3) and the Commander but an attack
message from Lieutenant (2). Whereas Lieutenant (3)
also receives two retreat messages from Lieutenant
(2) and the Commander but an attack message from
Lieutenant (2).
• We observe that when all the correct Lieutenants
follow the majority voting principle, although
Lieutenant (2) is a Byzantine node, Lieutenant (1) &
Lieutenant (3) can correctly decode the message.
However, the same concept is not valid if two
Lieutenants become faulty.
Distributed Consensus: Solutions to Achieve in Asynchronous
Environment: Practical Byzantine Fault Tolerance (PBFT)
Four Byzantine Generals Problem: Commander Faulty
• In this case, there are four Byzantine Generals, out
of which three are non-faulty Lieutenants and a
faulty Commander. They communicate with each
other using the message passing technique. The
Commander sends the differing messages to
Lieutenants, and the Lieutenants exchange the
received message.
• The Commander sends the retreat message to two
Lieutenants (1,3) and an attack message to
Lieutenant (2). However, the Lieutenants exchange
messages correctly. If they go for the majority
voting principle, they can analyze and decide to
Retreat. This is illustrated as follows:
 Distributed Consensus: Solutions to Achieve in Asynchronous
Environment: Practical Byzantine Fault Tolerance (PBFT)
Four Byzantine Generals Problem: Commander Faulty
• Lieutenant (1) = {Retreat, Attack, Retreat) = Retreat
• Lieutenant (2) = {Retreat, Attack, Retreat} = Retreat
• Lieutenant (3) = {Attack, Retreat, Retreat) = Retreat
• We observe that when all the correct Lieutenants follow the majority voting principle, although
Commander is a Byzantine node, Lieutenant (1), Lieutenant (2) & Lieutenant (3) can correctly decode
the message. However, if the Commander sends an attack message to more than one Lieutenant and
then using the majority voting principle, they can analyze and decide to Attack. When the Commander
is faulty, the system will reach a consensus with the value that the Commander has proposed to the
majority of the Lieutenants.
• In general, to ensure the correct consensus in the system, and when there is a maximum of F numbers
of faulty Lieutenants, there should be 2*F + 1 number of Lieutenants, plus a Commander in the
system.
 Distributed Consensus: Solutions to Achieve in
Asynchronous Environment: Byzantine Generals
Model
• In the Byzantine Generals Model, we assume an N number of processes out of which at most F
number of the processes can be faulty while ensuring that the system has a total of 2*F + 1 number of
processes.
• The system should be fully connected, and receivers always know the identity of the senders.
• The other requirements are that the system should synchronous and having a reliable communication
medium.
• The synchronous system means that every process should receive all the messages within some
predefined timeout duration.
Consensus in Bitcoin
• Bitcoin has no central authority, yet somehow every full node has a complete copy of a
public ledger that it can trust as the authoritative record. The blockchain is not created by
a central authority, but is assembled independently by every node in the network.
Somehow, every node in the network, acting on information transmitted across insecure
network connections, can arrive at the same conclusion and assemble a copy of the same
public ledger as everyone else.
• Satoshi Nakamoto’s main invention is the decentralized mechanism for emergent
consensus. Emergent, because consensus is not achieved explicitly—there is no election
or fixed moment when consensus occurs. Instead, consensus is an emergent artifact of
the asynchronous interaction of thousands of independent nodes, all following simple
rules. All the properties of bitcoin, including currency, transactions, payments, and the
security model that does not depend on central authority or trust, derive from this
invention.
Consensus in Bitcoin
• Bitcoin’s decentralized consensus emerges from the interplay of four processes
that occur independently on nodes across the network:
• Independent verification of each transaction, by every full node, based on a
comprehensive list of criteria
• Independent aggregation of those transactions into new blocks by mining
nodes, coupled with demonstrated computation through a Proof-of-Work
algorithm
• Independent verification of the new blocks by every node and assembly into a
chain
• Independent selection, by every node, of the chain with the most cumulative
computation demonstrated through Proof-of-Work
Consensus in Bitcoin: Independent verification of
transactions
• Before forwarding transactions to its neighbors, every bitcoin node that receives a
transaction will first verify the transaction. This ensures that only valid transactions are
propagated across the network, while invalid transactions are discarded at the first node
that encounters them.

• Each node verifies every transaction against a long checklist of criteria:

• The transaction’s syntax and data structure must be correct.
• The transaction size in bytes is less than MAX_BLOCK_SIZE.
• Each output value, as well as the total, must be within the allowed range of values
(less than 21m coins, more than the dust threshold).
• None of the inputs have hash=0, N=–1.
Consensus in Bitcoin: Independent verification of
transactions
• A matching transaction in the pool, or in a block in the main branch, must exist.
• For each input, if the referenced output exists in any other transaction in the
pool, the transaction must be rejected.
• For each input, look in the main branch and the transaction pool to find the
referenced output transaction. If the output transaction is missing for any input,
this will be an orphan transaction. Add to the orphan transactions pool, if a
matching transaction is not already in the pool.
• For each input, the referenced output must exist and cannot already be spent.
• By independently verifying each transaction as it is received and before
propagating it, every node builds a pool of valid (but unconfirmed) transactions
known as the transaction pool, memory pool, or mempool.
Consensus in Bitcoin: Aggregating Transactions
into Blocks
• After validating transactions, a bitcoin node will add them to the memory pool, or
transaction pool, where transactions await until they can be included (mined)
into a block.
• These transactions will be aggregated into a candidate block by the Miner.
• The block becomes valid only if the miner succeeds in finding a solution to the
Proof-of-Work algorithm.
• The miner will get reward and transaction fee.
Consensus in Bitcoin: Verification of Block
• As the newly solved block moves across the network, each node performs a
series of tests to validate it before propagating it to its peers.
• This ensures that only valid blocks are propagated on the network. The
independent validation also ensures that miners who act honestly get their blocks
incorporated in the blockchain, thus earning the reward.
• Those miners who act dishonestly have their blocks rejected and not only lose
the reward, but also waste the effort expended to find a Proof-of-Work solution,
thus incurring the cost of electricity without compensation.
• When a node receives a new block, it will validate the block by checking it against
a long list of criteria that must all be met; otherwise, the block is rejected.
Consensus in Bitcoin: Verification of Block
• The Criteria for checking block is:
• The block data structure is syntactically valid
• The block header hash is less than the target (enforces the Proof-of-Work)
• The block timestamp is less than two hours in the future (allowing for time
errors)
• The block size is within acceptable limits
• All transactions within the block are valid
Consensus in Bitcoin: Selecting chains of blocks

• Once a node has validated a new block, it will then attempt to assemble a chain
by connecting the block to the existing blockchain.
• Nodes maintain three sets of blocks: those connected to the main blockchain,
those that form branches off the main blockchain (secondary chains), and finally,
blocks that do not have a known parent in the known chains (orphans).
• Invalid blocks are rejected as soon as any one of the validation criteria fails and
are therefore not included in any chain.
• The “main chain” at any time is whichever valid chain of blocks has the most
cumulative Proof-of-Work associated with it.
• The main chain will also have branches with blocks that are “siblings” to the
blocks on the main chain. These blocks are valid but not part of the main chain.
They are kept for future reference, in case one of those chains is extended to
exceed the main chain in work (Forks).
Consensus in Bitcoin: Selecting chains of blocks

• When a new block is received, a node will try to slot it into the existing
blockchain. The node will look at the block’s “previous block hash” field, which is
the reference to the block’s parent.
• In that case, the node will attach the new block to the secondary chain it extends
and then compare the work of the secondary chain to the main chain. If the
secondary chain has more cumulative work than the main chain, the node will
reconverge on the secondary chain, meaning it will select the secondary chain as
its new main chain, making the old main chain a secondary chain. If the node is a
miner, it will now construct a block extending this new, longer, chain.
Permissioned Blockchain
• Permissioned blockchains are blockchain networks that require access to be part of.
• In these blockchain types, a control layer runs on top of the blockchain that governs the actions
performed by the allowed participants.
• Permissioned blockchains work entirely different than that of private and public blockchains.
• They are crafted to take advantage of blockchains without sacrificing the authority aspect of a
centralized system.
• So, basically, there is one big difference between a permissioned and a permissionless one, i.e.,
the way the participants are going to interact with the network.
• A permissioned system is also known to have a restriction on the consensus participants, making
permissioned networks highly configured and controlled by the owners. However, it is not a bad
thing, but it is all about building a suitable blockchain network.
• There are many popular permissioned blockchain frameworks out there. It includes Hyperledger,
Quorum, Corda
Permissioned Blockchain:
Advantages
• Efficient performance: When we compared permissioned blockchains to permissionless blockchains, they
offer better performance. The core reason behind this is the limited number of nodes on the platform.
This removes the unnecessary computations required to reach consensus on the network, improving the
overall performance. On top of that, permissioned networks have their own pre-determined nodes for
validating a transaction.
• Proper governance structure: Permissioned networks do come with an appropriate structure of
governance. This means that they are organized. Administrators also require less time to update the rules
over the network, which is considerably faster when compared to public blockchains. The public
blockchain network suffers from the consensus problem as not all nodes work together to get the new
update implemented. These nodes might place their self-interest above the needs of the blockchain,
which, in return, means slower updates to the whole network. In comparison, permissioned blockchain
doesn’t have the problem, as the nodes work together to move the updates faster.
• Decentralized storage: Permissioned networks also make proper use of blockchain, including utilizing its
decentralized nature for data storage.
• Cost-Effective: There is no doubt that permissioned blockchains are more cost-effective when compared
with the permissionless blockchains.
Permissioned Blockchain:
Disadvantage
• Compromised security – A public or private blockchain has better security as the nodes
participate in a consensus method properly. But, in the case of permissioned blockchains, this
might not hold true. The security of a permissioned network is as good as the member’s integrity.
This means that a small section of a permissioned system can work together to modify the data
stored within the network. In this way, the integrity of the network can be compromised. To
resolve it, the system should have proper permissions set so those bad actors cannot merge to
cause the desired effect.
• Control, Censorship, and Regulation – In an ideal world, these permissioned blockchains should
work as that of a public blockchain, but with regulations. However, the regulations bring
censorship to the network, where the authority can restrict a transaction or control it from
happening. These are a threat to any business or organization that is using the permissioned
network. This approach also stops the permissioned network from making the most out of the
whole blockchain ecosystem.
Permissioned Blockchain: Design
Goals
• Decentralization: The degree of decentralization for permissioned blockchains is based
on how the members of the consortium choose to structure their business relationships.
The concept of ‘no central control’ is not relevant here since the consortiums are
managed entities. The extent and quality of decentralization depends upon the number
of peers, the expected number of bad nodes in the network, and the type of consensus
mechanism the members agree to. Permissioned blockchains usually employ an
algorithm such as Byzantine Fault Tolerance, which differs from the popular proof-of-
work algorithm used in the permissionless world. Hyperledger Fabric supports nearly a
dozen consensus algorithms through its plug-in architecture. While decentralization is an
aspect of blockchain design, having the right governance model is even more important,
since power and control structures may not be evenly distributed.
Permissioned Blockchain: Design
Goals
• Transparency: In permissioned blockchains, having transparency into the work performed by
each node may not be as important to network members as it is in the permissionless
blockchains. It all depends upon how the business relationships are set up and how the
blockchain is configured. Most permissioned blockchains do not have crypto economic incentives
built into them. The primary incentive of permissioned blockchain participants is to minimize the
cost, time, and ease of sharing information.
• Privacy: Permissioned blockchains, such as Hyperledger Fabric, offer fine-grained visibility into
transaction details, along with metadata about those transactions. Why is this important?
Imagine two suppliers, S1 and S2, doing business with a manufacturer, M. S1 might not want S2
to know the nature and volume of its business with M — even though they are both members of
the same blockchain network. Another design pattern is that S2 and M may choose to use a side-
channel to negotiate pricing and business terms. Once they strike a deal, the transaction is put on
the main channel, where all other participants can see that S2 and M have exchanged an asset.
Permissioned Blockchain: Design
Goals
• Governance: Governance has very different semantics between permissionless and permissioned
blockchains. In the permissioned world, governance is largely decided and agreed upon by the
members of the blockchain business network. Economic incentives, code quality, code changes, and
power allocation among peers are based on the business dynamics and the common purpose for
which the network has been designed and built. This allows companies to move quickly and in ways
that best fit their business needs.
• Tokens: Permissioned blockchains, especially the ones based on Hyperledger Fabric, generally don’t
employ a crypto economic model or monetary tokens due to the nature of these business networks.
However, a few companies are experimenting with utility tokens for exchanging intrinsic value in
this type of ecosystem.
• Scalability and Performance: Permissioned blockchains use consensus mechanisms that are
computationally inexpensive (when compared to proof-of-work). Therefore, they enjoy substantially
better scalability and performance than their permissionless cousins. Blockchains like Hyperledger
Fabric offer additional innovations with respect to the roles of the nodes, including peers (that
maintain state/ledger) and orderers (that consent on the order of transactions included in the ledger).
Permissioned Blockchain: State
Machine Replication
• The state machine replication helps us to achieve a consensus in a permission model.
• We do not need to execute a smart contract to all the nodes. Rather, the selected subset of
contract executor executes it and propagates it with other nodes to ensure the contract’s status is
propagated to all the nodes uniformly in the network, and they are on the same page.
• The distributed state machine replication technology ensures consensus in a permission
blockchain environment.
Permissioned Blockchain: State
Machine Concept
• State Machine is characterized by a set of parameters such as set
of Inputs, set of Outputs, and the Transition States.
• A set of state (S) based on the system design
• A set of inputs (I)
• A set of outputs (O)
• A transition function S x I –> S; takes the current state and
input value and produces a set as the output.
• A output function S x I –> O
• A start state
Permissioned Blockchain: Example
Smart Contract – Crowd Funding
• The smart contract state machine representation are as follows:
Permissioned Blockchain: Example
Smart Contract – Crowd Funding
• In the crowdfunding platform, there are mainly two parties which include the project proposes and
project funders.
• The project proposers propose the project to the funders, and if they are interested, they will invest
money in their project.
• The funders will release funds after the completion of a certain job. In the above diagram, Alice and
Bob are the two funders, and they are transferring money after completing the proposed jobs by the
proposers. Once the entire job is completed, money will be transferred to them.
Permissioned Blockchain: Distributed
State Machine Replication Mechanism
• In a typical distributed architecture, the distributed state machine replication mechanism work in the
following way.
• It has multiple distributed servers which work independently in a distributed fashion. Initially, copies
of the state machine are placed on each server that resides in the closed network, assume that each
server knows the information about other servers.
Permissioned Blockchain: Distributed
State Machine Replication Mechanism
• In the distributed setup, it may be possible that different users are communicating to different
servers.
• The servers get the client’s request independently.
• In our example, Alice and Bob are two clients who are transferred their share of money via the
distributed network. However, at this moment, this information is locally stored in the connected
servers. The end goal is to ensure that all three servers reach the same state after a certain time. i.e.,
Each server must have information about Alice and Bob have transferred their share of the money.
• To achieve this, the state machine replication mechanism works in this principle that, individually, all
the servers propagate their state to others. However, the problem is to understand ordering or
sequences in which requests came from the users.
• This can be achieved using the timestamp concept. So, whenever Alice and Bob are making the
transactions, the transactions are associated with the timestamp. This way, information will be
executed in each server in that particular ordering algorithm. Consequently, all will execute in the
same order in which it was support to be executed. This way, all servers are reaching the same state.
Permissioned Blockchain: Distributed
State Machine Replication Mechanism
• Once execution is finished, then the states should be propagated in the entire network. It might be
possible that one of the servers was offline due to some failure. This way, all the servers will have a
state copy. So that update is done through synchronization of the state machine.
• At the end, there will be certain outputs and those outputs will be updated to clients.
• In the entire procedure, there are two glitches. The first one is that we need to maintain ordering in
service, and the second is that in the presence of failure, the system needs to ensure that all the
individual servers are on the same page. From our example, in the end, all the three servers must
know that Alice and Bob had shared their money, and money has been transferred to the recipient.
• Reason to use State Machine
• The network is closed, the nodes know each other, so state replication is possible among the
known nodes.
• Avoid mining overhead, do not need to spend anything like power, time, bitcoin other than
message passing.
• However, the consensus is still required as machines can be faulty or behave maliciously.
Consensus protocols for Permissioned
Blockchains: PBFT Consensus
• 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 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.
Consensus protocols for Permissioned
Blockchains: 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.
Consensus protocols for Permissioned
Blockchains: 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 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