Module 04

Permissioned
Blockchain
• Smart Contracts in Blockchain
• A Smart Contract (or cryptocontract) is a computer program that directly and automatically controls
the transfer of digital assets between the parties under certain conditions.
• A smart contract works in the same way as a traditional contract while also automatically enforcing
the contract.
• Smart contracts are programs that execute exactly as they are set up(coded, programmed) by their
creators. Just like a traditional contract is enforceable by law, smart contracts are enforceable by
code.
• The bitcoin network was the first to use some sort of smart contract by using them to transfer value
from one person to another.
• The smart contract involved employs basic conditions like checking if the amount of value to transfer
is actually available in the sender account.
• Later, the Ethereum platform emerged which was considered more powerful, precisely because the
developers/programmers could make custom contracts in a Turing-complete language.
• It is to be noted that the contracts written in the case of the bitcoin network were written in a Turing-
incomplete language, restricting the potential of smart contracts implementation in the bitcoin
network.
• There are some common smart contract platforms like Ethereum, Solana, Polkadot, Hyperledger
fabric, etc.
• History:
• In 1994, Nick Szabo, a legal scholar, and a cryptographer
recognized the application of a decentralized ledger for
smart contracts.
• He theorized that these contracts could be written in code
which can be stored and replicated on the system and
supervised by the network of computers that constitute
the blockchain.
• These smart contracts could also help in transferring
digital assets between the parties under certain
conditions.
• Features of Smart Contracts
• Distributed:
• Everyone on the network is guaranteed to have a copy of all the conditions of the
smart contract and they cannot be changed by one of the parties. A smart contract
is replicated and distributed by all the nodes connected to the network.
• Deterministic:
• Smart contracts can only perform functions for which they are designed only
when the required conditions are met. The final outcome will not vary, no matter
who executes the smart contract.
• Immutable:
• Once deployed smart contract cannot be changed, it can only be removed as long
as the functionality is implemented previously.
• Autonomy:
• There is no third party involved. The contract is made by you and shared between
the parties. No intermediaries are involved which minimizes bullying and grants
full authority to the dealing parties. Also, the smart contract is maintained and
executed by all the nodes on the network, thus removing all the controlling power
from any one party’s hand.
• Customizable: Smart contracts have the ability for modification
or we can say customization before being launched to do what
the user wants it to do.
• Transparent: Smart contracts are always stored on a public
distributed ledger called blockchain due to which the code is
visible to everyone, whether or not they are participants in the
smart contract.
• Trustless: These are not required by third parties to verify the
integrity of the process or to check whether the required
conditions are met.
• Self-verifying: These are self-verifying due to automated
possibilities.
• Self-enforcing: These are self-enforcing when the conditions
and rules are met at all stages.
• Capabilities of Smart Contracts
• Accuracy: Smart contracts are accurate to the limit a programmer has accurately coded them
for execution.
• Automation: Smart contracts can automate the tasks/ processes that are done manually.
• Speed: Smart contracts use software code to automate tasks, thereby reducing the time it
takes to maneuver through all the human interaction-related processes. Because everything is
coded, the time taken to do all the work is the time taken for the code in the smart contract to
execute.
• Backup: Every node in the blockchain maintains the shared ledger, providing probably the
best backup facility.
• Security: Cryptography can make sure that the assets are safe and sound. Even if someone
breaks the encryption, the hacker will have to modify all the blocks that come after the block
which has been modified. Please note that this is a highly difficult and computation-intensive
task and is practically impossible for a small or medium-sized organization to do.
• Savings: Smart contracts save money as they eliminate the presence of intermediaries in the
process. Also, the money spent on the paperwork is minimal to zero.
• Manages information: Smart contract manages users’ agreement, and stores information
about an application like domain registration, membership records, etc.
• Multi-signature accounts: Smart contracts support multi-signature accounts to distribute
funds as soon as all the parties involved confirm the agreement.
• How Do Smart Contracts Work?
• A smart contract is just a digital contract with the security coding of the blockchain.
• It has details and permissions written in code that require an exact sequence of events to take
place to trigger the agreement of the terms mentioned in the smart contract.
• It can also include the time constraints that can introduce deadlines in the contract.
• Every smart contract has its address in the blockchain. The contract can be interacted with by
using its address presuming the contract has been broadcasted on the network.
• The idea behind smart contracts is pretty simple. They are executed on a basis of simple
logic, IF-THEN for example:
• IF you send object A, THEN the sum (of money, in cryptocurrency) will be transferred to
you.
• IF you transfer a certain amount of digital assets (cryptocurrency, for example, ether,
bitcoin), THEN the A object will be transferred to you.
• IF I finish the work, THEN the digital assets mentioned in the contract will be transferred to
me.
• Note: The WHEN constraint can be added to include the time factor in the smart contracts. It
can be seen that these smart contracts help set conditions that have to be fulfilled for the
terms of the contract agreement to be executed. There is no limit on how much IF or THEN
you can include in your intelligent contract.
• Identify Agreement: Multiple parties identify the cooperative opportunity and
desired outcomes and agreements could include business processes, asset swaps, etc.
• Set conditions: Smart contracts could be initiated by parties themselves or when
certain conditions are met like financial market indices, events like GPS locations,
etc.
• Code business logic: A computer program is written that will be executed
automatically when the conditional parameters are met.
• Encryption and blockchain technology: Encryption provides secure authentication
and transfer of messages between parties relating to smart contracts.
• Execution and processing: In blockchain iteration, whenever consensus is reached
between the parties regarding authentication and verification then the code is
executed and the outcomes are memorialized for compliance and verification.
• Network updates: After smart contracts are executed, all the nodes on the network
update their ledger to reflect the new state. Once the record is posted and verified on
the blockchain network, it cannot be modified, it is in append mode only.
• Applications of Smart Contracts
• Real Estate: Reduce money paid to the middleman and distribute between the parties actually
involved. For example, a smart contract to transfer ownership of an apartment once a certain amount
of resources have been transferred to the seller’s account(or wallet).
• Vehicle ownership: A smart contract can be deployed in a blockchain that keeps track of vehicle
maintenance and ownership. The smart contract can, for example, enforce vehicle maintenance
service every six months; failure of which will lead to suspension of driving license.
• Music Industry: The music industry could record the ownership of music in a blockchain. A smart
contract can be embedded in the blockchain and royalties can be credited to the owner’s account
when the song is used for commercial purposes. It can also work in resolving ownership disputes.
• Government elections: Once the votes are logged in the blockchain, it would be very hard to decrypt
the voter address and modify the vote leading to more confidence against the ill practices.
• Management: The blockchain application in management can streamline and automate many
decisions that are taken late or deferred. Every decision is transparent and available to any party who
has the authority(an application on the private blockchain). For example, a smart contract can be
deployed to trigger the supply of raw materials when 10 tonnes of plastic bags are produced.
• Healthcare: Automating healthcare payment processes using smart contracts can prevent fraud.
Every treatment is registered on the ledger and in the end, the smart contract can calculate the sum of
all the transactions. The patient can’t be discharged from the hospital until the bill has been paid and
can be coded in the smart contract.
• Advantages of Smart Contracts
• Recordkeeping: All contract transactions are stored in chronological order in the blockchain
and can be accessed along with the complete audit trail. However, the parties involved can be
secured cryptographically for full privacy.
• Autonomy: There are direct dealings between parties. Smart contracts remove the need for
intermediaries and allow for transparent, direct relationships with customers.
• Reduce fraud: Fraudulent activity detection and reduction. Smart contracts are stored in the
blockchain. Forcefully modifying the blockchain is very difficult as it’s computation-
intensive. Also, a violation of the smart contract can be detected by the nodes in the network
and such a violation attempt is marked invalid and not stored in the blockchain.
• Fault-tolerance: Since no single person or entity is in control of the digital assets, one-party
domination and situation of one part backing out do not happen as the platform is
decentralized and so even if one node detaches itself from the network, the contract remains
intact.
• Enhanced trust: Business agreements are automatically executed and enforced. Plus, these
agreements are immutable and therefore unbreakable and undeniable.
• Cost-efficiency: The application of smart contracts eliminates the need for
intermediaries(brokers, lawyers, notaries, witnesses, etc.) leading to reduced costs. Also
eliminates paperwork leading to paper saving and money-saving.
• Challenges of Smart Contracts
• No regulations: A lack of international regulations focusing on
blockchain technology(and related technology like smart contracts,
mining, and use cases like cryptocurrency) makes these technologies
difficult to oversee.
• Difficult to implement: Smart contracts are also complicated to
implement because it’s still a relatively new concept and research is still
going on to understand the smart contract and its implications fully.
• Immutable: They are practically immutable. Whenever there is a
change that has to be incorporated into the contract, a new contract has
to be made and implemented in the blockchain.
• Alignment: Smart contracts can speed the execution of the process that
span multiple parties irrespective of the fact whether the smart contracts
are in alignment with all the parties’ intention and understanding.
• Distributed Consensus
• A distributed consensus ensures a consensus of data among nodes
in a distributed system or reaches an agreement on a proposal.
• With the rapid development and the increasing complexity of
distributed networks, developers have always been exploring
possible solutions to solve this persistent problem in both theory
and practice.
• Next, with the rise of blockchain technology, especially 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.
• To understand distributed consensus, we need to first build an
understanding of the features of a distributed network and some
possible problems involved with a distributed network.
• Faults in Distributed Consensus
• Crash Fault
• First, let's consider cash faults. A crash fault in a distributed network often may be related to one of
the following issues:
• Nodes or replicas may experience downtime at any time, stop running for a short time and recover
later.
• The network may be interrupted at any time.
• A sent message may be lost during delivery and cannot be received.
• A sent message may be delayed and received after a long time.
• Messages may experience the out-of-order problem during the delivery process.
• The network may be divided. For example, due to poor communication between clusters in China
and the US, the entire network may be divided into two sub-networks for the China clusters and
US clusters, for instance.
• These above problems are common in distributed systems.
• They are essentially the inevitable risks caused by unreliable and unstable physical hardware in
distributed systems.
• For example, networks, or communication channels, cannot always be stable and reliable. Disks on
physical machines or CPUs will not always be of good condition.
• Therefore, it is safe to say that crash faults are the most basic and common type of faults to be
solved in distributed systems.
• The Byzantine Fault
• The crash faults are based on a simple assumption: Either nodes do not work or respond normally,
or although they work and respond normally, they cannot implement inconsistency, that is to say,
being idle is okay for them, but they cannot commit some errors.
• Malicious nodes in networks may change and forge data at any time, making it harder to solve the
consensus problem. These troublemaking problems that may change and forge data or response
information are often refer Byzantine faults. The crash fault is called a non-Byzantine fault.
• Byzantine originated from Lamport's paper. It is no exaggeration to say that Byzantine fault
tolerance (BFT) is the most complex and rigorous tolerance model.
• By analogy, some number of generals plan an attack on a castle together and each general can
choose to start the attack or retreat. However, to successfully take the castle, all the generals must
act synchronously.
• Next, given that the generals are too far from each other to use direct communication, messengers
are used to carry messages. However, messages are not reliable.
• They may successfully delivery messages after a very long time, fail to deliver messages or even
change with messages. The generals may not be reliable, either, for example, one of them may be
a traitor who does not act in accordance with the plan.
• The messengers in this story represent communication channels in distributed networks and the
generals represent nodes.
• Fault Tolerance
• The most critical problem that distributed consensus algorithms need to solve is the
question of how to implement the certainty and consensus, so that reliable consensus
results are returned across the entire distributed network, which can be full of risks
and uncertainties. Naturally, it is relatively easy to solve crash faults.
• Algorithms used to solve this type of faults are called crash fault tolerance (CFT)
algorithms or non-Byzantine fault tolerance algorithms.
• Byzantine faults may cause unauthorized changes, have higher complexity and are
more difficult to solve.
• Algorithms for solving these problems are called Byzantine fault tolerance
algorithms.
• What is the boundary between the two types of fault tolerance algorithms?
• In what scenarios do these two types of faults occur?
• Is it really necessary to take unauthorized changes into consideration?
• The answers to these questions may depend on the actual network environments and business
scenarios.
• Crash Fault Tolerance
• Generally, if a system is in a reliable internal network, we only need to
consider the issue of crash fault tolerance (CFT).
• For example, for distributed components in many companies such as
distributed storage, message queue, and distributed services, we only
need to consider CFT.
• The reasons for this is as follows:
• The entire enterprise network is closed and protected by multiple firewalls,
making external access and attacks unlikely.
• Individual nodes are deployed in a unified manner, and it is very unlikely that the
machines and running software gets changed without proper authorization.
• The distributed network is relatively "pure" at this point, and we only need to pay
special attention to the communication network and machine hardware.
• We need to consider network latency and instability as well as downtime and
faults that machines may experience at any time.
• Byzantine Fault Tolerance
• Then, there's Byzantine fault tolerance (BFT), which related to the entire distributed
network being evaluated in a larger environment.
• In addition to physical hardware, it is also necessary to take some "man-made"
factors.
• After all, it is specific persons instead of machines that perform misconduct.
• Assume that a distributed network is relatively open, for example, a private network
of tens of companies in a specific industry.
• Or assume a completely open network, for example, a network that anyone has
access to.
• Node machines and software on these machines are deployed by individual
companies or individuals themselves.
• If the benefit is tempting enough, a person may launch DDoS attacks on one of these
nodes, making authorized, often malicious changes to software code and to the code
execution logic, or even the data that is persisted on disks in the network.
• In such case, we face bigger challenges.
• In addition to the unreliable communication networks and machine hardware, we
need to consider and deal with the "troublemakers" in the system.
Byzantine fault tolerance
• Paxos
• Paxos is the oldest consensus protocol published way back in 1989 by Leslie
Lamport. Paxos is used in multiple graph databases like neo4j.
• It is also used in column store database Cassandra for leader election.
• How Paxos works:
• There are 4 friends named Rajesh, Rohit, Suresh and Vijay hanging out at
Rohit’s place.
• Rajesh is listening to music with his earplugs on, and not listening to what
others are saying.
• Suresh suggests that they all should go for a movie, and Vijay agrees with him.
• Then, Rajesh removes his earplugs and suggests they all should go for
bowling.
• Rohit agrees with him, and Vijay changes his decision and agrees with Rohit
for bowling.
• Since the other three agree on bowling, Suresh has no choice but to go for
bowling.
• Paxos algorithm
• There are 3 roles in Paxos:
• Proposers (Suresh and Rajesh)
• Acceptors (Vijay and Rohit)
• Listeners (Rajesh after a consensus reached on bowling)
• As you can see above, any actor can take on any role at a given point in time.
• Proposer wants to propose a value v and wants the system to reach a consensus on this value.
• Hence, it sends a prepare request along with an id to all the acceptors and expects
a promise response along with a value. There can be 3 cases here:
• If he gets a majority number (quorum) of promise response with null value v (This means
there is no other value v1 onto which a consensus has been reached and he can propose his
own value v), he sends an accept request which contains this value v and previously
accepted id to all the acceptors. If again he gets a majority of responses with same id and
value v, it indicates that a consensus has been reached on value v. This is what Suresh did
above
• If he gets a majority number (quorum) of promise response with a different value v1, that
means a consensus has already been reached on a value proposed by a different proposer and
it will accept value v1 as well. This is similar to what Rajesh did in our example above.
• If he doesn’t get a majority number of promise response, he will try with a higher id again.
Typical Proposer
flow
• Acceptors maintain a couple of fields in their local memory, a
maximum id (max_id) and already accepted value(v).
• If the id proposed by the Proposer is higher than the max_id and
the Acceptor has not accepted any value so far, then it accepts
that id, returns the response with null value and stores this id as the
new max_id in its local memory.
• If the id proposed by the Proposer is higher than the max_id but
the Acceptor has already accepted a different value v, then it
accepts that id, returns the response with value v and stores
this id as the new max_id in its local memory.
• If the id proposed by the Proposer is lower than the max_id, then
the Acceptor will ignore this request.
Typical Acceptor
flow
• Let’s consider another example to understand a basic interaction between all
these roles
• As you can see, the Proposer proposes id, it gets accepted
by a majority, and then the Proposer proposes a value with
that id.
• Please note that Acceptor 3 has not responded with Promise
id.
• A consensus has been reached for this value and this value
is propagated to all the nodes including listener.
• Now, let’s add another Proposer to this whole setup.
• Also, now Acceptor 3 has woken up
• New Proposer 2 sent a Prepare request with an id which is lesser than the
accepted id.
• Acceptor 1 and 2 ignored this request. Acceptor 3 which has just woken up
accepted it and sent a Promise. But since it was the only one which sent a
prepare and a majority has not sent a Prepare, Proposer 2 ignored that
response.
• Now Proposer 2 sent another Prepare request with an id which is higher
than the accepted id.
• This time, Acceptor 1 and 2 responded but with an accepted value. After
receiving the promise response with a value, Proposer 2 identified that there
is an already accepted consensus on value and it accepted that value as well.
• There can be a case of infinite loop here, when 2 proposers keep outbidding
each other with higher id.
• They will not give enough time to each other to send accept-request to
acceptors. We can solve this problem by waiting for a backoff period before
sending the next Promise request.
• Raft
• Raft is a consensus algorithm.
• It allows the members of a distributed system to agree on a
sequence of values in the presence of failures.
• More specifically, it has become the protocol of choice for
building resilient, strongly-consistent distributed systems.
• Raft can be described as a simpler version of Paxos.
• It was designed for being more understandable than Paxos.
• It is a fairly new protocol, being developed in 2014. Raft is
used in etcd, consul, docker to name a few. All of these
systems are used in Sixt.
• Raft decomposes consensus into leader election and log
propagation phases.
• After leader election, leader takes all the decisions and
communicates to other nodes through ordered logs.
• There are 3 possible states for a node in Raft consensus protocol:
• Leader
• Follower
• Candidate
• All the nodes start off with a 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. This process is called a Leader
election.
• All changes to the system now go through the leader. Each change is added as an
entry in the node’s log. Values remain in uncommitted state and get written to the
log first, and then these logs are replicated to other nodes.
• Once a majority of nodes respond, the value gets committed to the leader node as
well. The leader then notifies the followers that the entry is committed, so that the
followers can commit the value as well.
• The cluster has now come to consensus about the system state. This process is
called Log replication.
• Leader election
• Every follower waits for a certain amount of time before becoming a
candidate. This time is called the election timeout.
• After the election timeout the follower becomes a candidate and starts a
new election term. It Votes for itself and sends out Request Vote
messages to other nodes.
• If the receiving node hasn’t voted yet in this term then it votes for the
candidate and the node resets its election timeout. Once a candidate has a
majority of votes it becomes leader.
• Leader keeps sending regular messages to followers to keep it’s status as
leader. This message is called a heartbeat message. If a follower
doesn’t receive a heartbeat message in a certain time interval, it can
become a candidate and the whole cycle of leader election will repeat.
• For example, there are 3 nodes acting as a follower. Each has a different
election time out window.
• Follower with the lowest election timeout value becomes a candidate and
asks for vote.
• After the votes has been granted, candidate becomes leader.
• Now, when everybody has voted. We have a leader.
• Log replication
• Once we have a leader elected, we need to replicate all changes to our
system to all nodes. This is done by using Append Entries messages to
the followers.
• It works like this:
• Client sends a change to the elected leader.
• The change is appended to the leader’s log.
• Then the change is sent to the followers on the next heartbeat.
• An entry is committed once a majority of followers acknowledge it and a response
is sent to the client.
• This is usually called a 2 Phase commit.
• There are other protocols that solves different problems.
• ZAB (Zookeeper Atomic Broadcast) was used in zookeeper for setting a master-slave system.
• Gossip protocol is used in consul for membership detection and failures.
• Viewstamped Replication is another state machine replication protocol, and it provides
consensus too.
• Practical Byzantine Fault Tolerance(pBFT)
• Practical Byzantine Fault Tolerance is a consensus
algorithm introduced in the late 90s by Barbara Liskov
and Miguel Castro.
• pBFT was designed to work efficiently in asynchronous
(no upper bound on when the response to the request
will be received) systems.
• It is optimized for low overhead time.
• Its goal was to solve many problems associated with
already available Byzantine Fault Tolerance solutions.
• Application areas include distributed computing and
blockchain.
• What is Byzantine Fault Tolerance?
• Byzantine Fault Tolerance(BFT) is the feature of a
distributed network to reach consensus(agreement on
the same value) even when some of the nodes in the
network fail to respond or respond with incorrect
information.
• The objective of a BFT mechanism is to safeguard
against the system failures by employing collective
decision making(both – correct and faulty nodes) which
aims to reduce to influence of the faulty nodes. BFT is
derived from Byzantine Generals’ Problem.
• Byzantine Generals’ Problem
• The problem was explained aptly in a paper by LESLIE LAMPORT, ROBERT
SHOSTAK, and MARSHALL PEASE at Microsoft Research in 1982:
• Imagine that several divisions of the Byzantine army are camped outside an enemy
city, each division commanded by its own general. The generals can communicate
with one another only by messenger. After observing the enemy, they must decide
upon a common plan of action.
• However, some of the generals may be traitors, trying to prevent the loyal generals
from reaching an agreement. The generals must decide on when to attack the city, but
they need a strong majority of their army to attack at the same time. The generals
must have an algorithm to guarantee that (a) all loyal generals decide upon the same
plan of action, and (b) a small number of traitors cannot cause the loyal generals to
adopt a bad plan.
• The loyal generals will all do what the algorithm says they should, but the traitors
may do anything they wish. The algorithm must guarantee condition (a) regardless of
what the traitors do. The loyal generals should not only reach agreement, but should
agree upon a reasonable plan.
• Byzantine fault tolerance can be achieved if the correctly
working nodes in the network reach an agreement on their
values.
• There can be a default vote value given to missing messages i.e.,
we can assume that the message from a particular node is
‘faulty’ if the message is not received within a certain time
limit.
• Furthermore, we can also assign a default response if the
majority of nodes respond with a correct value.
• Leslie Lamport proved that if we have 3m+1 correctly working
processors, a consensus(agreement on same state) can be
reached if atmost m processors are faulty which means that
strictly more than two-thirds of the total number of processors
should be honest.
• Types of Byzantine Failures:
• There are two categories of failures that are considered.
• One is fail-stop(in which the node fails and stops operating) and other is
arbitrary-node failure.
• Some of the arbitrary node failures are given below :
• Failure to return a result
• Respond with an incorrect result
• Respond with a deliberately misleading result
• Respond with a different result to different parts of the system
• Advantages of pbft:
• Energy efficiency :
• pBFT can achieve distributed consensus without carrying out complex
mathematical computations(like in PoW).
• Zilliqa employs pBFT in combination with PoW-like complex computations
round for every 100th block.
• Transaction finality :
• The transactions do not require multiple confirmations(like in case of PoW
mechanism in Bitcoin where every node individually verifies all the transactions
before adding the new block to the blockchain; confirmations can take between
10-60 minutes depending upon how many entities confirm the new block) after
they have been finalized and agreed upon.
• Low reward variance :
• Every node in the network takes part in responding to the request by the client
and hence every node can be incentivized leading to low variance in rewarding
the nodes that help in decision making.
• How pBFT works ?
• pBFT tries to provide a practical Byzantine state machine replication
that can work even when malicious nodes are operating in the system.
• Nodes in a pBFT enabled distributed system are sequentially ordered
with one node being the primary(or the leader node) and others referred
to as secondary(or the backup nodes).
• Note here that any eligible node in the system can become the primary
by transitioning from secondary to primary(typically, in the case of a
primary node failure).
• The goal is that all honest nodes help in reaching a consensus regarding
the state of the system using the majority rule.
• A practical Byzantine Fault Tolerant system can function on the
condition that the maximum number of malicious nodes must not be
greater than or equal to one-third of all the nodes in the system.
• As the number of nodes increase, the system becomes more secure.
• pBFT consensus rounds are broken into 4 phases(refer
with the image below):
• The client sends a request to the primary(leader) node.
• The primary(leader) node broadcasts the request to the all
the secondary(backup) nodes.
• The nodes(primary and secondaries) perform the service
requested and then send back a reply to the client.
• The request is served successfully when the client receives
‘m+1’ replies from different nodes in the network with the
same result, where m is the maximum number of faulty
nodes allowed.
• The primary(leader) node is changed during
every view(pBFT consensus rounds) and can be
substituted by a view change protocol if a
predefined quantity of time has passed without
the leading node broadcasting a request to the
backups(secondary).
• If needed, a majority of the honest nodes can
vote on the legitimacy of the current leading node
and replace it with the next leading node in line.
• Limitations of pBFT:
• The pBFT consensus model works efficiently only when the number of nodes in the
distributed network is small due to the high communication overhead that increases
exponentially with every extra node in the network.
• Sybil attacks :
• The pBFT mechanisms are susceptible to Sybil attacks, where one entity(party) controls many
identities.
• As the number of nodes in the network increase, sybil attacks become increasingly difficult to
carry out.
• But as pBFT mechanisms have scalability issues too, the pBFT mechanism is used in
combination with other mechanism(s).
• Scaling :
• pBFT does not scale well because of its communication(with all the other nodes at every step)
overhead.
• As the number of nodes in the network increase(increases as O(n^k), where n is the messages
and k is the number of nodes), so does the time taken to respond to the request.
• Platforms using pBFT variants:
• Zilliqa – pBFT in combination with PoW consensus
• Hyperledger Fabric – permissioned version of pBFT
• Tendermint – pBFT + DPoS(Delegated Proof-of-Stake)
• Variations of pBFT:
• To enhance the quality and performance of pBFT for specific use cases
and conditions, many variations were proposed and employed.
• Some of them are :
• RBFT – Redundant BFT
• ABsTRACTs
• Q/U
• HQ – Hybrid Quorum Protocol for BFT
• Adapt
• Zyzzyva – Speculative Byzantine Fault Tolerance
• Aardvark