Block Chain Technology

UNIT-4
RAFT Consensus:-
Raft is a consensus algorithm that's gaining popularity in permissioned blockchains and other
distributed systems. It's a leader-based model that focuses on understandability and simplicity
compared to other algorithms like Paxos. Its main goal is to ensure that all nodes in a distributed system
agree on the same sequence of actions, even if some nodes fail.

How Raft Works

Raft breaks down the consensus problem into three key sub-problems:

 Leader Election: In a Raft cluster, all nodes start as followers. If a follower doesn't receive a
message from a leader within a certain time, it becomes a candidate and requests votes from
other nodes. The first candidate to get a majority of votes becomes the leader. This leader is
then responsible for all subsequent actions and sends periodic "heartbeat" messages to the
followers to maintain its authority.

 Log Replication: Once a leader is elected, it's responsible for all client requests. When a client
sends a transaction to the leader, the leader appends the transaction to its own local log. It then
sends an "AppendEntries" message to all the followers, asking them to replicate the same log
entry. A log entry is considered committed and applied to the state machine only after a
majority of nodes have acknowledged that they've received and stored it.

 Safety and Consistency: Raft guarantees that all committed log entries are durable and will not
be overwritten. It also ensures that only nodes with the most up-to-date logs can become
leaders. This prevents an outdated leader from making decisions that could lead to
inconsistencies.
Raft in Blockchain

Raft is primarily used in permissioned blockchains, like Hyperledger Fabric, rather than public, open-
access ones like Bitcoin or Ethereum. Here's why:

 Trust and Identity: In a permissioned blockchain, all participating nodes are known and trusted,
which makes a leader-based model feasible. Raft works by having a single leader at any given
time, which simplifies the consensus process and increases transaction speed. In contrast, public
blockchains require "leaderless" consensus algorithms like Proof-of-Work (PoW) or Proof-of-
Stake (PoS) to achieve trust among unknown participants.

 Efficiency: Raft is much more efficient than PoW because it doesn't require a resource-intensive
mining process. This allows for higher transaction throughput and lower latency, which is crucial
for enterprise-level applications.

 Centralization: The leader-based model of Raft introduces a degree of centralization. While this
is a drawback for public blockchains, it's an acceptable tradeoff in a private or consortium
blockchain where participants are pre-selected and a single, trusted authority is often a part of
the network design.

In summary, Raft provides a simple, robust, and highly performant consensus solution for distributed
systems, making it a powerful choice for building private, enterprise-grade blockchain applications.

Byzantine general problem:-

The Byzantine Generals Problem is a game theory problem that describes the difficulty decentralized
systems face in reaching consensus without a central authority. First introduced in 1982 by Leslie
Lamport, Robert Shostak, and Marshall Pease, it was initially framed as a theoretical computing problem:

In a network where no participant can fully verify the identity or honesty of others, how can they all
agree on a single version of the truth? This question is critical for decentralized networks like Bitcoin,
where trust is not placed in a single party but distributed across many participants.

The Byzantine Generals Problem is best understood through an analogy. Several generals are besieging a
city called Byzantium and must decide when to attack. If they all attack simultaneously, they win. If they
attack at different times, they lose.

However, the generals have no secure communication channels. Messages can be intercepted, delayed,
or modified by the enemy. This makes coordination difficult and introduces the risk of deception. How
can the generals organize to attack at the same time?
How Centralized Systems Avoid the Byzantine Generals Problem:-
Only decentralized systems face the Byzantine Generals Problem because they lack a single, trusted
source of truth. In centralized systems, an authority is responsible for verifying and distributing accurate
information.

For example, in traditional finance, banks are trusted to maintain accurate balances and transaction
histories. If a bank were to manipulate data or commit fraud, a central bank or government authority is
expected to intervene and restore trust.

However, centralized systems do not solve the Byzantine Generals Problem; they bypass it by relying on a
central authority. While this approach provides efficiency, it also creates risks. For example, if the central
authority is compromised, the entire system is at risk of failure or corruption.

What Is Byzantine Fault Tolerance?

To overcome the Byzantine Generals Problem, decentralized networks must be designed with Byzantine
Fault Tolerance (BFT). This means they can continue functioning correctly even if some participants act
maliciously or send false information. A Byzantine fault-tolerant system does not require every
participant to be trustworthy because it only needs a majority to maintain consensus.
Bitcoin is an example of a Byzantine fault-tolerant system. It achieves this through its Proof-of-
Work consensus mechanism. In this system, miners must expend computational energy to propose new
blocks. Because bitcoin mining requires real-world resources, attempting to deceive the network
becomes prohibitively expensive. Any dishonest behavior, such as broadcasting false transactions, is
rejected by the network.

Byzantine Fault Tolerance is essential for decentralized networks, allowing them to function reliably
without a central authority. Without it, consensus would be impossible, making trustless systems
unworkable.

Common Types of Protocols

Different blockchains use various consensus mechanisms, each with its own trade-offs in terms of
security, scalability, and energy consumption. The most prominent ones are:

 Proof of Work (PoW): This is the original protocol used by Bitcoin. It requires nodes, called
miners, to solve a complex mathematical puzzle. The first miner to find the solution gets to add
the next block to the chain and is rewarded with cryptocurrency. PoW is very secure and
decentralized, but it's slow and highly energy-intensive.

o Examples: Bitcoin, Litecoin.

 Proof of Stake (PoS): PoS addresses the energy concerns of PoW. Instead of mining, nodes called
validators are chosen to create new blocks based on how much cryptocurrency they've "staked"
or locked up as collateral. The more a validator stakes, the higher their chance of being selected.
If a validator acts maliciously, they can lose their staked funds.

o Examples: Ethereum (after "The Merge"), Cardano, Tezos.

 Delegated Proof of Stake (DPoS): A variation of PoS where token holders elect a limited number
of delegates (or witnesses) to validate transactions and create blocks. This system is faster and
more scalable than PoS and PoW because it involves a smaller, more centralized group of
validators.

o Examples: EOS, Tron.

 Practical Byzantine Fault Tolerance (PBFT): This protocol is used in permissioned or private
blockchains where the network participants are known and trusted. It's a voting-based system
where a supermajority (more than two-thirds) of validators must agree on the next block. It
offers high throughput and low latency.

o Examples: Hyperledger Fabric.

Agreement Protocols in Distributed Systems:-
Agreement protocols in distributed systems are mechanisms that ensure all participating nodes or
processes reach a consensus on a single decision or state despite potential failures, network partitions,
or asynchronous communication. These protocols are crucial for maintaining consistency and reliability
in decentralized environments. Key types include:

 Consensus Protocols: Ensure all nodes agree on a single value or decision (e.g., Paxos, Raft).

 Atomic Broadcast: Guarantees that messages are delivered to all nodes in the same order (e.g.,
Total Order Broadcast).

 Two-Phase Commit (2PC): A protocol for ensuring all participants in a distributed transaction
agree to commit or abort the transaction.

 When several sites are communicating, trust is required between them.

 To reach upon single agreed value.
 There are n processors/nodes in a network.
 Each processor can communicate directly with other processor.
 M faculty nodes can be there.
 Each receiver knows identity of sender nodes.
 Total number of nodes=n , faculty nodes=m

What are Distributed Systems?

Distributed systems are networks of independent computers that work together to achieve a common
goal, appearing as a single cohesive system to users. They share resources, such as processing power and
storage, and communicate over a network to provide reliable and scalable services, often handling tasks
like data processing, file sharing, and web services.

Lamport-Shostak-Pease BFT Algorithm

1. The Lamport-Shostak-Pease (LSP) algorithm is a Byzantine Fault Tolerance (BFT) algorithm that
was first proposed by Leslie Lamport, Robert Shostak, and Marshall Pease in 1982.

2. It is a simple and efficient algorithm that can be used to achieve BFT in a distributed system,
such as a blockchain network.

3. In the LSP algorithm, nodes in the network are divided into two
groups: generals and lieutenants.
 4. Generals are responsible for proposing values, and lieutenants are responsible for voting on
proposed values.

5. In blockchain, LSP algorithm can be used as a consensus algorithm to ensure that all nodes in the
network agree on the state of the blockchain.

6. LSP is designed to be fault-tolerant and can handle network partitions and failures, making it a
suitable option for permissioned blockchains.

#Another explanation
Lamport Shoskat Pease Algorithm

The main idea behind this algorithm is: There is a commander and N lieutenants. The commander
initiates the process and sends an initial message to all the lieutenants in the closed network. Later, each
lieutenant forwards the value received from the commander to the other lieutenants except the sender.
So at the end of the rounds, all the lieutenants must be having N-1 values, except the offline lieutenants.
In the end, they will apply the majority voting principle and achieves the consensus. This is one of the
first algorithms for Byzantine Generals’ Problem.

Base Condition for Commander

Pulse-1 is the initial pulse where the commander sends the message to all the Lieutenants. Broadcast (N,
t=0), where N is the number of processes and t is the algorithm parameter, denotes the individual
rounds. The Commander decides his own value, and in this case, the possible values are {retreat, attack}.
In this example, N = 3 has three different lieutenants and is trying to reach a consensus.
Base Condition for Lieutenant

Each lieutenant receives the message from the commander and checks whether it is a pulse-1 message
or not. If it is a pulse-1 message, and the sender is the commander, accept it; otherwise, wait for a pulse-
1 message. Suppose a pulse-1 message is received then broadcast this message to all other processes in
the network.

General Condition for Lieutenant

All the lieutenants broadcast their values to the other lieutenants except the senders. At the end of the
rounds, all the lieutenants must be having N-1 values, except the offline lieutenants. In the end, they will
apply the majority voting principle and achieves the consensus.
In this agreement Protocol, after N rounds, each process must be having the N values; this is because the
system is synchronous and having a reliable communication medium. Once they have, N values can apply
the majority voting principle and achieve the consensus. However, to achieve consensus, the system
should satisfy the below condition.

 The system must have a minimum of three lieutenants (N =3) and a commander. So, out of N
number of processes (lieutenants), maximum of F number of the processes can be faulty, and F +
1 number of processes must be non-faulty such that N = 2*F + 1.

 The system should be fully connected, and the receivers always know the identity of the senders.

 The system should be synchronous and having a reliable communication medium.

BFT over Asynchronous systems

1. A Byzantine Fault Tolerance (BFT) system is typically designed to work in a synchronous network,
where all nodes have a consistent view of time and can communicate with each other in a timely
manner.

2. When BFT is applied to asynchronous systems, there is a risk of algorithm being stuck in an
infinite loop, or that it may not be able to reach the agreement on the state of the blockchain.

3. To address this, several modifications have been proposed to BFT algorithms such as :

 First approach: use a hybrid BFT algorithm, which combines a synchronous BFT algorithm with a
gossip protocol.

 Second approach: use a modified BFT algorithm, such as Asynchronous BFT (ABFT), which is
designed to work in asynchronous networks.

 Third approach: use a probabilistic BFT algorithm, such as HoneyBadgerBFT, which uses a
combination of secret sharing and threshold signing to ensure that the network can reach
agreement.

Practical Byzantine Fault Tolerance (PBFT):-

It is a consensus algorithm designed to achieve agreement in a distributed system, even in the presence
of malicious or faulty nodes. Developed in 1999 by Miguel Castro and Barbara Liskov, it's a significant
improvement over the original Byzantine Fault Tolerance (BFT) algorithms, making the concept
"practical" for real-world applications.
The Problem It Solves

Like the original BFT algorithms, PBFT is a solution to the Byzantine Generals Problem. It allows a
network of nodes to agree on a single, correct state of the system and a transaction order. Its key
innovation is reducing the high communication overhead that plagued earlier BFT algorithms, making it
suitable for systems with a moderate number of nodes.

How does pBFT work?

The pBFT algorithm provides practical state machine replication in which all nodes are sequentially
ordered, with one node as the primary node and others as secondary nodes (backup/replica nodes). A
pBFT can function on the condition that the total number of malicious nodes must be less than one-third
of the total nodes nn in the system.

The pBFT consensus happens in the following five steps:

1. The client makes a request and sends it to the primary node.

2. The primary node broadcasts the request to all the secondary(backup) nodes. It is called the pre-
prepare phase.

3. Then every node (primary and secondary) sends a prepare message to all other nodes.

4. Once every node receives (n/3)+1(n/3)+1prepare messages, it sends a commit message to all
other nodes and commits the changes made by the client's request.

5. Once every node receives (n/3)+1(n/3)+1 commit messages from other nodes, it sends a reply to
the client.