🔷 Permissioned Blockchain

🔹 Intro (Short & Familiar Style):

In public blockchains like Bitcoin, anyone can join, see, and verify transactions. But in real-world
companies (like banks, hospitals, supply chains), they need privacy, speed, and control.
That’s why they use permissioned blockchains, where only selected people are allowed to
take part.
🧠 Think of it like a private WhatsApp group — only invited members can see and send messages.

🔹 Simple Technical Definition:

A permissioned blockchain is a type of blockchain where only authorized participants can
access the network to read, write, or validate transactions.
It is usually used by enterprises to ensure privacy, trust, and controlled participation, and uses
blockchain features like immutability and consensus, but with restricted access.

🔹 Why is it needed?
Enterprises cannot use fully open blockchains due to privacy, legal, and control reasons. They
need:
 Controlled access – not open to the public
 Data confidentiality – important info (like patient records or banking details) must remain
private
 Faster decision-making – fewer nodes = quicker consensus
 Compliance – easier to meet regulations and audit requirements
 Trusted environment – all participants are known and verified

🔹 What is Permissioned Blockchain?

A Permissioned Blockchain is a blockchain where only selected participants (nodes) are allowed
to:
 Join the network
 Read data
 Write transactions
 Validate blocks
These participants are pre-approved and known by the organization or group managing the
blockchain.
Unlike public blockchains, it’s not open to everyone, making it more secure and controlled for
business use.
🔹 How it works?
 A central authority (or group) grants permission to members.
 Each member has a role (reader, writer, validator).
 Transactions are stored in blocks like any blockchain — but only visible to allowed members.
 Example platforms: Hyperledger Fabric, R3 Corda.
 These are specially designed for enterprise-level permissioned blockchain use.

🔹 Limitations:
 Less decentralized – requires trust in the managing authority
 Transparency is limited – outsiders cannot verify anything
 Single point of control – if the authority is corrupt, it can misuse power
 More complex setup – needs identity management, role settings, etc.

🔹 Advantages:
 ✅ Faster transactions – fewer nodes, no mining
 ✅ High security for private data
 ✅ Custom roles and access – everyone doesn't need full access
 ✅ Legal and regulatory support – better fit for businesses needing audits and records
 ✅ Industry-specific customization – great for banks, hospitals, supply chains, etc.
🔷 Design Issues in Permissioned Blockchain

🔹 Intro:
Permissioned blockchains are built for private use — only selected members can access or
control the system.
But designing such a system isn't as simple as just restricting access. There are several
challenges that must be handled carefully for the blockchain to work efficiently, securely,
and fairly.

🔹 Main Design Issues:

Identity Management
 In a permissioned blockchain, every participant must be known and verified.
 A secure identity system must be built to manage who joins and what role they have.
 Problem: If identity is mismanaged, unauthorized people may get access or valid users may
be blocked.

Access Control / Role Assignment

 Not all members should have the same permissions.
 Some may only read, others may write or validate blocks.
 The system needs a well-planned access control model to avoid misuse.
 Issue: Poor role design can lead to security or performance problems.

Centralization Risk
 Since one or few authorities control permissions, it creates a central point of trust.
 If that authority is dishonest or hacked, the whole system is at risk.
 This goes against decentralization, which is a key blockchain idea.

Consensus Mechanism Design

 Permissioned blockchains don't use Proof of Work (PoW); instead, they use lighter methods
like PBFT, RAFT, etc.
 Challenge: Choosing a method that balances speed, security, and fault tolerance.
 Wrong choice can make the network slow or unsafe.

Privacy vs. Transparency

 Businesses want privacy, but blockchain is built for transparency.
 Designers must carefully plan what data should be visible to whom.
 Problem: Over-privacy can reduce auditability, while over-transparency can risk sensitive
data.
Scalability
 As more members join, the system must handle more transactions and access requests.
 Need to design a network that remains fast and efficient.
 Risk: Poor design may slow down the network as it grows.
Interoperability
 Enterprises often need to connect their blockchain with other systems or blockchains.
 Designing a permissioned blockchain that can interact securely with external systems is
challenging.

🔷 Distributed Consensus

🔹 Intro:
In blockchain or any distributed system, there’s no single boss or central computer to make
decisions.
So, how do all the computers (called nodes) agree on what’s true — like which transaction is
valid or which block should be added?
That’s where Distributed Consensus comes in — it helps all nodes come to the same decision,
even if some fail or lie.

🔹 What is Distributed Consensus? (Simple Definition)

It is a process used in distributed systems (like blockchain) where multiple nodes agree on a
single version of truth or data, even if some nodes are faulty or untrusted.

🔹 Why is it Important?
 Blockchain has no central authority.
 So, nodes must agree among themselves about which transaction/block is correct.
 Prevents cheating, double spending, or forks.

🔹 How it Works (Simple):

 A node proposes a transaction or block.
 Other nodes check if it’s valid.
 If a majority (like 51%) agree, the transaction is accepted and added to the chain.
 If they don’t agree, it’s rejected.
🔄 This agreement process = Consensus Algorithm
🔹 Common Consensus Methods:
 Proof of Work (PoW) – Solve hard puzzles (used in Bitcoin)
 Proof of Stake (PoS) – Based on coins locked by user
 PBFT (Practical Byzantine Fault Tolerance) – Used in private blockchains
 RAFT, DPoS, etc. – Others used for faster, enterprise-grade systems

🔹 Example to Understand:
Imagine 10 friends trying to agree on what movie to watch.
If 6 out of 10 vote for the same one, they go with it.
Even if a few lie or don’t respond — as long as most agree, a decision is made.
That’s consensus.
🔷 RAFT Consensus (Simple + Technical)

🔹 Intro:
RAFT is a method used in private blockchains (like those in banks or companies) to help all the
computers (called nodes) agree on the same data, like transactions inside a block.
It is used when users are known and trusted, and we need fast, secure, and clear agreement
without using mining.

🔹 What is RAFT?
RAFT is a consensus algorithm. That means it helps all the nodes in a blockchain network agree
on which transaction blocks are correct and in what order they should be saved.
It is not used in public blockchains like Bitcoin, but in permissioned (private) blockchains where
the users are already trusted.

🔹 How RAFT Works:

🔸 1. Leader Node
 One node is chosen as the leader.
 The leader receives transaction requests from users.
 It collects them and creates a block with those transactions.
🔸 2. Sharing the Block
 The leader sends the new block to all other nodes (called followers).
 If most nodes agree, they all save the block on their blockchain.
🔸 3. Everyone Stays in Sync
 After agreement, all nodes have the same blockchain, with the same transactions in the
same order.
🔸 4. If Leader Fails
 If the leader goes offline or crashes, the nodes vote to choose a new leader.

🔹 Roles of Nodes in RAFT:

 Leader – Takes transaction requests, creates blocks, shares with others.
 Followers – Accept blocks and store them after checking.
 Candidate – Becomes leader if the current one fails.

🔹 Why Use RAFT?

✅ Fast block confirmation (no mining)
✅ Works well with trusted users (like companies or banks)
✅ Keeps all nodes in sync
✅ Easy to understand and manage compared to complex systems like Paxos

🔹 Limitations:
❌ Not good for public blockchains (no mining, no anonymous users)
❌ Needs a trusted system
❌ If the leader fails, the system pauses briefly

🧠 Simple Example:
Imagine a team of friends working on a shared notebook (blockchain).
One friend (leader) writes what happened today (transactions).
Before finalizing the page (block), they ask everyone if it’s correct.
If most agree, the page is saved, and everyone copies it.
If the leader leaves, they vote and pick a new leader.

🔹 Real Use Cases:

 🔐 Hyperledger Fabric (for private blockchain systems)
 🔄 Distributed databases (like etcd, Consul)
🔷 Byzantine Fault Tolerance (BFT)

🔹 What is BFT?
Byzantine Fault Tolerance is the ability of a system to keep working properly even when some
of its members give wrong or misleading information.
It means the system can still make the right decision even if some people inside are lying, not
responding, or making mistakes.

🔹 Why is BFT Needed?

In any group-based system (like computer networks, military decisions, or even team voting),
not everyone will always behave correctly.
Some may be faulty, hacked, or intentionally dishonest.
To prevent the whole system from failing or making wrong decisions, BFT makes sure that:
“As long as most members are honest, the system will still work fine.”

🔹 Why the Name "Byzantine"?

This idea comes from a famous computer science story called the Byzantine Generals Problem.
📖 Short Story:
Several army generals surround a city. They must agree on a single plan — attack or retreat.
But they can only communicate by sending messages.
Some generals might be traitors, sending false messages to confuse others.
How can they trust the decision, and act together, even if some generals lie?
This is the Byzantine Fault, and the system that can handle it is called Byzantine Fault Tolerant.

🔹 How Does BFT Work? (Simple Logic)

1. Everyone in the system shares what they believe or know.
2. They compare messages from others.
3. If a majority agree on something, it is accepted as correct.
4. The system ignores minority members who send wrong or inconsistent messages.
5. Even if a few members are dishonest, their effect is cancelled by the majority vote.

🔹 Advantages of BFT:
✅ Prevents wrong decisions even with bad actors
✅ Keeps the system running smoothly
✅ No need for a central authority to decide
✅ Useful in private networks where all members are known

🔹 Limitations of BFT:
❌ Not suitable for very large public systems (too much communication needed)
❌ Can be slower with many members
❌ Requires members to know and trust the system setup

🔷 Lamport-Shostak-Pease Algorithm (BFT Algorithm)

🔹 Intro:
This algorithm was proposed in 1982 by Leslie Lamport, Robert Shostak, and Marshall Pease.
It was the first formal solution to the Byzantine Generals Problem and explained how a group of
computers (called nodes) can still reach agreement even when some are faulty or malicious.

🔹 Why is it needed?
In distributed systems:
 Some computers (nodes) may fail or act maliciously (called Byzantine faults).
 But we still want all the honest ones to agree on the same decision.
This algorithm tells us:
✅ How many nodes we need
✅ How to communicate
✅ And how to detect faulty behavior

🔹 What it does:
It helps a group of n nodes reach an agreement even if up to f nodes are faulty —
but only if n ≥ 3f + 1
👉 For example:
If you want to tolerate 1 faulty node, you need at least 4 total nodes.

🔹 How it works (In Simple Terms):

Let’s say 1 node is the Commander (who gives the order), and the others are Lieutenants.
The algorithm runs in rounds:
1. Round 1:
Commander sends a message to all lieutenants (like “attack” or “retreat”).
2. Round 2:
Every lieutenant forwards what they received to every other lieutenant.
3. Decision:
Each lieutenant collects all messages, checks for inconsistencies, and uses a majority vote to
decide the final value.
This way:
 If a traitor tries to send different messages to different lieutenants, the group can detect
and ignore them.
 As long as most nodes are honest, the group will agree on the same decision.

🔹 Example:
Let’s say:
 Commander says “Attack”
 One traitor lieutenant lies and says, “Commander said Retreat”
 Others cross-check all messages
 Majority still says “Attack”, so the final decision is safe ✅

🔹 Limitations:
 Message-heavy: Requires a lot of communication between nodes.
 Doesn’t scale well to very large systems.
 Works best when all participants are known (like in permissioned blockchain).

🔹 Why it’s Important:

It proved that:
To tolerate f faulty nodes, you need at least 3f + 1 total nodes.
This rule is still used in modern BFT systems like:
 PBFT
 Tendermint
 HyperledgerFabric