Block Chain Technologies (AL-802 (A)) Unit 3 Notes

How unit 3 is examined

This unit covers permissioned blockchains and consensus among known nodes (Paxos, Raft, Byzantine fault tolerance); the marks lie in the permissioned model, its design issues, closed-environment consensus, BFT applications and the Lamport-Shostak-Pease algorithm.

Permissioned Block chain: Permissioned model and use cases

Medium weight

Definition. A permissioned blockchain is a ledger in which only identified, authorised participants may join, read, propose or validate transactions, so trust rests on known identities and a shared ledger rather than on anonymous mining.

Key points.

Every member is enrolled by a membership authority, so each transaction can be traced to a known identity and misbehaviour has legal consequences.
Trust: parties who do not fully trust each other share one ledger, so no single party owns the truth and nobody can alter history alone.
Disintermediation: the shared ledger and smart contracts replace banks, clearing houses and other middlemen, which cuts cost and settlement time.
Transparency and traceability: all permitted members see the same records, and every asset or transaction has an auditable, time-stamped history.
Security and immutability: appended records are hash-linked and cannot be silently changed, and access control limits who sees what.
Efficiency: validators are known, so fast consensus (PBFT, Raft) gives high throughput and quick finality instead of energy-hungry mining.
Fit test: choose a blockchain when many parties write shared data, trust is low and no neutral intermediary is wanted; otherwise a normal central database is cheaper and faster.
Use cases: supply-chain tracking, trade finance, cross-border payments, KYC and healthcare records.

Example. In a food supply chain, farmer, shipper and retailer write to one shared ledger, so a contaminated batch is traced to its source in minutes instead of days through paper records.

Traditional business network	Blockchain network
Each party keeps its own ledger and must reconcile	One shared ledger, always in sync
Intermediary needed for trust	Consensus and smart contracts give trust
Slow, paper based, costly	Fast and automated
Records can be disputed or altered	Immutable and traceable

Answer frame. Open with the definition; then reasons 2-6 in order, one sentence each; add the comparison table for the "revolutionizing business network" wording; give the supply-chain example; close with the fit test (blockchain when multiple untrusting writers, database otherwise).

Asked: [7 marks] (May 2022) Discuss why an organization might decide to implement a block chain solution? How block chain is revolutionizing the traditional business network? Explain with example.

Design issues for Permissioned block chains

Definition. Design issues of a permissioned blockchain are the choices that must be made about who may join, how the known validators agree, what stays private, and who governs the network.

Key points.

Membership and identity: a certificate authority or membership service issues identities, so the design must decide who enrols, how identities are revoked and how they map to roles.
Consensus choice: because validators are known, crash-fault protocols (Paxos, Raft) or Byzantine-fault protocols (PBFT) are used, and the choice depends on whether members can be malicious.
Privacy and confidentiality: competitors share a chain, so private channels, encrypted data and restricted views are needed to stop leaks of business data.
Access control: permissions decide who can read, write, deploy contracts or act as validators, and are enforced at node and contract level.
Governance: the consortium must agree rules for adding or removing members, upgrading contracts and settling disputes.
Scalability and throughput: BFT protocols exchange many messages, so throughput falls as the number of validators grows, which is a trade-off against fault tolerance.
Smart-contract execution and integration: contracts must be deterministic, and the chain must integrate with existing enterprise systems.
Use cases where these apply: banking, enterprise supply chains and healthcare.

Answer frame. Open by defining a permissioned chain with known validators; draw a box diagram (members, membership service, validators, ledger); develop points 1-6 in order; close with the trade-off of performance and privacy against decentralisation.

Asked: [7 marks] (May 2022, May 2024) What are the design issues for permissioned block chain? Discuss design issues for permissioned blockchains and use cases.

Execute contracts

Definition. Executing contracts means running smart-contract code (chaincode) on the peers so that every node reaches the same state change from the same transaction.

Key points.

Contract code must be deterministic, so every node computing it obtains the identical result.
In order-execute designs, transactions are first ordered by consensus and then every node executes them in that order.
In execute-order-validate designs (Hyperledger Fabric), only endorsing peers execute first, then ordering and validation follow, which improves scalability.
Chaincode runs in an isolated container to protect the peer from faulty code.

State machine replication

Definition. State machine replication (SMR) keeps identical copies of a deterministic state machine on several servers, and applies the same commands in the same order so all replicas stay consistent.

Key points.

A blockchain is an SMR system: the ledger is the state and transactions are the commands.
Replicas must be deterministic and start in the same initial state.
A consensus protocol gives the total order of commands.
With crash faults, $2f+1$ replicas tolerate $f$ failures; with Byzantine faults, $3f+1$ are needed.

Overview of Consensus models for permissioned block chain

Definition. Consensus in a permissioned chain is agreement among known validators on the order and validity of transactions, done by voting protocols rather than mining.

Key points.

Crash-fault-tolerant models (Paxos, Raft) assume nodes fail only by stopping and need $2f+1$ nodes.
Byzantine-fault-tolerant models (PBFT, LSP) assume nodes may lie and need $3f+1$ nodes.
Voting protocols give immediate finality, unlike probabilistic finality in Proof of Work.
Message cost grows with the number of nodes, so these suit tens of validators, not thousands.

Distributed consensus in closed environment

Definition. Distributed consensus in a closed environment is agreement among a fixed, known set of nodes on a single value or ordered log, even when some nodes fail.

Key points.

Membership is known and fixed, so voting-based protocols work; there is no need for mining or anonymous puzzle-solving.
Examples are Paxos and Raft for crash faults, and PBFT for Byzantine faults.
Advantages are finality (a committed block is never reverted), high speed and low energy use.
The trade-off is a stronger trust assumption: it needs known identities, a bounded fraction of faulty nodes and limited scalability.

Asked: [7 marks] (May 2022) Give a brief note on distributed consensus in closed environment.

Paxos

Definition. Paxos is a consensus protocol by Lamport in which a majority of crash-prone nodes agrees on one value using proposers, acceptors and learners.

Key points.

Phase 1: a proposer sends prepare(n) with a proposal number, and acceptors promise not to accept lower numbers.
Phase 2: if a majority promise, the proposer sends accept(n, value), choosing the highest value already accepted, if any.
A value is chosen once a majority of acceptors accept it, and learners are then informed.
It tolerates $f$ crash failures with $2f+1$ nodes but is hard to understand, which led to Raft.

RAFT Consensus

Definition. Raft is a leader-based consensus protocol that keeps a replicated log consistent by electing one leader who orders all entries.

Key points.

Each node is a follower, candidate or leader, and time is divided into numbered terms.
Leader election: a follower that hears no heartbeat times out (random timeout), becomes a candidate and wins with votes from a majority.
Log replication: the leader appends client commands, sends them to followers, and commits an entry once a majority has stored it.
Raft tolerates crash faults only, with $2f+1$ nodes, and is easier to understand than Paxos.

Byzantine general problem

Definition. The Byzantine Generals Problem asks how loyal generals can agree on a common plan (attack or retreat) when some generals, or their messages, are traitorous.

Key points.

Agreement condition (IC1): all loyal lieutenants obey the same order.
Validity condition (IC2): if the commander is loyal, every loyal lieutenant obeys his order.
With oral (unsigned) messages, no solution exists with three generals and one traitor; $n \ge 3m+1$ is needed for $m$ traitors.
It models faulty nodes that send conflicting or false messages in a distributed system.

Byzantine fault tolerant system

Definition. A Byzantine fault tolerant system keeps working correctly and reaches agreement even when up to $f$ of its $3f+1$ nodes fail arbitrarily or act maliciously.

Key points.

PBFT runs pre-prepare, prepare and commit phases, with a primary node ordering the requests.
Applications are permissioned blockchains such as Hyperledger Fabric (BFT ordering) and Tendermint (used in Cosmos), plus finance, supply chain and IoT networks.
Industry also uses BFT in aircraft control and spacecraft systems, where a faulty component must not cause failure.
It gives immediate finality but has heavy message cost ($O(n^2)$), which limits the node count.

Asked: [7 marks] (May 2024) What are some practical applications of Byzantine fault tolerant systems, and how are they used in industry?

Lamport-Shostak-Pease BFT Algorithm

Definition. The Lamport-Shostak-Pease algorithm solves the Byzantine Generals Problem for oral messages with the recursive procedure OM(m), which works only if $n \ge 3m+1$ (at most $m$ traitors).

Key points.

OM(0): the commander sends his value to every lieutenant, who uses it (default value if none arrives).
OM(m), $m>0$: the commander sends his value to all lieutenants; each lieutenant then acts as commander in OM(m-1) to relay the value to the others.
Each lieutenant takes the majority of the value received directly and the values relayed by the others.
Example $n=4$, $m=1$: if lieutenant L3 is a traitor, L1 and L2 each see (v, v, x), so majority is v and both obey the loyal commander; if the commander is the traitor and sends x, y, z, all loyal lieutenants see the same set and reach the same default decision.
Conclusion: OM(m) achieves agreement and validity with $m$ traitors when $n \ge 3m+1$; it needs $m+1$ rounds and many messages.

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u3-01" viewBox="0 0 338 252" width="338" height="252" role="img" aria-label="OM(1) with n=4: commander C sends v, then lieutenants L1-L3 relay it"><style>#dsfig-u3-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u3-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u3-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u3-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u3-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u3-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u3-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u3-01 .t{fill:#16181D;font-weight:500}#dsfig-u3-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u3-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u3-01 .dot{fill:#16181D}#dsfig-u3-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u3-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u3-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u3-01 .ah{fill:#454C5A}#dsfig-u3-01 .ah.hi{fill:#2340B8}#dsfig-u3-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u3-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u3-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u3-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u3-01 .e{stroke:#B1B7C3}html.dark #dsfig-u3-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u3-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u3-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u3-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u3-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u3-01 .t{fill:#E6E8ED}html.dark #dsfig-u3-01 .t.inv{fill:#0F1115}html.dark #dsfig-u3-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u3-01 .dot{fill:#E6E8ED}html.dark #dsfig-u3-01 .ann{fill:#8FA3FF}html.dark #dsfig-u3-01 .lbl{fill:#858D9C}html.dark #dsfig-u3-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u3-01 .ah{fill:#B1B7C3}html.dark #dsfig-u3-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u3-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u3-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u3-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah4" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh4" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M157.6,55.2 L52.6,195.2" marker-end="url(#ah4)"/><path class="e" d="M169,59 L169,191" marker-end="url(#ah4)"/><path class="e" d="M180.4,55.2 L285.4,195.2" marker-end="url(#ah4)"/><path class="e" d="M61,212 L148,212" marker-end="url(#ah4)" marker-start="url(#ah4)"/><path class="e" d="M190,212 L277,212" marker-end="url(#ah4)" marker-start="url(#ah4)"/><path class="e" d="M61,212 L277,212" marker-end="url(#ah4)" marker-start="url(#ah4)"/><g class="wl"><rect x="94.9" y="117" width="19.2" height="18" rx="9"/><text class="t" x="104.5" y="126" dy=".35em" text-anchor="middle">v</text></g><g class="wl"><rect x="159.4" y="117" width="19.2" height="18" rx="9"/><text class="t" x="169" y="126" dy=".35em" text-anchor="middle">v</text></g><g class="wl"><rect x="223.9" y="117" width="19.2" height="18" rx="9"/><text class="t" x="233.5" y="126" dy=".35em" text-anchor="middle">v</text></g><circle class="n" cx="169" cy="40" r="18"/><text class="t" x="169" y="40" dy=".35em" text-anchor="middle">C</text><circle class="n" cx="40" cy="212" r="18"/><text class="t" x="40" y="212" dy=".35em" text-anchor="middle">L1</text><circle class="n" cx="169" cy="212" r="18"/><text class="t" x="169" y="212" dy=".35em" text-anchor="middle">L2</text><circle class="n" cx="298" cy="212" r="18"/><text class="t" x="298" y="212" dy=".35em" text-anchor="middle">L3</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">OM(1) with n=4: commander C sends v, then lieutenants L1-L3 relay it</figcaption></figure>

Asked: [7 marks] (May 2022) Explain Lamport-Shostak-Pease BFT algorithm.

BFT over Asynchronous systems

Definition. In an asynchronous system message delay has no bound, so BFT protocols cannot tell a slow node from a faulty one, and safety must hold regardless of timing.

Key points.

The FLP result says no deterministic protocol can guarantee consensus in an asynchronous system with even one crash fault.
Practical protocols such as PBFT keep safety always and guarantee liveness only when the network is eventually synchronous.
Randomised protocols such as HoneyBadgerBFT achieve consensus in fully asynchronous networks.
The requirement remains $n \ge 3f+1$.

Last-minute revision

Permissioned chain: known, authorised participants; trust from identity and shared ledger.
Reasons to adopt blockchain: trust, disintermediation, transparency, traceability, efficiency, security.
Design issues: membership, consensus choice, privacy, access control, governance, scalability.
SMR: same deterministic commands in the same order on all replicas.
Crash faults need $2f+1$ nodes (Paxos, Raft); Byzantine faults need $3f+1$ (PBFT, LSP).
Paxos: prepare/promise, then accept, majority chooses the value.
Raft: follower, candidate, leader; terms; heartbeat; majority commits.
Byzantine generals: agreement (IC1) and validity (IC2); $n \ge 3m+1$.
OM(m) needs $m+1$ rounds; the $n=4$, $m=1$ case is the standard example.
FLP: no deterministic asynchronous consensus with one fault.

Memory hooks

"Known members, quick votes": permissioned means voting, not mining.
2f+1 for Crash, 3f+1 for Cruel (Byzantine).
Paxos = Prepare, Promise, Propose, Pick.
Raft = Randomised timeout, Ask votes, Follow leader, Team log.
OM(m): commander tells, lieutenants relay, then majority.

Coverage checklist

Permissioned Block chain: Permissioned model and use cases: Q5 (why organisations adopt blockchain; revolutionizing business network)
Design issues for Permissioned block chains: Q2 (design issues and use cases)
Execute contracts: no past questions
State machine replication: no past questions
Overview of Consensus models for permissioned block chain: no past questions
Distributed consensus in closed environment: Q3 (brief note)
Paxos: no past questions
RAFT Consensus: no past questions
Byzantine general problem: no past questions
Byzantine fault tolerant system: Q1 (applications and industry use)
Lamport-Shostak-Pease BFT Algorithm: Q4 (explain the algorithm)
BFT over Asynchronous systems: no past questions

Account

Block Chain Technologies (AL-802 (A)) - Unit 3 Short Notes

How unit 3 is examined

Permissioned Block chain: Permissioned model and use cases

Design issues for Permissioned block chains

Execute contracts

State machine replication

Overview of Consensus models for permissioned block chain

Distributed consensus in closed environment

Paxos

RAFT Consensus

Byzantine general problem

Byzantine fault tolerant system

Lamport-Shostak-Pease BFT Algorithm

BFT over Asynchronous systems

Last-minute revision

Memory hooks

Coverage checklist