24NB28 - Blockchain Technology and Applications

1 a) a. A decentralized crowdfunding application requires that funds are automatically returned

to contributors if a specific funding goal is not reached within 30 days. Identify the essential development tools
and frameworks within the Ethereum ecosystem required to build, test, and deploy this solution. Develop a
Solidity smart contract that would handle this time-bound logic using standard Ethereum components.

Essential Ethereum Development Tools and Frameworks (2 Marks)

● Solidity – Smart contract programming language.

● Remix IDE – Development and debugging environment.
● Hardhat/Truffle – Frameworks for development, testing, and deployment.
● Ganache – Local Ethereum blockchain for testing.
● MetaMask – Wallet for interacting with smart contracts.
● [Link]/[Link] – Libraries for blockchain communication.
● Ethereum Mainnet/Testnet (Sepolia) – Deployment networks. (Any

Framework and development tools can be used as per your choice)

Solidity Smart Contract (4 Marks)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Crowdfunding {

address public owner;

uint public goal;
uint public deadline;
uint public totalAmount;

mapping(address => uint) public donations;

constructor(uint _goal) {
owner = [Link];
goal = _goal;
deadline = [Link] + 30 days;
}

// Donate Ether
function donate() public payable {
donations[[Link]] += [Link];
totalAmount += [Link];
}

// Owner withdraws money if goal reached

 function withdraw() public {
require([Link] == owner, "Not owner");
require(totalAmount >= goal, "Goal not reached");

payable(owner).transfer(totalAmount);
}

// Refund if goal not reached after deadline

function refund() public {
require([Link] > deadline, "Campaign active");
require(totalAmount < goal, "Goal reached");

uint amount = donations[[Link]];

donations[[Link]] = 0;

payable([Link]).transfer(amount);
}
}
Working of the Contract (2 Marks)

The contract owner creates the campaign with a funding goal.

Users send Ether using the donate() function.

All donations are stored in a mapping.

A deadline of 30 days is set using [Link].

If the funding goal is reached, the owner can withdraw funds using withdraw().

If the goal is not reached after 30 days, contributors can get their money back using refund().

The process is automatic, transparent, and does not require any intermediary.

b) Analyze and compare the architectural frameworks of the Ethereum Mainnet and Hyperledger Fabric by
deconstructing their core components and design philosophies.

Ethereum Mainnet Architecture and Design Philosophy (3 Marks)

Ethereum Mainnet is a public, permissionless blockchain designed to support decentralized applications

(DApps) and smart contracts.

Core Components

● Nodes: Maintain copies of the blockchain and validate transactions.

● Ethereum Virtual Machine (EVM): Executes Solidity smart contracts.
● Smart Contracts: Self-executing programs deployed on-chain.
● Consensus Mechanism: Proof-of-Stake (PoS) validates blocks and secures the network.
● Ether (ETH): Native cryptocurrency used for transaction fees and incentives.
Design Philosophy

● Open participation without central authority.

● Trustless operation among unknown participants.
● Maximum decentralization and transparency.
● Global accessibility and censorship resistance.
Hyperledger Fabric Architecture and Design Philosophy (3 Marks)

Hyperledger Fabric is a permissioned enterprise blockchain designed for business applications requiring
privacy and controlled access.

Core Components

● Peers: Host ledgers and execute chaincode.

● Ordering Service: Orders transactions and creates blocks.
● Chaincode: Business logic equivalent to smart contracts.
● Membership Service Provider (MSP): Manages identities and authentication.
● Channels: Enable private communication among selected organizations.
● World State Database: Stores current ledger data as key-value pairs.

Design Philosophy

● Identity-based participation.
● High performance and scalability.
● Fine-grained privacy controls.
● Consortium governance for enterprise collaboration.

Comparative Analysis (1 Mark)

Feature Ethereum Mainnet Hyperledger Fabric

Network Type Public Permissioned

Identity Pseudonymous Verified identities

Consensus Proof-of-Stake Raft/Kafka/BFT

Smart Contracts Solidity on EVM Chaincode (Go/Java/[Link])

Privacy Public ledger Channels and private data

Cryptocurrency Ether (ETH) No native cryptocurrency

Primary Use DApps and DeFi Enterprise solutions

c) Design a comprehensive enterprise asset-tracking Chaincode for a multi-organization Hyperledger Fabric
network, and formulate the complete end-to-end deployment lifecycle required to push this chaincode into
production across distributed peers. Design the following two core phases:
Phase 1: Architecture & Chaincode Design: Create a basic smart contract that manages the creation and
transfer of an asset. The design must demonstrate how asset data is stored as aKey-Value pair in the World
State database using Hyperledger Fabric's stub APIs (PutState and GetState). Additionally, the contract must
implement basic access control using the GetClientIdentity API to ensure that only the authorized creator
organization can initialize an asset.
Phase 1: Architecture & Chaincode Design

JavaScript Chaincode (4 Marks)

class AssetContract extends Contract {

// Create Asset
async CreateAsset(ctx, assetId, owner) {

const asset = {
assetId,
owner
};
await [Link](
assetId,
[Link]([Link](asset))
);
return "Asset Created";
}
// Read Asset
async ReadAsset(ctx, assetId) {
const asset = await [Link](assetId);
return [Link]();
}
// Transfer Asset
async TransferAsset(ctx, assetId, newOwner) {
const assetBytes =
await [Link](assetId);
const asset =
[Link]([Link]());
[Link] = newOwner;
await [Link](
assetId,
[Link]([Link](asset))
);
return "Asset Transferred";
}
}
[Link] = AssetContract;

Key APIs Used

 ● putState() → Stores asset in World State.
● getState() → Retrieves asset from World State.

Access Control using GetClientIdentity (1 Mark)

const mspId = [Link]();

if (mspId !== "Org1MSP") {

throw new Error(
"Only Org1 can create assets"
);
}

This ensures that only Org1 is authorized to initialize assets.

Phase 2: Decentralized Deployment Workflow: Systematically outline the exact operational steps with
commands required by network administrators to deploy this chaincode onto the network peers in
accordance with the Fabric v2.x/v3.x lifecycle governance model. Detail the sequence of executing the
four critical CLI steps: Packaging the chaincode into a .[Link] archive, Installing the package on specific
endorsing peers to generate a Package ID, Approving the chaincode definition by separate organizations
to meet the channel's lifecycle endorsement policy, and finally, Committing the chaincode definition to
the channel. Conclude by designing a validation test case using the peer chaincode invoke command to
prove that the deployed smart contract successfully interacts with the ledger across the distributed peer
topology.

Phase 2: Fabric Lifecycle Deployment Workflow (5 Marks) Explain each

step along with commands

Step 1: Package Chaincode

peer lifecycle chaincode package [Link] \
--path ./assetcc \
--lang node \
--label asset_1
Step 2: Install Chaincode
peer lifecycle chaincode install [Link] Retrieve
Package ID:
peer lifecycle chaincode queryinstalled Example Output:
Package ID: asset_1:abcd123456
Step 3: Approve Chaincode Definition
Org1:
peer lifecycle chaincode approveformyorg \
--channelID mychannel \
--name assetcc \
--version 1.0 \
--package-id asset_1:abcd123456 \
--sequence 1
Org2 executes the same approval command.
Step 4: Commit Chaincode
peer lifecycle chaincode commit \
--channelID mychannel \
--name assetcc \
--version 1.0 \
--sequence 1 Validation Test
Case Create Asset
peer chaincode invoke \
-C mychannel \
-n assetcc \
-c '{"Args":["CreateAsset",
"Asset001","Alice","50000"]}'
Transfer Asset
peer chaincode invoke \
-C mychannel \
-n assetcc \
-c '{"Args":["TransferAsset",
"Asset001","Bob"]}'
Query Asset
peer chaincode query \
-C mychannel \
-n assetcc \
-c '{"Args":["ReadAsset",
"Asset001"]}'
Expected Output
{
"assetId":"Asset001", "owner":"Bob",
"value":"50000"
}

The successful query from any authorized peer proves that the chaincode has been deployed correctly
and that ledger updates are synchronized across the distributed Hyperledger Fabric network.
2)
a) A mining pool secretly keeps its discovered blocks hidden to build a private chain, and
then releases them all at once to cancel out the blocks found by honest miners, analyze
how this "selfish mining" strategy works and its impact on the network.
Address the following points:
i) Explain step-by-step what happens to both the public chain and the attacker’s private
chain when a block is found.

i) Step-by-Step Working of Selfish Mining (4 Marks)

Selfish mining is a strategy where a mining pool withholds newly discovered blocks instead of immediately
broadcasting them to the network.

Step 1: Attacker Finds a Block

● Honest miners continue mining on the current public blockchain.

● The attacker discovers a block and keeps it private.

Public Chain : B0 Private Chain:

B0 → A1

Step 2: Attacker Mines Secretly

● While honest miners work on the public chain, the attacker continues mining on the hidden
chain.
● If another block is found by the attacker, the private chain grows.

Public Chain : B0

Private Chain: B0 → A1 → A2

Step 3: Honest Miner Finds a Block

● Honest miners discover a block and publish it.

Public Chain : B0 → H1 Private Chain:

B0 → A1 → A2

● The attacker still has a longer chain.

Step 4: Attacker Releases Hidden Chain

● The attacker broadcasts the private chain.

● Since blockchain nodes adopt the longest valid chain, the attacker's chain becomes the main
chain.

Accepted Chain:
 B0 → A1 → A2

Step 5: Honest Blocks Become Orphan Blocks

● Honest miners' block (H1) is discarded.

● Rewards earned by honest miners are lost.
● The attacker receives rewards for both A1 and A2.

ii) Explain the minimum percentage of network computing power a pool needs to possess
for this trick to actually earn them more rewards than honest mining.

(ii) Minimum Computing Power Required (1 Mark)

Let α represent the attacker's share of total network hash power.

● Selfish mining becomes profitable when the attacker controls approximately:

α > 25%

● With favorable network propagation delays, profitability may begin around 25–30%.
● Above 33% hash power, selfish mining consistently earns higher rewards than honest mining.
iii) Evaluate how this behavior hurts the blockchain network in the long run and what defense
mechanism can be taken to avoid this attack.

(iii) Impact on the Blockchain Network (2 Marks) Negative

Effects

1. Increased Orphan Blocks

○ Honest miners waste computational resources.
2. Reduced Fairness
○ Honest participants receive fewer rewards.
3. Mining Centralization
○ Small miners may join large pools to remain competitive.
4. Lower Network Security
○ Weakens trust in consensus mechanisms.
5. Potential for Further Attacks
○ May facilitate double-spending and majority-control attacks.
Defense Mechanisms (1 Mark)

1. Rapid Block Propagation

○ Reduces the advantage of hiding blocks.
2. Random Tie-Breaking
○ Nodes randomly select between competing chains of equal length.

b) An independent journalist receives donations via a public Bitcoin address published on their blog. As
Bitcoin relies on pseudo-anonymity, all transactions are linked to a single public key address. A hostile actor is
attempting to trace the journalist's real-world identity by analyzing the public ledger. Interpret the various
transaction analysis techniques the hostile actor could use to de-anonymize the journalist. For each technique,
describe a practical step the journalist could implement within their blockchain operations to mitigate the risk
and protect their privacy.

Bitcoin provides pseudo-anonymity, where users are identified by public addresses rather than real
names. However, because all transactions are publicly visible on the blockchain, a hostile actor can
analyze transaction patterns to link a user's address to their real-world identity.
Advanced privacy techniques such as Ring Signatures, Stealth Addresses, and
Zero-Knowledge Proofs (ZKPs) can significantly reduce this risk.

Transaction Analysis Techniques and Mitigation Strategies (4 marks)

Analysis How De-anonymization Occurs Privacy-Preserving Mitigation

Technique Used
by Attacker

Address Repeated use of the same donation Stealth Addresses generate a

Clustering address allows all incoming and unique one-time address for every
Analysis outgoing transactions to be linked donation, preventing linkage
together. between transactions.

Transaction The attacker traces the flow of funds Ring Signatures hide the true
Graph Analysis between addresses to identify sender among a group of possible
ownership patterns. signers, making transaction tracing
difficult.

Input Ownership Multiple inputs used in a transaction Ring Signatures obscure which
Analysis suggest common ownership of input actually authorized the
addresses. transaction.

Balance and Unique transaction amounts can Zero-Knowledge Proofs (ZKPs)

Amount reveal sender-recipient allow transaction validation
Tracking relationships. without revealing transaction
amounts.
 Donation-to-Spe Donations received at a public ZKPs conceal transaction details,
nding address are traced to exchanges or while Stealth Addresses prevent
Correlation merchants where identity direct linkage between received
verification exists. and spent funds.

Privacy Technologies (3 marks) Ring

Signatures

● A transaction is signed by a group (ring) of possible users.

● Observers can verify that one member signed the transaction but cannot determine which one.
● This hides the actual sender and prevents transaction graph analysis.

Benefit: Sender anonymity.

Stealth Addresses

● The journalist publishes a single public address.

● For every donation, a unique one-time receiving address is automatically generated.
● Outside observers cannot determine that multiple payments belong to the same recipient.

Benefit: Receiver anonymity.

Zero-Knowledge Proofs (ZKPs)

● Enable a transaction to be validated without revealing sensitive information.

● Transaction amount, sender, and recipient details remain hidden while still proving legitimacy.

Benefit: Transaction confidentiality.

A hostile actor can use address clustering, transaction graph analysis, and ownership analysis to de-
anonymize a journalist using a public Bitcoin address. To mitigate these threats, Stealth
Addresses hide recipient identities, Ring Signatures conceal transaction origins, and
Zero-Knowledge Proofs protect transaction details. Together, these techniques provide strong privacy
protection against blockchain-based surveillance and de-anonymization attacks.

c) An IoT smart meter transmits real-time consumption data to a blockchain to manage appliance states and
automate micro-payments, this analysis must assess the overall system architecture by critiquing the contract-
level state machine (Idle, Active, Suspended) to determine if locking device activation to a verified prepaid
balance securely prevents unauthorized access. Develop a smart contract for this scenario and appraise the
real-time data ingestion pipeline and judge whether an automated, intermediary-free micro-transaction
function can reliably execute an instantaneous device shutdown when the balance hits zero without triggering
network latency. Outline a machine-to-machine (M2M) cryptographic identity framework to establish trust,
validate the integrated system against data-tampering threats and justify the selection of distinct architectural
data layers to separate high-frequency usage tracking from final financial settlements.
Contract-Level State Machine Analysis (2 Marks)
The smart meter operates using three states:

Recharge

Idle ---------------- > Active

| Balance = 0 Suspended

| Recharge Active

Security Assessment

● Idle: Device registered but not consuming power.

● Active: Appliance operates only when prepaid balance exists.
● Suspended: Activated automatically when balance reaches zero.
Locking device activation to a verified prepaid balance prevents unauthorized usage because every state
transition is validated by the smart contract before appliance operation is allowed.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract SmartMeter {

enum State {Idle, Active, Suspended}

State public currentState;

uint public balance;

constructor() {
currentState = [Link];
}

function recharge() public payable {

balance += [Link];

if(balance > 0)
currentState = [Link];
}

function consumePower(uint units) public {

require(
currentState == [Link],
"Device inactive"
);

if(balance >= units) {

balance -= units;
}

if(balance == 0) {
currentState = [Link];
}
}

function getState()
public view returns(State)
{
return currentState;
}
}

Real-Time Data Ingestion Pipeline (2 Marks) Architecture

Smart Meter

IoT Gateway

MQTT Broker

Blockchain Oracle/API

Smart Contract

Blockchain Ledger

Evaluation

● Smart meter continuously records consumption.

● MQTT enables lightweight transmission.
● Gateway aggregates sensor readings.
● Oracle submits verified data to blockchain.
● Ledger maintains immutable billing records.

Advantage: Transparent and tamper-resistant monitoring.

Automated Micro-Payment and Instant Shutdown Analysis (1 Mark) Micro-

Payment Function

For every unit consumed:

Energy Usage → Balance Deduction → Ledger Update

Can Blockchain Perform Instant Shutdown? No, not

directly.

Reasons:

● Block creation delay.

● Network congestion.
● Consensus latency.

Recommended Solution

Local Edge Controller

Instant Device Shutdown

Blockchain

Financial Settlement

Thus, shutdown should occur locally while blockchain records payment settlement.

Machine-to-Machine (M2M) Cryptographic Identity Framework (1.5 Marks)

Each device possesses:

Public Key Private Key

Digital Certificate

Authentication Process

1. Smart meter signs usage data using private key.

2. Gateway verifies signature using public key.
3. Certificate Authority validates device identity.
4. Smart contract accepts data only from authenticated devices. This

establishes trust between machines without human intervention.

Data-Tampering Protection and Layered Architecture (1.5 Marks) Protection

Against Data Tampering

● Digital signatures ensure authenticity.

● Hash functions detect modifications.
● Immutable blockchain prevents record alteration.
● Certificate-based authentication blocks unauthorized devices.

Distinct Data Layers

Layer Purpose

Operational Layer High-frequency energy readings

Settlement Layer Payments and billing transactions

Architecture

Operational Layer

(MQTT / Time-Series DB)

↓ Aggregated Data

Settlement Layer (Blockchain

Ledger) Justification

● High-frequency sensor data is stored off-chain for scalability.

● Financial transactions are stored on-chain for security and auditability.
● Reduces blockchain storage overhead and network congestion.
 1. a. A group of 15 international hospitals and 5 pharmaceutical research firms want to create a
shared ledger to track patient clinical trial results. Data must be immutable, but patient privacy is
legally mandated. Only verified medical institutions should be allowed to validate transactions.
The system must handle 1,000 transactions per second (TPS) to log real-time biometric data.
Based on the 'Global HealthData Connect' scenario, identify and explain the most suitable type of
Distributed Ledger Technology (DLT).
Justify your choice by comparing it to other types of DLT, and discuss two technical challenges
and two real-world applications of this specific implementation.

1. Identification (1 Mark)
● Target DLT: Consortium (or Federated) Blockchain.
● Core Definition: A semi-private, multi-party ledger where the consensus process is controlled by a pre-
defined set of nodes (the 15 hospitals and 5 firms).

2. Justification & Comparison (3 Marks)

To justify this choice, compare it against the other primary DLT types based on the "Global HealthData
Connect" requirements:
● Public Blockchain (Rejected): While immutable, it is fully transparent and open to anyone. This fails
the legal privacy mandate for patient data and the requirement that only verified institutions validate
transactions.
● Private Blockchain (Rejected): These are usually centralized under one organization. Since this
involves 20 distinct international entities, a private chain would centralize too much power, whereas a
Consortium allows for shared governance.
● Consortium Advantage (Accepted): It provides the "middle ground." It allows for high TPS (1,000)
because the network uses lightweight consensus (like PBFT) instead of heavy mining, and it ensures
only the 20 verified members can see or validate clinical data.

3. Two Technical Challenges (2 Marks)

Address the difficulties of implementing this specific health-tech system:
● Interoperability: The 20 different organizations likely use different Electronic Health Record (EHR)
formats. Syncing this data into a single "shared ledger" requires complex standardization.
● Data Volume & Scalability: Logging "real-time biometric data" at 1,000 TPS creates massive storage
requirements. The challenge is keeping the ledger performant without it becoming too large for the
nodes to store.

4. Two Real-World Applications (2 Marks)

Provide examples of where this specific DLT implementation is used:
● Pharmaceutical Supply Chain: Tracking the provenance of drugs (e.g., MediLedger) where only
manufacturers, wholesalers, and hospitals are allowed to validate the movement of medicine.
● Inter-bank Financial Settlements: Platforms like R3 Corda, where a group of pre-verified banks
settle transactions privately and instantly without a central clearinghouse.

b. A Fintech company is launching a 'Sovereign Wealth' app. They have decided to use a blockchain
wallet. To ensure user privacy, the app must generate a unique Base58 Bitcoin Address for every
transaction without requiring the user to perform multiple backups. Analyze the steps involved in
generating a wallet address from a private key. Compare and contrast the different types of wallets
available.
1. Analysis: Steps to Generate a Bitcoin Address (4 Marks)
Generating a Base58 address from a private key involves a series of cryptographic one-way functions:

Step 1: Private Key to Public Key The process begins with a 256-bit random number (Private Key). This is
transformed into a Public Key using Elliptic Curve Cryptography (ECC), specifically the secp256k1 curve.

Step 2: Double Hashing To create a shorter, secure identifier, the Public Key undergoes two rounds of
hashing: first with SHA-256, and then the result is hashed with RIPEMD-160. This produces a 160-bit "Public
Key Hash."
Step 3: Adding Version Byte & Checksum A network version byte (e.g., 0x00 for Bitcoin Mainnet) is added
to the front. A checksum is then calculated by hashing this string twice with SHA-256 and taking the first 4
bytes of the result to prevent typing errors.
Step 4: Base58Check Encoding The version, hash, and checksum are converted into a Base58 string. This
format excludes visually ambiguous characters (like 0, O, I, and l) to ensure the address is user-friendly and
error-resistant.
Comparison (3 Marks)

Wallet Type Backup Requirement Privacy & Functionality

Hot Wallets Online/Software based. High convenience for daily app use but
higher risk of being hacked.

Cold Wallets Offline/Hardware based. Maximum security (air-gapped) but less

practical for a real-time mobile Fintech app.

c. A blockchain is a multi-layered architecture designed to create 'Trust without a Central Authority.' Analyze the
core functions of this architecture by answering the following:
i. Define a Full Client and a Lightweight (SPV) Client. Which one provides the highest level of security, and which
one is more practical for a shop counter? (3Marks)
ii. Describe the role and structure of the Block Header and Merkle tree. Explain how the inclusion of the Previous
Block Hash and the Merkle Root ensures that once data is written, it is both immutable and easy to
verify. (3 Marks)
iii. Discuss the process of Mining within a Distributed P2P Network. Interpret the various elements of the Contract
layer with suitable examples. (4 Marks)

Full Client vs. Lightweight (SPV) Client (3 Marks)

● Full Client: A node that downloads and stores the entire history of the blockchain (every block and
transaction) and independently validates all rules of the network.
● Lightweight (SPV) Client: Simplified Payment Verification clients that do not store the whole chain;
they only download Block Headers and use Merkle proofs to verify that a transaction is included in a
block.
● Security & Practicality:
○ Highest Security: The Full Client provides the highest security because it does not rely on third
parties for verification.
 ○ Shop Counter Practicality: The Lightweight (SPV) Client is more practical for a shop counter
because it requires significantly less storage and bandwidth, allowing it to run on mobile devices
or tablets for quick transaction checks.

ii. Block Header, Merkle Tree, and Immutability (3 Marks)

● Block Header: Contains metadata about the block, including the version, Previous Block Hash,
Merkle Root, Timestamp, Difficulty Target, and Nonce.
● Merkle Tree: A binary tree of hashes where each leaf node is a transaction hash and every non-leaf
node is the hash of its children.
● Immutability and Verification:
○ Previous Block Hash: By including the hash of the preceding block, blocks are
cryptographically linked in a chain. Changing data in Block A changes its hash, which breaks the
link in Block B, making tampering immediately evident.
○ Merkle Root: This single hash represents all transactions in a block. It allows for easy
verification because a user only needs a small "Merkle Path" to prove a transaction's existence
without downloading the entire block data.

iii. Mining and the Contract Layer (4 Marks)

● Mining in a P2P Network:

○ Mining is the process where decentralized nodes compete to solve a cryptographic puzzle (Proof
of Work) to validate a new batch of transactions.
○ In a Distributed P2P network, once a miner finds a valid nonce, the block is broadcasted to all
peers, who verify it and append it to their local ledgers, ensuring global consensus without a
central authority.
● Contract Layer Elements:
○ This layer consists of the scripts, algorithms, and Smart Contracts that define the rules of
transaction execution.

The Contract Layer handles the rules of the system through three main elements:

● Scripts: Simple instructions used to "lock" or "unlock" funds.

● Algorithms: Mathematical rules, such as difficulty adjustments or consensus logic.
● Smart Contracts: Programmable, self-executing agreements (e.g., Ethereum) that automate
complex tasks.
2. a. The developers of a popular blockchain want to update the network. One group wants to change the
rules so that the 'Block Size' decreases (a more restrictive rule). Another group wants to change the
fundamental signature algorithm, making it completely incompatible with the old software. The
community is divided on which path to take. Illustrate the technical implications of these updates by
answering the following:
i) Explain what a Soft Fork is. Why is it considered 'Backward Compatible', and how does it affect
nodes that do not upgrade their software
immediately? (4 Marks)
ii) Describe a Hard Fork. Why does this result in a permanent divergence of the blockchain, and
what happens to the 'Legacy' (old) nodes? (4 Marks)
Soft Fork (4 Marks)

● Definition: A soft fork is a software upgrade that is backward-compatible, meaning the new rules are
more restrictive than the old rules.
● Backward Compatibility: It is considered backward-compatible because blocks created by upgraded
nodes (following the new, tighter rules) are still seen as valid by non-upgraded nodes. For example, if
the 'Block Size' decreases from 2MB to 1MB, a 1MB block is valid under both the old and new
software.
● Effect on Non-Upgraded Nodes:
○ Nodes that do not upgrade immediately will still stay on the same chain and accept new blocks.
○ However, if a non-upgraded node tries to mine a block that violates the new, tighter rules (e.g., a
1.5MB block), the upgraded majority of the network will reject it.
○ This encourages non-upgraded nodes to eventually update to avoid wasting computational power
on rejected blocks.

ii. Hard Fork (4 Marks)

● Definition: A hard fork is a software update that is not backward-compatible because it introduces
fundamental changes, such as a new signature algorithm.
● Permanent Divergence: It results in a permanent split because the new rules are so different that blocks
produced by upgraded nodes are considered invalid by old software, and vice versa. The blockchain
splits into two separate paths: the original chain and the new chain.
● Fate of 'Legacy' (Old) Nodes:
○ Legacy nodes continue to follow the old set of rules, completely ignoring the new chain.
○ Unless all nodes upgrade (a "planned" hard fork), the network permanently splits into two
independent blockchains with their own transaction histories and potentially their own tokens
(e.g., Bitcoin vs. Bitcoin Cash).
○ Legacy nodes cannot see or verify transactions happening on the new chain, and new nodes
cannot verify transactions on the legacy chain.

b. A private college consortium wants to move away from the high electricity costs of Bitcoin's Proof of
Work. They decided to implement Proof of Elapsed Time (PoET) using Intel SGX (Software Guard
Extensions). Analyze the technical workflow of this system. Also, explain how the 'Trusted Execution
Environment' (Enclave) inside the processor ensures that a node cannot cheat the random timer.
1. Technical Workflow of PoET (5 Marks)

The workflow of PoET replaces the energy-intensive "mining" of Bitcoin with a randomized waiting system:

● Step 1: Joining the Network: Every participating node in the college consortium must initialize a
Trusted Execution Environment (TEE) using Intel SGX to prove they are running legitimate code.
● Step 2: Requesting a Wait Time: When a new block needs to be created, each node requests a random
wait time from its local "Enclave".
● Step 3: The Waiting Phase: Each node goes into a sleep/wait state for the specific duration assigned to
it (e.g., Node A waits 5 minutes, Node B waits 2 minutes).
● Step 4: Block Generation: The first node to wake up (the one with the shortest random wait time)
creates the block and broadcasts it to the network.
 ● Step 5: Validation: Other nodes verify that the winner actually waited for the assigned time by
checking a signed certificate generated by the Enclave.

2. Role of the Trusted Execution Environment (Enclave) (3 Marks)

The Intel SGX Enclave is a hardware-secured area of the processor that ensures no node can "cheat" the timer:

● Isolation: The Enclave is an isolated memory region that is invisible to the rest of the Operating System
or even a user with "root" access. This prevents the node owner from manually changing the timer value.
● Secure Randomness: The random wait time is generated inside the Enclave using a hardware-based
random number generator. Since the code is sealed, the node cannot "request" a shorter time or
repeatedly request times until it gets a low one.
● Attestation: Once the timer expires, the Enclave produces an Attestation Report (a digital signature).
This serves as cryptographic proof to the rest of the consortium that the node waited for the correct
amount of time and did not bypass the protocol.

c. AlphaChain uses a 10-digit hashing system (0-9). The "Target" adjusts every 100 blocks to maintain a
5-minute block time. Propose solutions for given problems.

i) On average, how many nonces must be tested to find a hash starting with a single 0? If the requirement
changes from one to three zeros, by what factor has the difficulty increased? Describe the use of a nonce
in PoW. (3 marks)

ii) The total hash range is 0–5,000. Target X: 2,500, Target Y: 25. Which Target is harder to solve?
Illustrate with an example (2 marks)

iii) If a transaction in Block 50 is altered, what happens to its hash? Explain why the attacker must then
re-mine Block 50 ,51, 52, etc. to maintain a valid chain. Demonstrate this
scenario. (3marks) iv) If new
high-speed miners cause blocks to be found every 30 seconds (instead of 5 minutes): Does the network
move the Target number Up or Down? Explain the logic of this adjustment. (2
marks)

Nonces and Difficulty Scaling (3 Marks)

● Single Zero Calculation: In a 10-digit system (0-9), the probability of the first digit being a 0 is 1/10.
On average, 10 nonces must be tested to find a successful hash.
● Three Zeros Calculation: The probability of the first three digits being 000 is (1/10) x (1/10) x (1/10) =
1/1,000.
● Difficulty Factor: The difficulty has increased from 10 to 1,000, which is a factor of 100.
● Role of Nonce: A nonce ("number used once") is a random value that miners change iteratively to alter
the block's hash output until it meets the network's target requirement.

ii. Target Comparison (2 Marks)

● Harder Target: Target Y (25) is significantly harder to solve than Target X (2,500).
● Explanation: In PoW, a valid hash must be less than or equal to the target.
● Illustration: With Target X, any random number between 0 and 2,500 works (50% of the total range).
With Target Y, only numbers between 0 and 25 work (0.5% of the total range), making it 100 times
harder to find a winning hash.
iii. Block Alteration and Re-mining (3 Marks)
● Effect on Hash: If a transaction in Block 50 is altered, its unique hash changes immediately due to the
avalanche effect.
● Chain Reaction: Because Block 51 contains the "Previous Block Hash" of Block 50 in its header, Block
51's hash also becomes invalid. This creates a broken link that propagates through all subsequent blocks
(52, 53, etc.).
● Demonstration: To make the chain valid again, an attacker must re-calculate the Proof of Work (find
new nonces) for Block 50 and all following blocks faster than the rest of the network can add new ones.

iv. Target Adjustment Logic (2 Marks)

● Direction: The network moves the Target number Down.
● Logic: A lower Target number reduces the range of "winning" hashes, making the mathematical puzzle
harder to solve. By increasing the difficulty, the network forces the high-speed miners to take more time,
pushing the 30-second block time back up to the desired 5-minute average.

Explain the advantages and disadvantages of Proof of work ,proof of stake , and PBFT consensus
algorithms.

Based on your comparison, which consensus algorithm would you choose for your blockchain network,
and why?

Comparison of Proof of Work (PoW), Proof of Stake (PoS), and PBFT Consensus Algorithms
1. Proof of Work (PoW)
What is PoW?
Proof of Work is a consensus mechanism where miners solve complex mathematical puzzles to validate
transactions and create new blocks. The first miner to solve the puzzle gets the right to add the block to the
blockchain and receives a reward. It is used in cryptocurrencies like Bitcoin.
Advantages of PoW
1. High Security
• PoW makes it extremely difficult for attackers to manipulate the blockchain.
• An attacker must control more than 50% of the network's computing power.
• This requirement provides strong protection against fraud and double-spending.
2. Decentralization
• Anyone with mining hardware can participate in the consensus process.
• No central authority controls transaction validation.
• This promotes fairness and trust among network participants.
3. Proven Reliability
• PoW has been successfully used for many years in blockchain networks.
• It has demonstrated strong resistance to attacks.
• Its reliability makes it one of the most trusted consensus mechanisms.
Disadvantages of PoW
1. High Energy Consumption
• Mining requires powerful computers that consume large amounts of electricity.
• This increases operational costs for miners.
• It also raises environmental concerns.
2. Slow Transaction Processing
• Solving cryptographic puzzles takes time.
• Transactions may require several confirmations before becoming final.
• This reduces the overall transaction speed of the network.
3. Expensive Hardware Requirements
• Specialized mining devices are often needed.
• Small participants may struggle to compete with large mining farms.
• This can lead to mining centralization.
2. Proof of Stake (PoS)
What is PoS?
Proof of Stake selects validators based on the amount of cryptocurrency they lock or "stake" in the network.
Validators confirm transactions and create new blocks according to their stake. It is a more energy-efficient
alternative to PoW.
Advantages of PoS
1. Energy Efficient
• PoS does not require solving computational puzzles.
• Validators only need to keep their systems online.
• This significantly reduces electricity consumption.
2. Faster Transactions
• Block validation occurs more quickly than in PoW.
• The network can process a larger number of transactions.
• Users experience faster confirmation times.
3. Lower Operational Costs
• Expensive mining equipment is not required.
• Participation is possible with standard computing devices.
• This reduces maintenance and infrastructure costs.
Disadvantages of PoS
1. Wealth Concentration
• Participants with larger stakes have greater influence.
• Rich validators may receive more rewards over time.
• This can create unequal power distribution.
2. Security Concerns
• Validators may attempt to validate multiple competing chains.
• Additional mechanisms are needed to discourage dishonest behavior.
• Improper implementation can affect security.
3. Dependency on Token Ownership
• Consensus power depends on the amount of cryptocurrency owned.
• New users may find it difficult to gain influence.
• Large stakeholders can dominate decision-making.
3. Practical Byzantine Fault Tolerance (PBFT)
What is PBFT?
Practical Byzantine Fault Tolerance is a consensus algorithm designed to handle faulty or malicious nodes in a
distributed system. Nodes communicate with each other and vote on the validity of transactions. It is commonly
used in permissioned blockchain networks.
Advantages of PBFT
1. Instant Finality
• Once a transaction is approved, it becomes permanent immediately.
• No additional confirmations are required.
• This eliminates the possibility of transaction reversal.
2. High Transaction Speed
• PBFT processes transactions much faster than PoW and PoS.
• Consensus is achieved through communication among nodes.
• It is suitable for applications requiring real-time processing.
3. Low Energy Consumption
 • PBFT does not involve mining or staking.
• Nodes only exchange messages to reach consensus.
• This makes it highly energy-efficient.
Disadvantages of PBFT
1. Limited Scalability
• Communication between nodes increases rapidly as the network grows.
• Performance decreases with a large number of participants.
• It is not suitable for very large public blockchains.
2. Complex Communication
• Nodes must exchange multiple messages during consensus.
• Network management becomes more complicated.
• Increased communication overhead can affect efficiency.
3. Requires Trusted Participants
• PBFT works best in permissioned environments.
• Participants are usually known and verified.
• It is less suitable for completely open public networks.
Comparison Table
Feature PoW PoS PBFT
Security Very High High High
Energy Consumption Very High Low Very Low
Transaction Speed Slow Fast Very Fast
Scalability Moderate Good Limited
Cost High Low Low
Finality Delayed Faster Instant
Best For Public Blockchains Modern Public Blockchains Private/Permissioned Blockchains

Which Consensus Algorithm Would I Choose and Why?

Choice: Proof of Stake (PoS)
Reason 1: Energy Efficiency
• PoS consumes significantly less electricity than PoW.
• It eliminates the need for expensive mining operations.
• This makes the blockchain environmentally sustainable.
Reason 2: Better Scalability
• PoS supports higher transaction throughput.
• It can handle growing numbers of users more efficiently.
• This makes it suitable for large-scale blockchain applications.
Reason 3: Faster Transaction Processing
• Transactions are confirmed more quickly than in PoW.
• Users receive better performance and reduced waiting times.
• This improves the overall user experience.
Reason 4: Lower Cost
• No specialized mining hardware is required.
• Operating and maintenance expenses are reduced.
• More participants can join the network economically.
PoS Question 1
Question
In Bitcoin (PoW), a block is never "100% final"—it just becomes very unlikely to change after 6 blocks. In
many PoS systems, blocks become "Finalized" and can never be changed.
If a PoS network requires 2/3 of all stakers to agree on a block for it to be finalized:
i) If a group of bad validators owns 34% of the coins, can they finalize a fake block?
Given
• Required approval = 2/3 (66.67%)
• Bad validators = 34%
Content
No, the bad validators cannot finalize a fake block. To finalize a block, at least two-thirds of the total stake must
approve it. Since the malicious validators control only 34% of the stake, they do not have enough voting power
to reach the required threshold. They can vote for a fake block, but without support from honest validators, the
block cannot be finalized.
Question
ii) Can they stop the network from finalizing any new blocks?
Given
• Honest validators = 66%
• Malicious validators = 34%
• Finalization requires 66.67%
Content
Yes, they can potentially stop finalization. Since finalization requires more than two-thirds agreement, the
malicious validators can refuse to vote. This leaves only 66% of the stake participating, which is slightly below
the required 66.67%. As a result, blocks may not receive enough approvals to become finalized, causing the
network to stall.
PoS Question 2
Question
A validator receives a 5% annual reward. There is an offline penalty of 0.01% per hour.
i) If Validator C is offline for 48 hours, how much stake is lost?
Given
• Offline penalty = 0.01% per hour
• Offline time = 48 hours
Content
The total penalty is calculated by multiplying the hourly penalty by the number of hours offline.
48×0.01%=0.48%48 \times 0.01\% = 0.48\%48×0.01%=0.48%
Validator C loses 0.48% of the staked amount. This penalty is deducted because the validator was unavailable
to participate in consensus during that period.
Question
ii) Does Validator C still make a profit?
Given
• Annual reward = 5%
• Penalty = 0.48%
Content
Yes, Validator C still makes a profit. The annual reward is 5%, while the total penalty is only 0.48%.
5%−0.48%=4.52%5\% - 0.48\% = 4.52\%5%−0.48%=4.52%
After deducting the penalty, Validator C still earns a net gain of 4.52%, meaning staking remains profitable
despite the temporary outage.
PoS Question 3
Question
There are four validators:
 • V1 = 40 coins
• V2 = 30 coins
• V3 = 20 coins
• V4 = 10 coins
A block is valid only if validators representing at least 61 coins sign it.
i) Can V1 and V2 pass a block by themselves?
Given
• V1 = 40
• V2 = 30
• Required = 61
Content
Yes, V1 and V2 can pass a block by themselves.
40+30=7040 + 30 = 7040+30=70
Since 70 coins represent more than the required 61 coins, they satisfy the validation requirement. Therefore, a
block signed by V1 and V2 is considered valid.

Question
ii) If V1 goes offline, what is the minimum number of validators needed to keep the network running?
Given
• V2 = 30
• V3 = 20
• V4 = 10
• Required = 61
Content
If V1 is offline, the remaining validators have:
30+20+10=6030 + 20 + 10 = 6030+20+10=60
The network requires 61 coins for validation, but only 60 coins remain available. Therefore, even if all three
remaining validators work together, they cannot reach the required threshold.
As a result, the network cannot continue validating blocks until V1 comes back online or the validation
threshold is changed.

PoET Question 1
Question
In PoET, every node requests a wait time from its secure hardware. The node with the shortest wait time wins
the right to forge the next block.
Imagine a network with 100 nodes.
• Node A is a massive supercomputer with 128 CPU cores.
• Node B is a simple laptop with a single 4-core processor.
• Both nodes have the same Intel SGX security hardware.
i) Does Node A have a higher statistical chance of winning the next block than Node B?
Given
• Node A = 128 CPU cores
• Node B = 4 CPU cores
• Both use the same Intel SGX hardware
Content
No, Node A does not have a higher chance of winning than Node B. In PoET, block selection is based on a
randomly generated waiting time provided by the Trusted Execution Environment (TEE), such as Intel SGX.
The number of CPU cores or processing power does not affect the waiting time. Since both nodes use the same
trusted hardware, they have an equal probability of receiving the shortest wait time. Therefore, both nodes have
the same statistical chance of creating the next block.
Question
ii) If Node A tries to "speed up" its internal clock to make 10 seconds pass in only 5 seconds, why will the
rest of the network reject its block?
Given
• Assigned wait time = 10 seconds
• Node A attempts to finish in 5 seconds
Content
The network will reject the block because the waiting time is monitored and verified by Intel SGX. The Trusted
Execution Environment generates a certificate proving that the assigned waiting period was actually completed.
Even if Node A manipulates its local clock, the SGX hardware records the true elapsed time. When other nodes
verify the certificate, they will detect that the required waiting period was not completed correctly. As a result,
the certificate becomes invalid and the block is rejected.
PoET Question 2
Question
When a node's timer expires, the secure hardware generates a Certificate proving the time actually elapsed.
An attacker discovers a way to pause their secure hardware right before the timer ends. They wait until the
network is at a very high traffic moment, unpause it, and immediately broadcast a winning certificate they
generated for a block that was supposed to be mined 30 minutes ago.
i) Why must a PoET certificate be tied to a specific Block Hash (the most recent block)?
Given
• Certificate generated earlier
• Blockchain state changes continuously
Content
A PoET certificate must be tied to a specific block hash to ensure that it can only be used for the current state of
the blockchain. Every new block changes the blockchain's history and creates a new block hash. If certificates
were not linked to the latest block hash, attackers could store old certificates and reuse them later. By binding
the certificate to the most recent block hash, the network ensures that old certificates become invalid whenever
the blockchain advances.
Question
ii) If the attacker provides a valid certificate showing they waited 10 seconds, but that certificate was
generated based on the Previous Block Hash from an hour ago, will the network accept it? Why or why
not?
Given
• Certificate proves 10-second wait
• Certificate linked to block hash from one hour ago
Content
No, the network will not accept the certificate. Although the certificate proves that the node waited for the
required amount of time, it is tied to an outdated block hash. Since the blockchain has already produced many
new blocks, the current block hash is different from the one stored in the certificate. During verification, nodes
compare the certificate's block hash with the latest blockchain state. Because they do not match, the certificate
is considered invalid and the block is rejected.
PoET Question 3
Question
PoET is highly efficient, but it has one major Achilles' heel: it requires specific hardware such as Intel SGX to
create the Trusted Execution Environment (TEE).
i) If the network requires every node to update their hardware microcode to fix a security flaw, but 30%
of the miners are using older chips that cannot be updated, what happens to decentralization if those
30% are kicked off?
Given
• 30% of nodes removed
 • Only updated nodes remain
Content
The network becomes less decentralized. Decentralization means that control is distributed among many
independent participants. When 30% of the validators are removed, fewer participants remain to validate
transactions and produce blocks. This increases the influence of the remaining validators and concentrates
power among a smaller group. As a result, the blockchain becomes more centralized and more vulnerable to
control by a few organizations.
Question
ii) In Proof of Work, anyone can build an ASIC. In Proof of Stake, anyone can buy coins. In PoET, you
must buy hardware from a specific company. If that company secretly hardcodes a rule into its chips that
gives its own nodes a slightly shorter timer, how would the blockchain ever find out?
Given
• Hardware manufacturer controls the TEE
• Secret advantage built into chips
Content
Detecting such manipulation would be extremely difficult because PoET relies on trusting the hardware
manufacturer. The internal operations of Intel SGX are not fully visible to the blockchain network. If the
company secretly gives its own devices slightly shorter waiting times, the network may only notice unusual
patterns, such as certain nodes winning blocks much more frequently than expected. However, proving that the
hardware contains a hidden advantage would require independent security audits and hardware analysis. This
dependence on a specific manufacturer is one of the major criticisms of PoET because it introduces a level of
trust that does not exist in PoW or PoS.

PoB Question 1
Question
In Proof of Burn, your mining power isn't permanent. Most PoB systems use a Decay Function where Effective
Burn Power drops by 50% every year.
• Miner A burns 100 coins on January 1st, 2026.
• Miner B burns 60 coins on January 1st, 2027.
i) On January 1st, 2027 (exactly one year later), which miner has more power in the network?
Given
• Miner A burned 100 coins in 2026
• Burn power decays by 50% per year
• Miner B burned 60 coins in 2027
Content
After one year, Miner A's effective burn power decreases by 50%.
100×0.5=50100 \times 0.5 = 50100×0.5=50
Therefore, Miner A now has 50 units of effective burn power.
Miner B has just burned 60 coins, so their effective burn power is 60.
Since:
60>5060 > 5060>50
Miner B has more mining power than Miner A on January 1st, 2027. Even though Miner A burned more coins
initially, the decay function reduces their influence over time.
Question
ii) Why is this decay necessary to prevent the Early Adopter Monopoly?
Given
• Burn power decreases by 50% every year
Content
The decay mechanism prevents early participants from controlling the network forever. Without decay, a user
who burned a large number of coins in the early stages would permanently maintain the highest mining power.
New participants would have little chance of competing. By gradually reducing burn power over time, the
network allows new users to gain influence and participate fairly in block creation. This helps maintain
decentralization and prevents long-term monopolies.
PoB Question 2
Question
PoB is often used to transition from an old blockchain to a new blockchain.
To receive coins on Chain B, users must send their Chain A coins to a Burn Address.
i) If the Burn Address is just a public wallet where the private key has been deleted, how does Chain B
know that you actually burned the coins?
Given
• Coins sent to Burn Address
• Burn transaction recorded on blockchain
Content
Chain B verifies the burn by checking the blockchain records of Chain A. Every transaction on a blockchain is
public and permanent. When a user sends coins to the burn address, the transaction becomes part of the
blockchain history. The software on Chain B scans Chain A and verifies that the coins were transferred to the
designated burn address. Once verified, Chain B rewards the user with new coins according to the migration
rules.
Question
ii) If an attacker finds the private key to the Burn Address 5 years later, does the Proof of Burn security
break?
Given
• Coins were already burned
• Burn transaction permanently recorded
Content
No, the Proof of Burn process does not break. The important factor is not whether the coins physically
disappear, but whether the network accepted the burn transaction as proof of commitment. Once the burn
transaction is recorded and verified on the blockchain, the participant has already received the associated
benefits. Even if someone later gains access to the burn address, it does not change the historical record that the
coins were originally burned. The blockchain's proof remains valid because the evidence of burning is
permanently stored.
PoB Question 3
Question
PoB is often compared to PoW.
Scenario PoW
You spend $1000 on electricity to mine 1 Bitcoin.
Scenario PoB
You burn $1000 worth of Coin X to mine 1 Bitcoin.
i) In a market crash where Coin X loses 90% of its value, which miner is in a worse position?
Given
• Coin X drops by 90%
• PoW miner spent electricity
• PoB miner burned Coin X
Content
The PoB miner is in a worse position. The PoW miner spent money on electricity, and that cost is already fixed
and completed. However, the PoB miner permanently destroyed valuable coins. If Coin X later experiences a
dramatic price increase or recovery, the burned coins can never be recovered. The miner loses both the original
investment and any future value those coins might have gained. Therefore, the financial risk is greater for the
PoB miner.
Question
ii) Why is PoB considered greener than PoW, but riskier for the miner's personal balance sheet?
Given
• PoW uses electricity
• PoB destroys cryptocurrency
Content
PoB is considered greener because it does not require massive computational power, mining farms, or
continuous electricity consumption. Instead of solving complex mathematical puzzles, participants prove
commitment by destroying coins. This significantly reduces energy usage and environmental impact.
However, PoB is riskier for the miner because the sacrificed coins are permanently lost. If the value of those
coins increases in the future, the miner cannot recover them. In PoW, electricity costs are consumed
immediately, but in PoB, valuable assets are intentionally destroyed. Therefore, while PoB is environmentally
friendly, it exposes participants to greater financial risk.

Exercise 1: The "Digital DNA" (Recovery)

Question
How are Account addresses generated using the Mnemonic?
Given
• Ganache provides a 12-word mnemonic.
• MetaMask imports the same mnemonic.
• Additional accounts are created using "Create Account".
Answer
The mnemonic acts as the root seed of the wallet. When the 12-word mnemonic is entered into MetaMask, it is
converted into a cryptographic seed. From this seed, multiple private keys are generated using the Hierarchical
Deterministic (HD) wallet algorithm. Each private key produces a unique public key and Ethereum address.
Since both Ganache and MetaMask use the same mnemonic and derivation path, they generate exactly the same
wallet addresses. This proves deterministic wallet generation, where the same mnemonic always produces the
same set of accounts.
Question
What happens when you forget the Mnemonic?
Given
• Mnemonic is the wallet backup.
• All accounts are derived from the mnemonic.
Answer
The mnemonic is the most important recovery mechanism of the wallet. If the mnemonic is forgotten or lost, the
wallet cannot be restored on another device. Since all private keys are derived from the mnemonic, losing it
means losing access to all wallet accounts. The user will not be able to recover the private keys or access the
funds stored in those accounts. Therefore, the mnemonic must be stored securely because it serves as the digital
identity of the entire wallet.
Exercise 2: The "Ghost Transaction" (Nonce Sync)
Question
Why does MetaMask hang or show an error after Ganache is restarted?
Given
• Two transactions were sent before restart.
• Ganache restart resets blockchain to Block 0.
• MetaMask still remembers previous transaction history.
Answer
When Ganache is restarted, the blockchain is completely reset to Block 0 and all previous transaction records
are erased. However, MetaMask still remembers the old transaction count (nonce) from before the restart. A
nonce is a sequential number assigned to every transaction from an account. Since MetaMask expects the next
transaction to use a higher nonce while Ganache expects the nonce to start again from zero, a mismatch occurs.
This causes MetaMask transactions to remain pending, fail, or display errors. This phenomenon is known as a
nonce synchronization problem because the wallet and blockchain are no longer synchronized.
Exercise 3: The "Gas War" (Priority)
Question
Why does a transaction remain pending when the gas fee is set to 5 Gwei while Ganache requires 20 Gwei?
Given
• Ganache fixed gas price = 20 Gwei.
• Transaction gas price = 5 Gwei.
• Transaction submitted successfully.
Answer
The transaction remains pending because its gas fee is lower than the minimum gas fee expected by the
network. Miners always prioritize transactions that provide higher rewards because transaction fees contribute
to their earnings. Since the transaction offers only 5 Gwei while the network expects 20 Gwei, it receives a
lower priority. As a result, the transaction is placed in the mempool, which acts as a waiting area for
unconfirmed transactions. The transaction stays there until a miner chooses to process it or network conditions
change. This demonstrates how gas prices directly influence transaction priority in blockchain networks.
Question
What triggers the transaction to stay pending?
Given
• Gas fee is below network requirement.
• Transaction enters mempool.
Answer
The transaction remains pending due to three major reasons. First, the gas fee is lower than the required network
gas price, making it less attractive for miners. Second, miners are economically motivated and prefer
transactions that provide higher rewards. Third, blockchain transactions enter the mempool before being mined,
and only transactions selected by miners are included in blocks. Because this transaction offers a low fee, it
remains in the mempool and is ignored until it becomes profitable to process.
Exercise 4: The "Mempool" Congestion (Bottlenecking)
Question
Did all 5 transactions go into one block or five separate blocks?
Given
• Mining mode = Manual.
• Five transactions sent quickly.
• Mine button clicked once.
Answer
All five transactions were included in a single block. When manual mining is enabled, transactions are not
processed immediately. Instead, they accumulate in the mempool and remain in a pending state. Once the Mine
button is clicked, Ganache collects all pending transactions and packages them into one block. Because only
one mining event occurred, the block height increased by one instead of five. This demonstrates the concept of
batching, where multiple transactions are grouped together and processed simultaneously in a single block.
Question
How does batching work in a blockchain?
Given
• Multiple pending transactions exist.
• One mining event occurs.
Answer
Batching is the process of combining multiple transactions into a single block before adding that block to the
blockchain. Instead of creating a separate block for every transaction, the miner gathers several pending
transactions from the mempool and includes them together. This reduces the number of blocks required,
improves network efficiency, and minimizes blockchain growth. In the experiment, all five pending transactions
were processed together when a single block was mined, clearly demonstrating how batching increases
throughput and reduces overhead.
Exercise 5: The Gas Price and Mining Link
Question
If five transactions have different gas prices and the block gas limit allows only three transactions, which
transactions will Ganache select?
Given
Example gas prices:
• Transaction 1 = 5 Gwei
• Transaction 2 = 10 Gwei
• Transaction 3 = 15 Gwei
• Transaction 4 = 20 Gwei
• Transaction 5 = 25 Gwei
Block gas limit allows only three transactions.
Answer
Ganache will select the three transactions with the highest gas prices because miners aim to maximize their
rewards. In this example, the transactions with 25 Gwei, 20 Gwei, and 15 Gwei would be included in the block
first. The transactions with 10 Gwei and 5 Gwei would remain in the mempool waiting for future blocks. This
behavior reflects the fee-based priority system used in blockchain networks, where higher-paying transactions
receive preference over lower-paying ones.
Question
Why does this happen?
Given
• Block size is limited.
• Transactions have different gas prices.
Answer
This occurs because miners are incentivized to maximize their earnings from transaction fees. Since a block has
limited capacity, not all pending transactions can be included at once. Therefore, miners prioritize transactions
that offer higher gas prices because they provide greater rewards. Transactions with lower fees remain in the
mempool until sufficient block space becomes available. This mechanism ensures efficient utilization of block
space while encouraging users to offer competitive fees for faster transaction confirmation.

1. Decentralized Blind Auction

Question
Create an auction where bids are hidden until the bidding period ends to prevent bid sniping.
Given
• commit() function
• reveal() function
• withdraw() function
• Hash generated using keccak256()
Commit Function
function commit(uint _value, string memory _secret) public payable {
bytes32 hash = keccak256(
[Link](_value, _secret)
);
 bids[[Link]] = Bid(hash, [Link]);
}
Reveal Function
function reveal(uint _value, string memory _secret) public {

require(
bids[[Link]].hash ==
keccak256([Link](_value, _secret)),
"Wrong Reveal"
);

if(_value > highestBid){

highestBid = _value;
highestBidder = [Link];
}
}
Withdraw Function
function withdraw() public {
uint amount = refunds[[Link]];
refunds[[Link]] = 0;
payable([Link]).transfer(amount);
}
Answer
The Blind Auction contract hides bid values during the bidding stage using a commit-reveal mechanism. During
the commit phase, the bidder submits a bid value and secret string. The contract generates a hash using
keccak256([Link](_value, _secret)) and stores only the hash. Since only the hash is stored, other
participants cannot see the actual bid amount.
During the reveal phase, the bidder submits the original bid value and secret. The contract recalculates the hash
and compares it with the stored hash. If both hashes match, the bid is accepted as valid. The contract then
determines whether the revealed bid is higher than the current highest bid.
If a participant becomes outbid, their deposited amount is moved to the refund mapping. The withdraw function
allows those users to safely reclaim their funds. This prevents bid sniping and ensures fairness because bids
remain hidden until the reveal stage.
What to Verify
• Commit transaction stores hash successfully.
• Reveal function matches the original hash.
• Highest bidder updates correctly.
• Refund amount appears for outbid users.
• Withdraw function transfers refund successfully.
2. Multi-Signature Corporate Wallet
Question
Design a wallet that requires approval from a majority of owners (3 out of 5) before executing a transaction.
Given
• Transaction Struct
• Confirmation Counter
• Approval Mapping
• Required Confirmations
Submit Transaction
function submit(address _to, uint _value) public {
 [Link](
Transaction(
_to,
_value,
false,
0
)
);
}
Approve Transaction
function approve(uint txId) public {

approved[txId][[Link]] = true;

transactions[txId].confirmations++;

if(
transactions[txId].confirmations
>= required
){
transactions[txId].executed = true;
}
}
Answer
The Multi-Signature Wallet increases security by requiring multiple approvals before a transaction can be
executed. When a user submits a transaction, the contract stores the transaction details such as recipient address,
transfer amount, execution status, and confirmation count.
Each owner can approve a transaction only once because the approval mapping records which owner has
already signed a specific transaction. Every approval increases the confirmation counter.
The transaction remains in a pending state until the required number of confirmations is reached. Once the
confirmation count becomes equal to or greater than the required threshold, the contract automatically marks the
transaction as executed. This prevents a single owner from having complete control over corporate funds.
What to Verify
• Transaction submitted successfully.
• After first approval → confirmations = 1.
• After second approval → confirmations = 2 and still pending.
• After third approval → executed becomes true.
• Transaction status changes from Pending to Executed.
3. Time-Locked Vesting Contract
Question
Automate employee token release over a 4-year period with a 1-year cliff.
Given
• [Link]
• Cliff period
• Vesting duration
• Release function
Release Function
function release() public {

require(
 [Link] >= start + cliff,
"Cliff not reached"
);

uint vested =
(totalAmount *
([Link] - start))
/ duration;

uint unreleased =
vested - released;

released += unreleased;

payable(beneficiary)
.transfer(unreleased);
}
Answer
The vesting contract releases funds gradually to a beneficiary over time. When the contract is deployed, the
deployment timestamp becomes the starting point of the vesting schedule. The beneficiary cannot withdraw any
funds before the cliff period ends.
The release function first checks whether the current block timestamp has passed the cliff period. If the cliff has
not been reached, the transaction reverts with the message "Cliff not reached".
Once the cliff period expires, the contract calculates the vested amount using the proportion of elapsed time
compared to the total vesting duration. The beneficiary can then withdraw only the vested portion while the
remaining balance stays locked. This ensures controlled and gradual distribution of funds.
What to Verify
• Release before cliff produces revert error.
• "Cliff not reached" message displayed.
• Release after cliff succeeds.
• Correct vested amount calculated.
• Released amount increases after withdrawal.
4. Decentralized Supply Chain with Role-Based Access
Question
Track a product from Manufacturer → Distributor → Retailer using role-based access control.
Given
• Manufacturer role
• Retailer role
• Access control restrictions
• shipItem() function
Manufacturer Check
modifier onlyManufacturer() {
require(
[Link] == manufacturer,
"Not Manufacturer"
);
_;
}
Ship Item
function shipItem()
public
onlyManufacturer
{
status = "Shipped";
}
Answer
The supply chain system uses role-based access control to restrict which users can perform specific operations.
Different blockchain addresses are assigned different roles such as Manufacturer, Distributor, and Retailer.
The Manufacturer is responsible for creating products and shipping them through the supply chain. Before
executing functions such as shipItem(), the contract checks whether the caller has the required role.
If a Retailer attempts to execute a function reserved for the Manufacturer, the contract rejects the transaction
immediately. This prevents unauthorized modifications to product records and ensures that each stage of the
supply chain is handled only by authorized participants. The blockchain maintains a transparent and immutable
record of all product movements.
What to Verify
• Manufacturer role assigned successfully.
• Manufacturer calls shipItem() successfully.
• Retailer role assigned.
• Retailer attempts shipItem().
• Transaction rejected due to insufficient permissions.
5. Trustless NFT Swap (Escrow)
Question
Allow two parties to exchange digital assets without requiring a trusted third party.
Given
• Party A
• Party B
• Escrow Contract
• depositA()
• depositB()
• swap()
Deposit A
function depositA() public {

require(
[Link] == partyA,
"Not Party A"
);

depositedA = true;
}
Deposit B
function depositB() public {

require(
[Link] == partyB,
"Not Party B"
);

depositedB = true;
}
Swap
function swap() public {

require(
depositedA &&
depositedB,
"Both parties must deposit"
);

depositedA = false;
depositedB = false;
}
Answer
The escrow contract enables a trustless exchange between two parties. Initially, Party A and Party B must both
deposit their respective assets into the contract. The contract tracks these deposits using the boolean variables
depositedA and depositedB.
The swap function cannot execute until both parties have successfully deposited their assets. This is enforced
through the condition require(depositedA && depositedB).
Once both deposits are confirmed, the contract performs the swap operation and resets the deposit flags. This
ensures that neither participant can receive the other asset unless both parties have fulfilled their obligations.
The escrow mechanism removes the need for a middleman and guarantees fairness during the exchange process.
What to Verify
• Party A deposit successful.
• Party B deposit successful.
• Contract records both deposits as true.
• Swap function executes successfully.
• Deposit flags reset after swap.
• Asset ownership transferred correctly.

1(a) Explain the features, working mechanism, and applications of Ethereum and Discuss the
architecture and consensus mechanism of Solana. (8 Marks)
Ethereum
Introduction
Ethereum is an open-source blockchain platform introduced by Vitalik Buterin in 2015. It was designed to
support not only cryptocurrency transactions but also smart contracts and decentralized applications (DApps).
Ethereum enables developers to create programmable applications that operate without intermediaries. It
provides a secure, transparent, and decentralized environment for executing digital transactions and agreements.
Features of Ethereum
Ethereum offers several unique features that make it one of the most widely used blockchain platforms. Its
primary feature is the support for smart contracts, which are self-executing programs that automatically perform
actions when predefined conditions are met. Ethereum also supports decentralized applications (DApps),
allowing developers to build applications without relying on centralized servers. The platform uses the
Ethereum Virtual Machine (EVM), which executes smart contracts consistently across all nodes in the network.
In addition, Ethereum provides transparency, immutability, and strong security through cryptographic
mechanisms.
Features
• Smart Contracts
• Decentralized Applications (DApps)
 • Ethereum Virtual Machine (EVM)
• Native Cryptocurrency (Ether - ETH)
• Transparency and Immutability
• Decentralized Network
• High Security
Working Mechanism of Ethereum
Ethereum operates through a distributed network of nodes that maintain a shared copy of the blockchain ledger.
When a user initiates a transaction, it is broadcast to the network and verified by validators. If the transaction
contains a smart contract, the Ethereum Virtual Machine executes the contract code. After successful
verification, transactions are grouped into blocks and permanently added to the blockchain. Every node updates
its ledger copy, ensuring consistency and transparency across the network.
Steps Involved
Step 1: Transaction Creation
A user creates a transaction using an Ethereum wallet and signs it digitally using a private key. The transaction
may involve transferring Ether or interacting with a smart contract.
Step 2: Broadcasting the Transaction
The transaction is sent to the Ethereum network, where it becomes visible to validators waiting to verify
pending transactions.
Step 3: Validation
Validators check the transaction details, verify the digital signature, and ensure that the sender has sufficient
balance to perform the transaction.
Step 4: Smart Contract Execution
If the transaction contains a smart contract, the Ethereum Virtual Machine executes the contract instructions and
produces the corresponding output.
Step 5: Block Creation
Validated transactions are grouped together into a block. The block is then approved through the consensus
mechanism.
Step 6: Blockchain Update
The approved block is added to the blockchain, and every node updates its local copy of the ledger. The
transaction becomes permanent and immutable.
Applications of Ethereum
Ethereum has become the foundation for numerous blockchain-based applications across various industries. Its
programmability allows developers to create innovative decentralized solutions that improve transparency,
automation, and security.
Decentralized Finance (DeFi)
Ethereum enables financial services such as lending, borrowing, staking, and trading without the need for
traditional banks. Smart contracts automate these processes and reduce operational costs.
Non-Fungible Tokens (NFTs)
Ethereum is widely used for creating and trading NFTs. These digital assets represent ownership of unique
items such as artwork, music, gaming assets, and collectibles.
Supply Chain Management
Ethereum helps organizations track products throughout the supply chain. Every transaction is recorded on the
blockchain, improving transparency and reducing fraud.
Healthcare
Patient records can be securely stored and shared using Ethereum-based systems. This improves data integrity,
privacy, and accessibility.
Voting Systems
Ethereum can be used to build secure electronic voting systems where votes are recorded immutably, preventing
manipulation and increasing trust.
Digital Identity Management
Ethereum enables users to maintain self-sovereign digital identities without depending on centralized
authorities.
Solana
Introduction
Solana is a high-performance blockchain platform developed to address scalability and transaction speed issues
found in traditional blockchains. It is designed to support decentralized applications and cryptocurrency
transactions with very low fees and high throughput. Solana achieves this by combining Proof of History (PoH)
with Proof of Stake (PoS), allowing thousands of transactions to be processed per second.
Architecture of Solana
Solana's architecture consists of several innovative technologies that work together to provide high-speed and
scalable blockchain operations. Unlike traditional blockchains, Solana uses a cryptographic clock known as
Proof of History to improve transaction ordering and reduce consensus delays.
Proof of History (PoH)
Proof of History is a cryptographic timestamping mechanism that records the sequence of events before
consensus occurs. It acts as a decentralized clock, allowing validators to verify transaction order efficiently.
This significantly improves transaction speed and reduces communication overhead.
Validators
Validators are responsible for verifying transactions, maintaining the blockchain ledger, and participating in the
consensus process. They stake SOL tokens and help secure the network.
Turbine Protocol
Turbine is a block propagation protocol that divides large blocks into smaller packets and distributes them
efficiently across the network. This reduces bandwidth requirements and improves scalability.
Gulf Stream
Gulf Stream forwards transactions to validators before block production begins. This minimizes transaction
confirmation delays and improves network efficiency.
Sealevel
Sealevel is Solana's parallel smart contract execution engine. It allows multiple transactions to be processed
simultaneously, greatly increasing throughput.
Pipelining
Pipelining optimizes transaction processing by assigning different hardware components to specific tasks,
enabling continuous and efficient execution.
Cloudbreak
Cloudbreak is Solana's data storage mechanism that supports parallel reading and writing operations, improving
database performance.
Consensus Mechanism of Solana
Solana uses a hybrid consensus mechanism that combines Proof of History (PoH) and Proof of Stake (PoS).
This combination allows the network to achieve both speed and security.
Proof of History (PoH)
Proof of History generates verifiable timestamps that establish the order of transactions before they are
validated. This eliminates the need for validators to spend time agreeing on transaction order, thereby increasing
efficiency.
Proof of Stake (PoS)
Validators stake SOL tokens to participate in consensus. Validators who behave honestly receive rewards, while
malicious validators may lose a portion of their stake. This mechanism ensures network security and encourages
honest participation.
Benefits of Solana Consensus
The combination of PoH and PoS provides several advantages. It enables very high transaction throughput, low
transaction fees, rapid confirmation times, and efficient scalability. Solana can process thousands of transactions
per second while maintaining decentralization and security.
Benefits
 • High transaction speed
• Low transaction cost
• Fast block confirmation
• Improved scalability
• Energy efficient
• Secure consensus process

1(b) Explain the advantages and disadvantages of Proof of Work, Proof of Stake, and PBFT consensus
algorithms. Based on your comparison, which consensus algorithm would you choose for your blockchain
network, and why? (7 Marks)
Introduction
Consensus algorithms are the core components of blockchain technology that help all nodes in the network
agree on a single version of the ledger. They ensure transaction validity, prevent fraud, and maintain network
security without relying on a central authority. Different consensus mechanisms provide different levels of
security, scalability, decentralization, and performance. The most widely used consensus algorithms are Proof
of Work (PoW), Proof of Stake (PoS), and Practical Byzantine Fault Tolerance (PBFT).
Proof of Work (PoW)
Proof of Work is the first and most popular blockchain consensus mechanism, introduced by Bitcoin. In PoW,
miners compete to solve complex mathematical puzzles using computational power. The first miner to solve the
puzzle earns the right to add the next block to the blockchain and receives a reward. This process secures the
network and prevents malicious activities.
Advantages of Proof of Work
Proof of Work provides a very high level of security because attackers would need enormous computational
resources to alter blockchain data. It is highly decentralized since anyone with mining hardware can participate
in the network. PoW has been tested for many years through Bitcoin and has proven to be reliable and resistant
to attacks. It also effectively prevents double-spending by requiring significant computational effort before
transactions are confirmed.
Advantages
• High security
• Strong decentralization
• Prevents double spending
• Proven and reliable technology
• Resistant to network attacks
Disadvantages of Proof of Work
Despite its security benefits, PoW consumes a large amount of electricity because miners continuously perform
computational work. Specialized hardware such as ASIC miners is often required, making participation
expensive. Transaction processing is relatively slow, and scalability becomes a challenge as the network grows.
These issues increase operational costs and raise environmental concerns.
Disadvantages
• Very high energy consumption
• Expensive mining hardware
• Slow transaction speed
• Limited scalability
• Environmental impact
Proof of Stake (PoS)
Proof of Stake is a consensus mechanism where validators are selected based on the amount of cryptocurrency
they stake in the network. Instead of solving mathematical puzzles, validators are chosen to create and validate
blocks according to their stake. This significantly reduces energy consumption while maintaining network
security.
Advantages of Proof of Stake
Proof of Stake is much more energy-efficient than PoW because it does not require intensive computational
work. It supports faster transaction processing and better scalability. Since expensive mining hardware is
unnecessary, participation becomes more accessible. PoS also reduces operational costs while maintaining a
secure and decentralized environment.
Advantages
• Energy efficient
• Faster transactions
• Better scalability
• Lower hardware requirements
• Reduced operational costs
Disadvantages of Proof of Stake
One major concern with PoS is that validators with large stakes may gain greater influence over the network.
This can potentially lead to centralization. Wealthier participants may continue accumulating rewards,
increasing their dominance over time. Additionally, new users may face difficulty participating if the staking
requirements are high.
Disadvantages
• Risk of wealth concentration
• Potential centralization
• High staking requirements
• Rich-get-richer problem
• Dependence on token ownership
Practical Byzantine Fault Tolerance (PBFT)
Practical Byzantine Fault Tolerance (PBFT) is a consensus mechanism designed to tolerate malicious or faulty
nodes while maintaining agreement among honest nodes. It is commonly used in permissioned blockchain
networks such as Hyperledger Fabric. PBFT achieves consensus through communication and voting among
nodes rather than mining.
Advantages of PBFT
PBFT provides instant transaction finality, meaning that once a transaction is confirmed, it cannot be reversed.
It consumes very little energy because no mining process is involved. The algorithm can tolerate malicious
behavior from a portion of participating nodes and still maintain network integrity. PBFT is highly suitable for
enterprise and consortium blockchain environments.
Advantages
• Instant finality
• Energy efficient
• High transaction speed
• Byzantine fault tolerance
• Suitable for enterprise applications
Disadvantages of PBFT
PBFT requires extensive communication among nodes during the consensus process. As the number of nodes
increases, communication overhead grows rapidly, reducing efficiency. This limits scalability and makes PBFT
less suitable for large public blockchain networks. The consensus process can also become complex to manage
in very large systems.
Disadvantages
• High communication overhead
• Limited scalability
• Complex implementation
• Performance decreases with many nodes
• Less suitable for public blockchains
Comparison of PoW, PoS, and PBFT
Feature PoW PoS PBFT
Security Very High High High
Energy Consumption Very High Low Very Low
Transaction Speed Slow Fast Very Fast
Scalability Limited Good Limited
Hardware Requirement High Low Low
Finality Probabilistic Faster Finality Instant Finality
Suitable For Public Networks Public Networks Permissioned Networks
Preferred Consensus Algorithm
For my blockchain network, I would choose Proof of Stake (PoS) because it provides the best balance between
security, scalability, and energy efficiency. Unlike Proof of Work, it does not require expensive mining
hardware or excessive electricity consumption. Compared to PBFT, it can support large public blockchain
networks without suffering from communication bottlenecks.
PoS enables faster transaction processing, lower operational costs, and improved scalability while maintaining
strong network security. It is also environmentally friendly and suitable for modern blockchain applications
such as decentralized finance, NFTs, supply chain management, and digital identity systems. Therefore, PoS is
the most practical and sustainable consensus mechanism for building a modern blockchain network.

1(c) [10 Marks]

A multinational educational foundation intends to implement a blockchain-based scholarship
management platform to ensure transparency, accountability, and secure distribution of financial aid.
The platform should enable sponsors to monitor scholarship contributions in real time, verify the
allocation of funds to eligible students, maintain immutable transaction records, and provide secure
digital wallets for sponsors and beneficiaries.
Design a comprehensive blockchain architecture for this platform by selecting and justifying an
appropriate blockchain framework. Describe the overall network topology, the participating entities and
nodes, and specify the consensus mechanism employed. Explain how smart contracts can automate
scholarship application verification, fund allocation, and disbursement processes. Illustrate the complete
workflow through a neat architectural diagram showing interactions among sponsors, students,
educational institutions, blockchain nodes, and smart contracts.

Introduction
Traditional scholarship management systems often face challenges such as lack of transparency, delayed fund
distribution, manual verification processes, and risks of fraud or record manipulation. Sponsors frequently have
limited visibility into how their contributions are utilized, while students experience delays in receiving
financial aid. Blockchain technology can overcome these issues by providing a decentralized, transparent, and
tamper-proof platform where every transaction is securely recorded and easily traceable. The proposed
blockchain-based scholarship management platform ensures accountability, trust, and efficient distribution of
scholarship funds.
Selection of Blockchain Framework
For this scholarship management platform, Hyperledger Fabric is the most suitable blockchain framework.
Hyperledger Fabric is a permissioned blockchain that allows only authorized participants to access the network.
Since scholarship information contains sensitive student and financial data, privacy and controlled access are
important requirements.
Hyperledger Fabric provides high transaction throughput, strong security, access control mechanisms, and
support for smart contracts known as chaincode. It also allows educational institutions, sponsors, and
administrators to collaborate within a trusted environment while maintaining data confidentiality.
Reasons for Selecting Hyperledger Fabric
• Permissioned network
• High scalability
• Better privacy protection
• Faster transaction processing
• Supports smart contracts
• Suitable for educational institutions
Participating Entities
Sponsors
Sponsors are organizations, government agencies, charities, or individuals who provide scholarship funds. They
contribute money to the scholarship pool and can monitor the utilization of funds through the blockchain
network. Sponsors gain complete visibility into scholarship allocation and can verify that funds are distributed
only to eligible students.
Students
Students are the primary beneficiaries of the scholarship program. They register on the platform, submit
scholarship applications, and receive financial assistance through secure digital wallets. Students can also track
the status of their applications in real time.
Educational Institutions
Educational institutions act as trusted verification authorities. They verify student eligibility, academic
performance, attendance records, and supporting documents. Their verification results are recorded permanently
on the blockchain, ensuring authenticity and transparency.
Blockchain Nodes
Blockchain nodes maintain copies of the distributed ledger and validate transactions. These nodes are operated
by sponsors, universities, scholarship boards, and administrative authorities. Every validated transaction is
replicated across all nodes, ensuring consistency and fault tolerance.
Smart Contracts
Smart contracts automate scholarship-related operations such as application submission, eligibility verification,
approval, fund allocation, and fund disbursement. This reduces manual intervention and ensures fair decision-
making.
Network Topology
The platform follows a consortium blockchain model where multiple trusted organizations participate in
maintaining the network. Sponsors, universities, and scholarship authorities operate blockchain nodes connected
through a secure peer-to-peer network.
Each participant maintains a synchronized copy of the ledger. Transactions generated by students, institutions,
and sponsors are validated through the consensus mechanism before being permanently recorded on the
blockchain.
Network Components
• Sponsor Nodes
• University Nodes
• Scholarship Authority Nodes
• Smart Contract Layer
• Distributed Ledger
• Student Wallets
Consensus Mechanism
The platform uses Practical Byzantine Fault Tolerance (PBFT) as its consensus mechanism. PBFT enables
participating nodes to agree on transactions even when some nodes behave incorrectly or maliciously. Since the
network consists of trusted organizations, PBFT provides fast and energy-efficient consensus without requiring
mining.
PBFT ensures immediate transaction finality, meaning once a scholarship transaction is approved, it cannot be
reversed or altered. This improves reliability and prevents disputes regarding scholarship distribution.
Benefits of PBFT
• Fast transaction confirmation
• Energy efficient
• Fault tolerant
• Immediate finality
• Suitable for permissioned networks
Smart Contract Automation
Scholarship Application Submission
Students submit scholarship applications through a smart contract. The application includes personal
information, academic records, income certificates, and supporting documents. Once submitted, the information
is recorded on the blockchain and cannot be altered.
Eligibility Verification
The educational institution reviews and verifies student information. Smart contracts automatically compare the
submitted data against predefined eligibility criteria such as minimum grades, attendance requirements, and
financial need. Verification results are stored on the blockchain.
Scholarship Approval
After successful verification, the smart contract evaluates whether the student satisfies all scholarship
requirements. Eligible applications are automatically approved and forwarded to sponsors for final
authorization.
Fund Allocation
Once approved, the smart contract calculates the scholarship amount according to predefined rules. The
allocated amount is reserved for the selected student and recorded transparently on the blockchain.
Fund Disbursement
The smart contract automatically transfers the scholarship amount to the student's digital wallet. Every
transaction is recorded permanently, allowing sponsors and institutions to verify successful fund delivery.
Security Features
Transparency
All scholarship transactions are visible to authorized participants, ensuring complete transparency throughout
the funding process.
Immutability
Once scholarship records are stored on the blockchain, they cannot be modified or deleted. This prevents fraud
and unauthorized changes.
Accountability
Every action performed on the platform is associated with a specific participant. This creates a clear audit trail
and improves accountability.
Data Integrity
Cryptographic hashing ensures that stored records remain accurate and untampered.
Fraud Prevention
Duplicate applications, fake student records, and unauthorized fund transfers are prevented through smart
contract validation and blockchain verification.
Workflow of the Scholarship Management Platform
Step 1: Student Registration
The student creates an account and uploads academic and personal information to the platform.
Step 2: Scholarship Application
The student submits a scholarship application through a smart contract.
Step 3: Verification
Educational institutions verify academic performance and eligibility criteria.
Step 4: Smart Contract Validation
The smart contract automatically checks whether the student meets scholarship requirements.
Step 5: Approval
Eligible applications are approved by sponsors and scholarship authorities.
Step 6: Fund Allocation
The smart contract allocates the scholarship amount to the approved student.
Step 7: Fund Disbursement
The scholarship amount is transferred to the student's digital wallet.
Step 8: Audit and Monitoring
Sponsors monitor transactions and verify scholarship utilization through the blockchain ledger.
Architecture Diagram
Sponsors
|
v
------------------
| Smart Contract |
------------------
/ \
/ \
v v
Educational Students
Institutions
|
v
-----------------------
| Blockchain Network |
| (Hyperledger |
| Fabric) |
-----------------------
|
v
Student Wallets
Advantages of the Proposed System
The blockchain-based scholarship management platform improves transparency by allowing sponsors to track
every contribution and fund transfer. Smart contracts automate verification and approval processes, reducing
administrative workload and processing time. Immutable blockchain records prevent fraud and ensure
accountability among all participants. The use of digital wallets enables secure and efficient fund distribution
directly to students. The platform also enhances trust among sponsors, educational institutions, and
beneficiaries.
Advantages
• Transparent fund tracking
• Faster scholarship processing
• Secure digital wallets
• Reduced fraud and corruption
• Automated verification process
• Immutable transaction records
• Improved accountability
• Real-time monitoring
2(a) A blockchain platform operating with the Delegated Proof of Stake (DPoS) consensus protocol
encounters several challenges, including biased delegate election, limited participation from token
holders, concentration of authority among a small group of validators, and inefficiencies in block
confirmation times.
Design an enhanced voting and incentive framework for the DPoS network that addresses these
limitations. Propose a delegate election mechanism that promotes equitable representation, transparency,
security, and timely block generation. Explain how the proposed approach mitigates centralization risks,
encourages greater stakeholder involvement, strengthens network resilience, and improves overall
transaction processing performance when compared with conventional DPoS-based blockchain systems.
(8 Marks)
Introduction
Delegated Proof of Stake (DPoS) is a consensus mechanism in which token holders vote for a small group of
delegates who are responsible for validating transactions and producing blocks. Although DPoS offers faster
transaction processing and lower energy consumption compared to Proof of Work, it faces challenges such as
validator centralization, low voter participation, biased delegate selection, and concentration of power among a
few delegates. To overcome these limitations, an enhanced voting and incentive framework can be implemented
to improve fairness, transparency, security, and network efficiency.
Existing Problems in Traditional DPoS
Biased Delegate Election
In conventional DPoS systems, wealthy token holders possess significant voting power because votes are
proportional to stake ownership. As a result, a small number of powerful stakeholders can repeatedly elect the
same delegates, reducing fairness and diversity within the validator set.
Limited Participation
Many token holders do not actively participate in voting because they receive little benefit from the election
process. This voter apathy reduces community involvement and allows a small group of voters to control
network decisions.
Validator Centralization
Over time, the same delegates continue receiving votes and remain in power. This creates centralization and
increases the risk of collusion among validators, potentially threatening network security.
Slow Confirmation Efficiency
Although DPoS is generally faster than PoW, inefficient delegate scheduling and repeated election cycles can
affect block confirmation efficiency and transaction throughput.
Proposed Enhanced Voting Framework
Weighted Reputation-Based Voting
Instead of relying solely on token ownership, voting power should be calculated using both stake and delegate
reputation. Reputation scores can be based on validator performance, uptime, honesty, and successful block
production history.
This approach prevents wealthy stakeholders from completely controlling elections and encourages delegates to
maintain high-quality performance to retain voter trust.
Benefits
• Fair delegate selection
• Reduced dominance of wealthy voters
• Increased accountability
• Better validator performance
Quadratic Voting Mechanism
Quadratic voting reduces the influence of large stakeholders by making additional votes progressively more
expensive. This ensures that small token holders also have meaningful participation in the election process.
The voting system becomes more democratic because influence is distributed across a larger portion of the
community rather than concentrated among a few wealthy participants.
Benefits
• Greater fairness
• Improved representation
• Reduced voting monopolies
• Enhanced decentralization
Continuous Election System
Rather than conducting elections only at fixed intervals, voting should remain active continuously. Token
holders can change their votes at any time if delegates perform poorly or act maliciously.
This creates constant accountability and motivates delegates to maintain good performance and network
reliability.
Benefits
• Real-time governance
• Increased accountability
• Faster removal of malicious delegates
• Improved network trust
Enhanced Incentive Framework
Voter Reward Mechanism
To encourage active participation, token holders who vote regularly should receive a portion of validator
rewards. This motivates stakeholders to participate in governance and helps increase voter turnout.
Higher participation results in more representative elections and stronger decentralization.
Benefits
• Increased voter engagement
• Better governance participation
• Stronger community involvement
• Improved election legitimacy
Performance-Based Validator Rewards
Delegates should receive rewards based on their actual network performance rather than simply holding a
validator position. Metrics such as uptime, transaction processing speed, and successful block production can be
used to calculate rewards.
Validators who fail to perform efficiently receive reduced rewards, encouraging better service quality.
Benefits
• Encourages honest behavior
• Improves network reliability
• Enhances validator efficiency
• Promotes healthy competition
Slashing Mechanism
A slashing mechanism penalizes validators who engage in malicious activities such as double-signing blocks,
censorship, or prolonged downtime. A portion of the validator's stake is deducted as punishment.
This discourages attacks and strengthens network security.
Benefits
• Prevents malicious activities
• Improves security
• Protects network integrity
• Encourages responsible behavior
Improved Delegate Election Mechanism
The enhanced delegate election mechanism combines stake-based voting, reputation scores, continuous
elections, and performance monitoring. Delegates are ranked using a combined score derived from stake
support and reputation metrics.
The highest-ranked delegates become active validators, while backup delegates remain ready to replace
underperforming validators immediately. This ensures fair representation and continuous availability of
validators.
Election Formula
Delegate Score =
Stake Support + Reputation Score + Performance Rating
This multi-factor approach produces a more balanced and transparent election process compared to traditional
DPoS systems.
Security and Transparency Enhancements
Transparent Voting Records
All voting activities are recorded on the blockchain, allowing participants to verify election results
independently. This eliminates hidden manipulations and improves trust.
Public Delegate Performance Metrics
Validator performance statistics such as uptime, missed blocks, and transaction throughput are publicly
available. Voters can make informed decisions based on actual performance.
Decentralized Governance
Community members actively participate in governance decisions, reducing dependence on a small group of
stakeholders.
Network Resilience Improvements
The proposed framework strengthens network resilience by maintaining a diverse validator set and rapidly
replacing underperforming delegates. Backup validators ensure uninterrupted block production even if active
validators become unavailable.
Continuous monitoring and dynamic elections allow the network to adapt quickly to failures or attacks,
improving overall stability.
Benefits
• Fault tolerance
• Improved availability
• Faster recovery from failures
• Greater network stability
Improved Transaction Processing Performance
The proposed framework improves transaction processing performance through better validator selection and
optimized block production scheduling. High-performing delegates are prioritized, ensuring faster transaction
validation and lower confirmation times.
Efficient validator management reduces network bottlenecks and increases throughput while maintaining
security and decentralization.
Performance Improvements
• Faster block generation
• Reduced transaction delays
• Higher throughput
• Better scalability
• Lower confirmation times
Comparison with Traditional DPoS
Feature Traditional DPoS Enhanced DPoS
Delegate Selection Stake Based Stake + Reputation
Voting Participation Low High
Centralization Risk High Reduced
Validator Accountability Limited Continuous
Security Moderate High
Transaction Speed Fast Faster
Governance Limited Community Driven

2(b) I
In PoET, every node requests a wait time from its secure hardware. The node with the shortest wait time
wins the right to forge the next block. Imagine a network with 100 nodes.
 • Node A is a massive supercomputer with 128 CPU cores.
• Node B is a simple laptop with a single 4-core processor.
• Both nodes have the same Intel SGX security hardware.
i) Does Node A have a higher statistical chance of winning the next block than Node B?
Introduction
Proof of Elapsed Time (PoET) is a consensus mechanism designed to achieve fairness without requiring
intensive computational power. Instead of competing through mining, every node receives a randomly
generated waiting time from a Trusted Execution Environment (TEE), such as Intel SGX. The node with the
shortest waiting time gets the right to create the next block.
Answer
No, Node A does not have a higher statistical chance of winning the next block than Node B.
In PoET, block selection is not based on CPU power, memory size, or hardware performance. The waiting time
is generated randomly by Intel SGX, which acts as a trusted and secure environment. Since both Node A and
Node B use the same Intel SGX hardware, both nodes have an equal probability of receiving the shortest
waiting time.
Even though Node A has 128 CPU cores and Node B has only 4 CPU cores, the additional processing power
does not provide any advantage during leader selection. The consensus mechanism intentionally removes
hardware competition to ensure fairness among participants.
This approach is very different from Proof of Work, where more computational power directly increases the
probability of mining a block. In PoET, fairness is achieved because all nodes depend on randomly assigned
waiting periods rather than processing capability.
Key Points
• CPU power does not affect block selection.
• Intel SGX generates random wait times.
• Both nodes have equal winning probability.
• PoET ensures fairness among participants.
• Supercomputers do not gain mining advantages.
ii) If Node A tries to "speed up" its internal clock to make 10 seconds pass in only 5 seconds, why will the
rest of the network reject its block?
Introduction
One of the main security features of PoET is the use of Intel SGX, which generates cryptographic certificates
proving that the assigned waiting period was actually completed. This prevents participants from cheating by
manipulating local system clocks.
Answer
The network will reject Node A's block because PoET requires a valid certificate generated by Intel SGX
proving that the assigned waiting time has fully elapsed. The secure hardware independently tracks the waiting
period and cannot be fooled by modifications to the system clock.
If Node A attempts to make 10 seconds appear as 5 seconds by changing its local clock, the Intel SGX
environment will still record the actual elapsed time. When the block is broadcast to the network, other nodes
verify the certificate attached to the block.
Since the certificate will show that the required 10-second waiting period was not completed, the proof becomes
invalid. As a result, the network identifies the block as fraudulent and rejects it immediately.
This mechanism ensures that every validator follows the assigned waiting period honestly and prevents unfair
advantages.
Key Points
• Intel SGX monitors actual elapsed time.
• Local clock manipulation cannot fool SGX.
• Certificate proves waiting period completion.
• Invalid certificate causes block rejection.
• Prevents cheating and maintains fairness.
2(b) II
When a node's timer expires, the secure hardware generates a Certificate proving the time actually
elapsed. An attacker discovers a way to "pause" their secure hardware right before the timer ends. They
wait until the network is at a very high traffic moment, "unpause" it, and immediately broadcast a
winning certificate they generated for a block that was supposed to be mined 30 minutes ago.
i) Why must a PoET certificate be tied to a specific Block Hash (the most recent block)?
Introduction
In blockchain systems, every block depends on the previous block through cryptographic hashing. This creates
a chain of blocks and ensures that transactions remain in the correct order. PoET certificates must therefore be
linked to a specific blockchain state.
Answer
A PoET certificate must be tied to the most recent block hash because the blockchain continuously changes
whenever a new block is added. The block hash uniquely identifies the current state of the blockchain at a
particular moment.
If certificates were not linked to a specific block hash, attackers could generate certificates in advance and reuse
them later when conditions become favorable. This would allow them to gain unfair advantages and potentially
manipulate transaction ordering.
By binding the certificate to the latest block hash, the certificate becomes valid only for that specific blockchain
state. As soon as a new block is created, the previous certificate becomes useless because the block hash has
changed.
This mechanism prevents replay attacks and ensures that every certificate corresponds to the current blockchain
condition.
Key Points
• Block hash represents current blockchain state.
• Prevents reuse of old certificates.
• Protects against replay attacks.
• Ensures fairness in block creation.
• Maintains transaction order integrity.
ii) If the attacker provides a valid certificate showing they waited 10 seconds, but that certificate was
generated based on the "Previous Block Hash" from an hour ago, will the network accept it? Why or
why not?
Introduction
Blockchain consensus mechanisms require validators to work with the most recent version of the ledger. Any
information generated using outdated blockchain data becomes invalid because the network state has already
changed.
Answer
No, the network will not accept the certificate.
Although the certificate correctly proves that the validator waited for 10 seconds, it was generated using an
outdated block hash from one hour earlier. During that hour, many new blocks would have been added to the
blockchain, changing the current network state.
When other nodes verify the certificate, they compare the block hash embedded in the certificate with the latest
block hash stored on the blockchain. Since the two hashes do not match, the certificate is considered stale and
invalid.
The network rejects the certificate because accepting it would allow attackers to reuse old waiting proofs and
gain unfair advantages. By rejecting outdated certificates, PoET ensures that only validators participating in the
current blockchain state can create new blocks.
Key Points
• Certificate is linked to an old block hash.
• Blockchain state has changed.
• Hash mismatch occurs during verification.
 • Certificate becomes invalid.
• Network rejects outdated proofs.

2(c) Explain on attacks on PoW and Monopoly Problem. (10 Marks)

Introduction
Proof of Work (PoW) is one of the most widely used blockchain consensus mechanisms and is employed by
cryptocurrencies such as Bitcoin. In PoW, miners compete to solve complex mathematical puzzles to validate
transactions and add new blocks to the blockchain. Although PoW provides strong security and
decentralization, it is still vulnerable to several attacks and monopoly-related problems. These attacks can
threaten the integrity, fairness, and stability of the blockchain network.
Attacks on Proof of Work (PoW)
1. 51% Attack
A 51% attack occurs when a single miner or a group of miners gains control of more than 50% of the total
mining power of the network. With majority control, the attacker can manipulate the blockchain and influence
transaction validation. Although the attacker cannot create coins from nothing, they can disrupt normal network
operations and perform fraudulent activities.
Working of 51% Attack
When the attacker controls the majority of the hash power, they can create blocks faster than the rest of the
network. This allows them to build a longer blockchain branch and force honest nodes to accept their version of
the blockchain. As a result, previously confirmed transactions can be reversed.
Effects of 51% Attack
• Double spending of coins
• Reversing confirmed transactions
• Blocking transactions from other users
• Disrupting normal blockchain operations
• Reducing trust in the network
Prevention
• Increase network decentralization
• Encourage more miners to participate
• Use larger mining pools carefully
• Monitor abnormal hash rate concentration
2. Selfish Mining Attack
Selfish mining is a strategy in which a miner or mining pool secretly keeps newly mined blocks private instead
of immediately broadcasting them to the network. The attacker attempts to gain an unfair advantage and earn
more rewards than honest miners.
Working of Selfish Mining
The selfish miner mines a block and keeps it hidden from the network. While honest miners continue mining on
the public chain, the attacker secretly extends their private chain. When the private chain becomes longer than
the public chain, the attacker releases it. Since blockchain protocols generally accept the longest chain, the
attacker's chain becomes valid and honest miners lose their rewards.
Effects of Selfish Mining
• Unfair mining rewards
• Wasted computational resources
• Reduced network efficiency
• Increased centralization
• Lower trust among miners
Prevention
• Encourage rapid block propagation
• Detect abnormal mining behavior
• Promote mining decentralization
 • Modify reward distribution mechanisms
3. Sybil Attack
A Sybil attack occurs when an attacker creates multiple fake identities or nodes within the blockchain network.
These fake nodes attempt to gain influence and manipulate network decisions.
Working of Sybil Attack
The attacker creates a large number of fake nodes and joins the network. These nodes appear as independent
participants but are controlled by the same entity. The attacker then attempts to influence consensus, spread
false information, or disrupt network communication.
Effects of Sybil Attack
• Manipulation of network decisions
• Increased network congestion
• Reduced trust in the system
• Potential disruption of consensus
Prevention
• Proof of Work requirements
• Identity verification mechanisms
• Resource-based participation costs
• Strong node authentication
4. Double Spending Attack
Double spending is an attack where a user attempts to spend the same cryptocurrency more than once. This
attack becomes possible if transaction confirmations are weak or if the attacker controls significant mining
power.
Working of Double Spending
The attacker sends cryptocurrency to a merchant and receives goods or services. Simultaneously, the attacker
creates another transaction sending the same coins back to themselves. If the attacker succeeds in creating a
longer chain, the original payment disappears and the attacker retains both the coins and the purchased goods.
Effects of Double Spending
• Financial losses
• Fraudulent transactions
• Reduced trust in cryptocurrency
• Blockchain instability
Prevention
• Wait for multiple confirmations
• Increase network security
• Prevent 51% attacks
• Monitor suspicious transactions
Monopoly Problem in PoW
Introduction to Monopoly Problem
One of the major criticisms of Proof of Work is the possibility of mining monopolies. Over time, mining power
tends to become concentrated among a few large mining pools or organizations. This reduces decentralization
and gives significant control to a small group of participants.
Mining Pool Centralization
Mining pools are groups of miners who combine their computational power and share rewards. While mining
pools help small miners earn stable rewards, very large mining pools can accumulate excessive power.
If a few mining pools control most of the network's hash rate, they may influence transaction validation and
network governance. This contradicts the decentralized nature of blockchain systems.
Problems Caused
• Reduced decentralization
• Increased risk of collusion
• Higher possibility of 51% attacks
 • Unfair influence over network decisions
ASIC Monopoly
Application-Specific Integrated Circuits (ASICs) are specialized hardware devices designed for cryptocurrency
mining. These devices are extremely efficient compared to ordinary computers.
Large organizations can afford thousands of ASIC miners, while small miners often cannot compete. As a
result, mining power becomes concentrated among wealthy participants.
Problems Caused
• Expensive entry barrier
• Reduced participation
• Wealth concentration
• Mining centralization
Geographic Monopoly
Mining operations are often concentrated in regions with cheap electricity and favorable regulations. This
geographic concentration can create additional centralization risks.
If a large percentage of mining power exists within a single country or region, government regulations or
infrastructure failures may significantly affect the network.
Problems Caused
• Geographic concentration
• Regulatory risks
• Reduced network resilience
• Dependency on local resources
Solutions to Monopoly Problem
Encouraging Decentralization
The network should encourage participation from a larger number of independent miners. A wider distribution
of mining power improves security and reduces monopoly risks.
Mining Pool Monitoring
Large mining pools should be monitored to ensure they do not gain excessive control over the network.
Community awareness helps prevent dangerous concentration of hash power.
Alternative Consensus Mechanisms
Consensus mechanisms such as Proof of Stake (PoS) and Delegated Proof of Stake (DPoS) can reduce
dependence on expensive mining hardware and improve decentralization.
Geographic Distribution
Promoting mining operations across multiple countries reduces dependence on specific regions and improves
network stability.
Summary of PoW Attacks
Attack Purpose Impact
51% Attack Control majority hash power Double spending and transaction reversal
Selfish Mining Earn extra rewards Unfair profit and centralization
Sybil Attack Create fake identities Network manipulation
Double Spending Spend same coins twice Financial fraud

3(a) Two participants on the Ethereum blockchain intend to exchange Non-Fungible Tokens (NFTs) and
ERC-20 tokens directly through a smart contract, eliminating the need for a trusted intermediary. To
facilitate the transaction, an escrow-based smart contract is deployed to securely lock the assets of both
parties until all exchange conditions are satisfied.
Design and evaluate a trustless asset-swapping smart contract that enables the atomic and secure
exchange of NFTs and ERC-20 tokens. Describe the contract architecture, transaction workflow, and
escrow mechanism involved in the swap process. Analyze how the proposed solution ensures fairness,
prevents fraudulent behavior, and guarantees that either both asset transfers are completed successfully
or neither transfer occurs. (8 Marks)
Introduction
In traditional digital asset trading, users often depend on centralized exchanges or trusted third parties to
facilitate transactions. This introduces risks such as fraud, asset theft, platform failures, and high transaction
fees. Blockchain technology enables trustless asset exchange through smart contracts, allowing participants to
trade directly without intermediaries. An escrow-based smart contract securely holds the assets of both parties
and ensures that the exchange occurs only when all predefined conditions are satisfied.
Overview of Trustless Asset Swapping
A trustless asset swap allows two users to exchange assets without relying on a middleman. In this scenario, one
participant owns an NFT while the other participant owns ERC-20 tokens. Instead of trusting each other, both
parties trust the smart contract. The smart contract acts as an automated escrow agent that temporarily stores the
assets until the exchange conditions are fulfilled.
This approach eliminates counterparty risk because neither participant can cheat or withdraw the other's asset
without completing their own obligation.
Contract Architecture
The trustless asset-swapping system consists of several important components that work together to perform a
secure exchange.
Party A
Party A is the owner of the NFT. This participant wishes to exchange the NFT for a specific amount of ERC-20
tokens.
The NFT remains under Party A's ownership until it is deposited into the escrow contract. Once deposited, the
NFT is securely locked and cannot be accessed by Party A.
Party B
Party B is the owner of the ERC-20 tokens. This participant agrees to transfer a specified number of tokens in
exchange for the NFT.
The ERC-20 tokens are deposited into the escrow contract and remain locked until the swap conditions are
satisfied.
Escrow Smart Contract
The escrow smart contract acts as the trusted intermediary. It stores both assets temporarily and verifies whether
each participant has deposited the required asset.
The contract contains functions for asset deposit, verification, swap execution, and transaction cancellation if
necessary. Since the contract operates automatically according to predefined rules, human intervention is not
required.
NFT Contract
The NFT contract manages ownership and transfer of the Non-Fungible Token. The escrow contract interacts
with the NFT contract to receive and transfer NFT ownership securely.
ERC-20 Token Contract
The ERC-20 token contract manages token balances and transfers. The escrow contract communicates with this
contract to receive token deposits and transfer tokens after successful swap completion.
Escrow Mechanism
The escrow mechanism is the core component of the trustless swap system. It ensures that both assets are
locked before any transfer occurs.
When Party A deposits the NFT, the contract records that the NFT has been received. Similarly, when Party B
deposits the ERC-20 tokens, the contract records the token deposit.
The contract continuously checks whether both assets have been successfully deposited. If either asset is
missing, the swap cannot proceed. This guarantees that neither party can receive an asset without contributing
their own asset.
Transaction Workflow
Step 1: Swap Initialization
The smart contract is deployed with details of both participants, the NFT identifier, and the required ERC-20
token amount.
The contract stores the addresses of Party A and Party B and defines the conditions required for a successful
exchange.
Step 2: NFT Deposit
Party A transfers the NFT to the escrow smart contract.
The contract verifies ownership and confirms that the NFT has been received. The NFT remains locked within
the contract until the swap process is completed.
Step 3: ERC-20 Token Deposit
Party B transfers the agreed number of ERC-20 tokens to the escrow contract.
The contract verifies the token deposit and records that Party B has fulfilled their obligation.
Step 4: Deposit Verification
The smart contract checks whether both deposits have been successfully received.
Only when both conditions are satisfied does the contract allow the swap process to continue.
Step 5: Atomic Swap Execution
The smart contract simultaneously transfers the NFT to Party B and the ERC-20 tokens to Party A.
Both transfers occur within a single blockchain transaction. If any part of the transaction fails, the entire
transaction is reversed automatically.
Step 6: Completion
After successful execution, ownership records are updated and the transaction is permanently recorded on the
blockchain.
Both participants receive their new assets and the escrow contract no longer holds any assets.
Atomic Swap Concept
Atomicity is one of the most important features of this system. An atomic transaction means that either all
operations succeed or none of them occur.
In the asset-swapping process, both transfers are executed together. If the NFT transfer fails, the token transfer
also fails automatically. Similarly, if the token transfer fails, the NFT remains with the escrow contract.
This eliminates the possibility of partial completion and protects both participants from fraud.
Benefits of Atomic Swaps
• No partial transactions
• Eliminates counterparty risk
• Fair asset exchange
• Automatic rollback on failure
• Strong transaction integrity
Security Features
Fraud Prevention
The smart contract ensures that assets remain locked until both participants fulfill their obligations. This
prevents one party from receiving assets without providing their own.
Transparency
All transactions are recorded on the blockchain and can be verified by anyone. This creates a transparent and
auditable transaction history.
Immutability
Once the swap transaction is recorded, it cannot be altered or deleted. This ensures permanent proof of asset
ownership transfer.
Decentralization
No centralized authority or intermediary controls the transaction. The smart contract independently manages the
entire exchange process.
Secure Ownership Verification
The contract verifies NFT ownership and ERC-20 balances before accepting deposits. This prevents
unauthorized asset transfers.
Prevention of Fraudulent Behavior
The escrow mechanism prevents fraudulent behavior by ensuring that neither participant can access the other's
asset until both deposits are confirmed.
Since the smart contract automatically enforces the exchange rules, there is no opportunity for either party to
manipulate the transaction. Even if one participant attempts to cancel the process after depositing assets, the
contract follows predefined conditions and executes only valid operations.
This significantly reduces the risk of scams, disputes, and malicious behavior.
Architectural Diagram
Party A
(NFT Owner)
|
| NFT Deposit
v
--------------------------------
| Escrow Smart Contract |
--------------------------------
^
|
| ERC-20 Deposit
|
Party B
(Token Owner)
|
v
Verification of Deposits
|
v
Atomic Swap Execution
|
----------------------------
| |
v v
NFT transferred to B ERC-20 transferred to A
Advantages
The proposed trustless asset-swapping system eliminates the need for trusted intermediaries and significantly
reduces transaction risk. The escrow mechanism ensures fairness by requiring both parties to deposit assets
before the exchange occurs. Atomic transactions prevent partial execution and guarantee that both transfers
succeed together. The system also provides transparency, immutability, security, and reduced transaction costs
compared to traditional exchange methods.
Advantages
• Trustless asset exchange
• No intermediaries required
• Atomic transaction execution
• Strong security
• Fraud prevention
• Transparent transactions
• Reduced transaction costs
• Decentralized operation
3(b) Analyze the design of a decentralized blind auction system that uses Commit and Reveal phases to
hide bid values until the auction ends. Explain how hashed bid commitments and bid revelation ensure
fairness, prevent bid sniping, and determine the winning bidder. (7 Marks)
Introduction
A Blind Auction is a type of auction in which bidders keep their bid amounts hidden until the bidding period
ends. Unlike traditional auctions where participants can see competing bids and continuously increase their
offers, a blind auction prevents bidders from knowing the values submitted by others. This improves fairness
and prevents manipulative practices such as bid sniping. Blockchain technology further enhances blind auctions
by using smart contracts to securely manage bids, verify participants, and automatically determine the winner.
Decentralized Blind Auction
A decentralized blind auction operates on a blockchain network using smart contracts instead of a central
auctioneer. The smart contract manages the entire auction process, including bid submission, bid verification,
winner selection, and fund refunds.
Since all auction rules are encoded into the smart contract, no participant can manipulate the auction process.
Every action is recorded on the blockchain, ensuring transparency, security, and trust among participants.
Commit Phase
The Commit Phase is the first stage of the blind auction process. During this phase, bidders do not reveal their
actual bid amounts. Instead, they generate a cryptographic hash using their bid value and a secret password or
random number.
The generated hash is submitted to the smart contract and stored on the blockchain. Since only the hash is
visible, no one can determine the actual bid amount. This keeps all bids confidential during the auction period.
Purpose of Commit Phase
• Hides actual bid values
• Protects bidder privacy
• Prevents competitors from viewing bids
• Secures bid information using cryptographic hashing
Example
Bid Amount = 100 ETH
Secret = "ABC123"
Hash = H(100 + ABC123)
Only the hash is stored on the blockchain.
Hashed Bid Commitments
Hashed bid commitments are the foundation of the blind auction mechanism. A hash function converts bid
information into a fixed-length encrypted value. Even a small change in the bid amount produces a completely
different hash.
Because cryptographic hash functions are one-way functions, it is practically impossible to determine the
original bid value from the stored hash. This ensures that bid information remains confidential until the reveal
phase begins.
Benefits of Hash Commitments
• Bid secrecy
• Tamper resistance
• Data integrity
• Strong security
• Protection against bid manipulation
Reveal Phase
After the bidding deadline expires, the auction enters the Reveal Phase. During this stage, bidders submit their
original bid amount along with the secret value used during hash generation.
The smart contract recalculates the hash using the revealed information and compares it with the previously
stored hash. If both hashes match, the bid is accepted as valid.
This process proves that the bidder is revealing the same bid that was originally committed during the Commit
Phase.
Purpose of Reveal Phase
• Validates original bids
• Prevents bid alteration
• Confirms bidder authenticity
• Enables winner selection
Bid Verification Process
The smart contract performs automatic verification of each revealed bid. It compares the newly generated hash
with the stored commitment hash.
If:
Generated Hash = Stored Hash
The bid is accepted.
If:
Generated Hash ≠ Stored Hash
The bid is rejected.
This mechanism prevents bidders from changing their bid amounts after seeing competitors' bids.
Prevention of Bid Sniping
Bid sniping occurs when a participant waits until the last moment to observe other bids and then submits a
slightly higher bid to win the auction.
In a decentralized blind auction, bid sniping is impossible because no participant can see the actual bid values
during the Commit Phase. All bidders only see cryptographic hashes, which reveal no information about the
underlying bid amount.
Since bid amounts remain hidden until the Reveal Phase, participants must decide their bids independently
without knowing competitors' offers.
How Bid Sniping is Prevented
• Bid values remain hidden
• Competitors cannot view bids
• Last-minute manipulation is eliminated
• Equal opportunity for all bidders
Winner Determination
After all valid bids have been revealed and verified, the smart contract compares the bid amounts. The bidder
who submitted the highest valid bid becomes the winner of the auction.
The smart contract automatically identifies the highest bid and records the winner on the blockchain. This
process is completely transparent and does not require human intervention.
Winner Selection Steps
1. Collect all revealed bids.
2. Verify hash commitments.
3. Reject invalid bids.
4. Compare valid bid values.
5. Select highest bidder.
6. Announce winner.
Refund Mechanism
Participants who do not win the auction are allowed to withdraw their deposited funds using a refund or
withdraw function.
The smart contract securely stores refundable balances and transfers funds back to unsuccessful bidders. This
ensures fairness and prevents loss of funds.
Benefits of Refund System
• Secure fund recovery
• Fair treatment of participants
• Automated withdrawal process
 • Reduced disputes
Smart Contract Workflow
Step 1: Auction Creation
The auction creator deploys the smart contract and defines auction rules.
Step 2: Commit Phase
Bidders generate hashes and submit bid commitments.
Step 3: Storage of Hashes
The smart contract stores bid hashes securely on the blockchain.
Step 4: Reveal Phase
Bidders reveal their actual bids and secret values.
Step 5: Verification
The smart contract validates each bid using hash comparison.
Step 6: Winner Selection
The highest valid bid is identified automatically.
Step 7: Fund Distribution
Winner receives the auctioned asset, and unsuccessful bidders receive refunds.
Architectural Diagram
Bidder A
|
Hash(Bid+Secret)
|
v
---------------------
| Smart Contract |
---------------------
^
|
Hash(Bid+Secret)
|
Bidder B
----- Commit Phase -----
|
v
----- Reveal Phase -----
Reveal Bid + Secret Values
|
v
---------------------
| Verification |
---------------------
|
v
Highest Valid Bid Wins
|
v
Refund Others
Advantages
A decentralized blind auction provides strong privacy because bid values remain hidden until the reveal stage. It
prevents bid sniping, collusion, and manipulation by ensuring that competitors cannot observe each other's bids.
Smart contracts automate verification and winner selection, reducing human intervention and increasing trust.
The blockchain ledger provides transparency, immutability, and auditability throughout the auction process.
Advantages
• Bid privacy
• Prevention of bid sniping
• Transparent winner selection
• Automated verification
• Secure refunds
• Reduced fraud
• Decentralized operation
The decentralized blind auction system uses Commit and Reveal phases to ensure secure and fair bidding.
Hashed bid commitments hide bid values during the auction, while the Reveal Phase verifies bid authenticity
through cryptographic validation. This approach prevents bid sniping, protects bidder privacy, and guarantees
that the highest valid bidder is selected fairly. By leveraging blockchain and smart contracts, the system
provides transparency, security, and trust without requiring a central auction authority.

3(c) A medicine-transfer transaction is executed using Hyperledger Fabric chaincode. Evaluate the
effectiveness of the chaincode execution lifecycle (from installation to invoke) in ensuring security and
consistency. Justify your assessment and recommend suitable enhancements. Also, explain the steps and
commands in chaincode execution lifecycle with a sample medicine-transfer transaction chaincode. (10
Marks)
Introduction
Hyperledger Fabric is a permissioned blockchain platform designed for enterprise applications. It uses
Chaincode (Smart Contracts) to define business logic and automate transactions between participants. In a
pharmaceutical supply chain, chaincode can be used to manage medicine transfers between manufacturers,
distributors, pharmacies, and hospitals. The chaincode lifecycle ensures that smart contracts are securely
installed, approved, committed, and executed across the network while maintaining consistency and trust among
all participants.
Chaincode Execution Lifecycle
The chaincode lifecycle in Hyperledger Fabric consists of multiple stages that ensure all organizations agree on
the smart contract before it becomes active on the blockchain.
1. Chaincode Packaging
The first step is packaging the chaincode source code into a deployable format. Packaging creates a compressed
file containing the smart contract logic that can be distributed to all participating organizations.
This step ensures that all organizations receive the same chaincode version and prevents inconsistencies in
contract execution.
Command
peer lifecycle chaincode package [Link] \
--path ./medicine-transfer \
--lang golang \
--label medicine_1
2. Chaincode Installation
After packaging, the chaincode is installed on peer nodes of participating organizations. Installation makes the
smart contract available locally on the peer but does not yet activate it.
Each organization independently installs the chaincode on its peers to prepare for approval and execution.
Command
peer lifecycle chaincode install [Link]
3. Chaincode Approval
Every participating organization reviews and approves the chaincode definition. This step ensures that all
organizations agree on the chaincode version, endorsement policy, and execution rules.
Approval prevents unauthorized smart contracts from being deployed on the network.
Command
peer lifecycle chaincode approveformyorg \
--channelID pharmachannel \
--name medicinecc \
--version 1.0 \
--package-id <PACKAGE_ID> \
--sequence 1
4. Chaincode Commit
After receiving sufficient approvals, the chaincode definition is committed to the channel. Once committed, the
chaincode becomes active and available for execution by all authorized network participants.
This step establishes consensus among organizations regarding the chaincode configuration.
Command
peer lifecycle chaincode commit \
--channelID pharmachannel \
--name medicinecc \
--version 1.0 \
--sequence 1
5. Chaincode Invocation
Once the chaincode is committed, users can invoke its functions to execute transactions. In the pharmaceutical
supply chain, invocation may involve transferring medicine ownership from a manufacturer to a distributor.
The transaction proposal is sent to endorsing peers, executed, validated, and recorded on the ledger.
Command
peer chaincode invoke \
-C pharmachannel \
-n medicinecc \
-c '{"Args":["TransferMedicine","MED001","DistributorA"]}'

6. Query Execution
Users can query the blockchain to retrieve medicine details without modifying the ledger. Queries help track
medicine ownership and shipment status.
Command
peer chaincode query \
-C pharmachannel \
-n medicinecc \
-c '{"Args":["QueryMedicine","MED001"]}'
Sample Medicine Transfer Chaincode
The following simplified chaincode demonstrates medicine ownership transfer.
func TransferMedicine(ctx [Link],
medicineID string,
newOwner string) error {
medicine, err := [Link]().GetState(medicineID)
if err != nil {
return err
}
var med Medicine
[Link](medicine, &med)
[Link] = newOwner
updatedMedicine, _ := [Link](med)
return [Link]().PutState(
medicineID,
updatedMedicine)
}
Explanation
The chaincode retrieves medicine information from the ledger using the medicine ID. It updates the ownership
field with the new owner's name and stores the updated information back on the blockchain. Every ownership
transfer becomes permanently recorded and can be audited later.
Medicine Transfer Workflow
Step 1: Manufacturer Creates Medicine Record
The manufacturer registers the medicine batch on the blockchain by storing details such as medicine ID,
manufacturing date, batch number, and ownership information.
Step 2: Transfer Request
The manufacturer initiates a transfer request to send the medicine to a distributor.
Step 3: Chaincode Invocation
The TransferMedicine function is invoked through the chaincode.
Step 4: Endorsement
Endorsing peers execute the transaction proposal and generate endorsements according to the endorsement
policy.
Step 5: Ordering Service
The endorsed transaction is forwarded to the ordering service, which organizes transactions into blocks.
Step 6: Validation
Peers validate endorsements and verify compliance with endorsement policies.
Step 7: Ledger Update
The transaction is committed to the blockchain, and ownership of the medicine is updated.
Security Provided by Chaincode Lifecycle
Smart Contract Verification
Before activation, chaincode must be approved by participating organizations. This prevents malicious or
unauthorized smart contracts from being deployed.
Endorsement Policies
Hyperledger Fabric requires transactions to receive endorsements from specified organizations. This prevents a
single participant from manipulating transaction outcomes.
Example:
Manufacturer AND Distributor
Both organizations must approve the transaction before it becomes valid.
Access Control
Only authorized users can invoke specific chaincode functions. This prevents unauthorized modification of
medicine records.
Immutable Ledger
Once a medicine transfer is recorded, it cannot be altered or deleted. This ensures traceability and auditability.
Cryptographic Security
Digital signatures verify the identity of transaction participants and protect against tampering.
Consistency Provided by Chaincode Lifecycle
Uniform Smart Contract Execution
All peers execute the same chaincode logic, ensuring identical results across the network.
Consensus Validation
Transactions are validated according to endorsement policies before being committed.
Distributed Ledger Synchronization
All peers maintain synchronized copies of the ledger, ensuring consistency among participants.
Version Control
Chaincode lifecycle management ensures that all organizations operate using the same approved chaincode
version.
Evaluation of Effectiveness
The Hyperledger Fabric chaincode lifecycle is highly effective because it provides security, consistency, and
controlled governance. Multiple approval stages prevent unauthorized contract deployment, while endorsement
policies ensure trustworthy transaction validation. The lifecycle also guarantees that all organizations execute
the same business logic, eliminating discrepancies.
For pharmaceutical supply chains, this is especially important because medicine records must remain accurate,
tamper-proof, and traceable throughout the product lifecycle.
Recommended Enhancements
Integration with IoT Sensors
Temperature and humidity sensors can automatically update medicine storage conditions on the blockchain.
Multi-Level Endorsement Policies
Critical transactions can require approvals from multiple organizations for increased security.
AI-Based Anomaly Detection
Artificial intelligence can identify suspicious transactions or counterfeit medicine activities.
Automated Regulatory Compliance
Smart contracts can automatically verify compliance with pharmaceutical regulations before approving
transfers.
Real-Time Monitoring Dashboards
Organizations can track medicine movements and inventory status through blockchain dashboards.
Architecture Diagram
Manufacturer
|
v
Invoke Chaincode
|
v
+------------------+
| Endorsing Peers |
+------------------+
|
v
+------------------+
| Ordering Service |
+------------------+
|
v
+------------------+
| Validation Peers |
+------------------+
|
v
+------------------+
| Blockchain Ledger|
+------------------+
|
v
Distributor
The Hyperledger Fabric chaincode lifecycle provides a secure and consistent framework for executing
medicine-transfer transactions. Through packaging, installation, approval, commitment, and invocation, it
ensures that only authorized and verified smart contracts operate within the network. Features such as
endorsement policies, access control, immutable ledgers, and consensus validation make it highly suitable for
pharmaceutical supply chain management. By integrating advanced technologies such as IoT, AI, and
automated compliance monitoring, the effectiveness of the system can be further enhanced.

4(a) I – Case Study: Cross-Border Payments (8 Marks)

Traditional remittance services (like Western Union or international wire transfers) often take 3–5
business days and charge high percentage-based fees to send money globally. Propose a blockchain-based
payment solution to optimize this process. Detail which type of blockchain you would use, how you would
handle liquidity, and how your solution minimizes transaction times and costs.
Introduction
Cross-border payments involve transferring money from one country to another. Traditional payment systems
rely on multiple intermediaries such as banks, clearing houses, and payment processors. This increases
transaction costs and causes delays that can take several days. Blockchain technology can solve these issues by
enabling direct peer-to-peer transactions, reducing intermediaries, lowering costs, and providing near real-time
settlement.
Proposed Blockchain-Based Payment Solution
The proposed solution uses a blockchain network to facilitate international money transfers between senders
and receivers. Instead of relying on multiple correspondent banks, transactions are recorded directly on a
distributed ledger. Smart contracts automate payment processing and ensure secure transfer of funds.
The system enables users to send money instantly across borders while maintaining transparency, security, and
traceability.
Type of Blockchain
A Permissioned Blockchain such as Hyperledger Fabric or a consortium blockchain is the most suitable
choice for cross-border payment systems.
A permissioned blockchain allows only authorized financial institutions, banks, and payment providers to
participate in the network. This improves security, regulatory compliance, and transaction speed while
maintaining privacy.
Reasons for Choosing Permissioned Blockchain
• Controlled access
• Faster transaction processing
• Regulatory compliance
• Better privacy protection
• High scalability
• Reduced risk of unauthorized participation
Participants in the Network
Sender
The sender initiates the payment request through a digital wallet or banking application. The transaction details
are securely submitted to the blockchain network.
Receiving Customer
The receiver obtains the transferred funds through their digital wallet or linked bank account.
Participating Banks
Banks act as authorized nodes within the blockchain network and validate transactions.
Smart Contracts
Smart contracts automate transaction verification, currency conversion, and settlement processes.
Blockchain Nodes
Nodes maintain the distributed ledger and ensure that transactions are verified and permanently recorded.
Liquidity Management
Liquidity is one of the most important aspects of cross-border payment systems. The proposed solution can use
Stablecoins or Digital Settlement Tokens to facilitate currency exchange.
When a sender initiates a payment, the local currency is converted into a stablecoin. The stablecoin is
transferred through the blockchain network and converted into the recipient's local currency at the destination.
This eliminates the need for pre-funded nostro and vostro accounts typically required in traditional banking
systems.
Benefits of Stablecoin-Based Liquidity
• Instant settlement
• Reduced currency conversion delays
• Lower operational costs
• Improved liquidity availability
• Reduced dependence on correspondent banks
Transaction Workflow
Step 1: Payment Initiation
The sender enters the payment details, including recipient information and transfer amount.
The transaction request is submitted to the blockchain network.
Step 2: Currency Conversion
The sender's local currency is converted into a stablecoin or digital settlement asset.
This conversion ensures smooth movement of value across borders.
Step 3: Transaction Validation
Blockchain validators verify the transaction and ensure that all requirements are satisfied.
Consensus is achieved before the transaction is approved.
Step 4: Block Creation
The validated transaction is added to a new block and recorded on the blockchain ledger.
Step 5: Settlement
The stablecoin is converted into the receiver's local currency.
The recipient receives the funds directly into their wallet or bank account.
Step 6: Transaction Confirmation
Both sender and receiver receive immediate confirmation of the completed transaction.
The transaction remains permanently recorded on the blockchain.
Minimizing Transaction Time
Traditional international payments require multiple banks and intermediaries to process transactions. Each
intermediary introduces delays due to verification and settlement procedures.
Blockchain eliminates these intermediaries and enables direct value transfer between participants. Consensus
mechanisms such as PBFT or Raft provide rapid transaction validation, reducing settlement times from several
days to a few seconds or minutes.
Time Reduction Benefits
• Near real-time settlement
• Faster verification
• Reduced intermediary delays
• Immediate transaction confirmation
Minimizing Transaction Cost
Traditional payment systems charge multiple fees including banking fees, exchange fees, processing fees, and
intermediary charges.
Blockchain reduces these costs by automating processes through smart contracts and eliminating unnecessary
intermediaries. Since transactions occur directly on the blockchain, operational expenses are significantly
reduced.
Cost Reduction Benefits
• Lower transaction fees
• Reduced intermediary costs
• Automated processing
• Efficient currency conversion
 • Lower administrative expenses
Security Features
Cryptographic Security
Transactions are protected using advanced cryptographic algorithms that ensure data confidentiality and
integrity.
Immutability
Once a transaction is recorded, it cannot be modified or deleted, preventing fraud and unauthorized changes.
Transparency
All authorized participants can verify transaction records, increasing trust and accountability.
Distributed Ledger
Multiple nodes maintain identical copies of the ledger, eliminating single points of failure.
Architecture Diagram
Sender
|
v
------------------
| Smart Contract |
------------------
|
v
----------------------
| Blockchain Network |
----------------------
/ \
/ \
v v

Currency Transaction
Conversion Validation

\ /
\ /
v v
Recipient Bank
|
v
Receiver
Advantages of Blockchain-Based Cross-Border Payments
Blockchain-based cross-border payments offer faster settlement, lower transaction costs, improved
transparency, and enhanced security. The elimination of intermediaries reduces operational complexity and
improves overall efficiency. The use of stablecoins ensures smooth liquidity management and minimizes
foreign exchange risks.
Advantages
• Faster settlements
• Lower costs
• Improved transparency
• Enhanced security
• Better liquidity management
• Reduced dependence on intermediaries
• Real-time transaction tracking
The proposed blockchain-based cross-border payment system uses a permissioned blockchain, smart contracts,
and stablecoin-based liquidity management to provide fast, secure, and cost-effective international money
transfers. By eliminating intermediaries and automating settlement processes, the solution significantly reduces
transaction time and operational costs while maintaining transparency, security, and regulatory compliance.
This makes blockchain an ideal technology for modern cross-border payment systems.

4(a) I – Case Study: Cross-Border Payments (8 Marks)

Traditional remittance services (like Western Union or international wire transfers) often take 3–5
business days and charge high percentage-based fees to send money globally. Propose a blockchain-based
payment solution to optimize this process. Detail which type of blockchain you would use, how you would
handle liquidity, and how your solution minimizes transaction times and costs.
Introduction
Cross-border payments involve transferring money from one country to another. Traditional payment systems
rely on multiple intermediaries such as banks, clearing houses, and payment processors. This increases
transaction costs and causes delays that can take several days. Blockchain technology can solve these issues by
enabling direct peer-to-peer transactions, reducing intermediaries, lowering costs, and providing near real-time
settlement.
Proposed Blockchain-Based Payment Solution
The proposed solution uses a blockchain network to facilitate international money transfers between senders
and receivers. Instead of relying on multiple correspondent banks, transactions are recorded directly on a
distributed ledger. Smart contracts automate payment processing and ensure secure transfer of funds.
The system enables users to send money instantly across borders while maintaining transparency, security, and
traceability.
Type of Blockchain
A Permissioned Blockchain such as Hyperledger Fabric or a consortium blockchain is the most suitable
choice for cross-border payment systems.
A permissioned blockchain allows only authorized financial institutions, banks, and payment providers to
participate in the network. This improves security, regulatory compliance, and transaction speed while
maintaining privacy.
Reasons for Choosing Permissioned Blockchain
• Controlled access
• Faster transaction processing
• Regulatory compliance
• Better privacy protection
• High scalability
• Reduced risk of unauthorized participation
Participants in the Network
Sender
The sender initiates the payment request through a digital wallet or banking application. The transaction details
are securely submitted to the blockchain network.
Receiving Customer
The receiver obtains the transferred funds through their digital wallet or linked bank account.
Participating Banks
Banks act as authorized nodes within the blockchain network and validate transactions.
Smart Contracts
Smart contracts automate transaction verification, currency conversion, and settlement processes.
Blockchain Nodes
Nodes maintain the distributed ledger and ensure that transactions are verified and permanently recorded.
Liquidity Management
Liquidity is one of the most important aspects of cross-border payment systems. The proposed solution can use
Stablecoins or Digital Settlement Tokens to facilitate currency exchange.
When a sender initiates a payment, the local currency is converted into a stablecoin. The stablecoin is
transferred through the blockchain network and converted into the recipient's local currency at the destination.
This eliminates the need for pre-funded nostro and vostro accounts typically required in traditional banking
systems.
Benefits of Stablecoin-Based Liquidity
• Instant settlement
• Reduced currency conversion delays
• Lower operational costs
• Improved liquidity availability
• Reduced dependence on correspondent banks
Transaction Workflow
Step 1: Payment Initiation
The sender enters the payment details, including recipient information and transfer amount.
The transaction request is submitted to the blockchain network.
Step 2: Currency Conversion
The sender's local currency is converted into a stablecoin or digital settlement asset.
This conversion ensures smooth movement of value across borders.
Step 3: Transaction Validation
Blockchain validators verify the transaction and ensure that all requirements are satisfied.
Consensus is achieved before the transaction is approved.
Step 4: Block Creation
The validated transaction is added to a new block and recorded on the blockchain ledger.
Step 5: Settlement
The stablecoin is converted into the receiver's local currency.
The recipient receives the funds directly into their wallet or bank account.
Step 6: Transaction Confirmation
Both sender and receiver receive immediate confirmation of the completed transaction.
The transaction remains permanently recorded on the blockchain.
Minimizing Transaction Time
Traditional international payments require multiple banks and intermediaries to process transactions. Each
intermediary introduces delays due to verification and settlement procedures.
Blockchain eliminates these intermediaries and enables direct value transfer between participants. Consensus
mechanisms such as PBFT or Raft provide rapid transaction validation, reducing settlement times from several
days to a few seconds or minutes.
Time Reduction Benefits
• Near real-time settlement
• Faster verification
• Reduced intermediary delays
• Immediate transaction confirmation
Minimizing Transaction Cost
Traditional payment systems charge multiple fees including banking fees, exchange fees, processing fees, and
intermediary charges.
Blockchain reduces these costs by automating processes through smart contracts and eliminating unnecessary
intermediaries. Since transactions occur directly on the blockchain, operational expenses are significantly
reduced.
Cost Reduction Benefits
• Lower transaction fees
• Reduced intermediary costs
• Automated processing
 • Efficient currency conversion
• Lower administrative expenses
Security Features
Cryptographic Security
Transactions are protected using advanced cryptographic algorithms that ensure data confidentiality and
integrity.
Immutability
Once a transaction is recorded, it cannot be modified or deleted, preventing fraud and unauthorized changes.
Transparency
All authorized participants can verify transaction records, increasing trust and accountability.
Distributed Ledger
Multiple nodes maintain identical copies of the ledger, eliminating single points of failure.
Architecture Diagram
Sender
|
v
------------------
| Smart Contract |
------------------
|
v
-------------------
| Blockchain Network |
----------------------
/ \
/ \
v v
Currency Transaction
Conversion Validation

\ /
\ /
v v
Recipient Bank
|
v
Receiver
Advantages of Blockchain-Based Cross-Border Payments
Blockchain-based cross-border payments offer faster settlement, lower transaction costs, improved
transparency, and enhanced security. The elimination of intermediaries reduces operational complexity and
improves overall efficiency. The use of stablecoins ensures smooth liquidity management and minimizes
foreign exchange risks.
Advantages
• Faster settlements
• Lower costs
• Improved transparency
• Enhanced security
• Better liquidity management
• Reduced dependence on intermediaries
• Real-time transaction tracking
The proposed blockchain-based cross-border payment system uses a permissioned blockchain, smart contracts,
and stablecoin-based liquidity management to provide fast, secure, and cost-effective international money
transfers. By eliminating intermediaries and automating settlement processes, the solution significantly reduces
transaction time and operational costs while maintaining transparency, security, and regulatory compliance.
This makes blockchain an ideal technology for modern cross-border payment systems.

4(a) II – Analyzing Vulnerabilities

Many DApps rely on external data sources known as "Oracles" to execute smart contracts (e.g., a
decentralized insurance DApp needs to verify if a flight was delayed). Explain the "Oracle Problem" and
discuss how a compromised or manipulated oracle can lead to financial loss in a payment-based DApp. (8
Marks)
Introduction
Smart contracts are self-executing programs that run on a blockchain. They can automatically perform actions
when predefined conditions are met. However, blockchains cannot directly access information from the outside
world, such as weather reports, stock prices, flight statuses, or sports results. To obtain this external
information, blockchain applications use Oracles. An oracle acts as a bridge between the blockchain and
external data sources. Although oracles make smart contracts more useful, they introduce a major challenge
known as the Oracle Problem.
What is an Oracle?
An Oracle is a third-party service that collects information from the real world and provides it to a blockchain
smart contract. It acts as a communication channel between off-chain data sources and on-chain applications.
For example, a flight insurance smart contract may need to know whether a flight was delayed. Since the
blockchain cannot access airline databases directly, an oracle retrieves the flight information and sends it to the
smart contract.
Examples of Oracle Data
• Flight delays
• Weather information
• Stock market prices
• Currency exchange rates
• Sports results
• IoT sensor readings
The Oracle Problem
The Oracle Problem refers to the challenge of ensuring that external data supplied to a blockchain is accurate,
trustworthy, and free from manipulation. While blockchain transactions are secure and immutable, the
blockchain cannot verify whether the information received from an oracle is correct.
In simple terms, a blockchain is only as trustworthy as the oracle providing its external data. If the oracle
supplies incorrect information, the smart contract will still execute based on that incorrect information.
This creates a weak point in an otherwise secure blockchain system.
Why the Oracle Problem Exists
• Blockchains cannot access external data directly.
• Smart contracts depend on third-party data providers.
• Blockchain cannot verify real-world events independently.
• Incorrect oracle data leads to incorrect smart contract execution.
Working of Oracle-Based Smart Contracts
Consider a flight insurance DApp.
Step 1
A customer purchases flight insurance through a smart contract.
Step 2
The smart contract waits for flight status information.
Step 3
The oracle retrieves flight information from the airline database.
Step 4
The oracle sends the flight status to the smart contract.
Step 5
If the flight is delayed, the smart contract automatically releases compensation.
Step 6
If the flight is on time, no payment is issued.
In this process, the smart contract completely trusts the oracle's information.
Compromised Oracle
A compromised oracle is an oracle that has been hacked, manipulated, or intentionally provides false
information. Since smart contracts rely on oracle data, compromised oracles can cause incorrect contract
execution.
Attackers may compromise an oracle through cyberattacks, insider manipulation, software vulnerabilities, or
data tampering.
Example of Financial Loss in a Payment-Based DApp
Consider a decentralized crop insurance system.
A farmer purchases insurance against drought conditions.
The smart contract is programmed to pay compensation if rainfall drops below a certain level.
The oracle supplies weather information to the blockchain.
Normal Scenario
• Rainfall = 20 mm
• Drought condition detected
• Smart contract releases compensation
• Farmer receives payment
Manipulated Oracle Scenario
• Actual Rainfall = 100 mm
• Oracle falsely reports 20 mm
• Smart contract believes drought occurred
• Compensation is released incorrectly
As a result, the insurance company loses money because the payment was triggered based on false information.
Financial Loss Due to False Data
If attackers manipulate oracle data, they can force smart contracts to execute unauthorized payments. Since
blockchain transactions are irreversible, recovering the lost funds becomes extremely difficult.
Possible Financial Losses
• Unauthorized insurance payouts
• Incorrect loan approvals
• Fake compensation payments
• Manipulated trading decisions
• Fraudulent reward distributions
Oracle Manipulation in DeFi Platforms
Decentralized Finance (DeFi) applications heavily depend on price oracles.
For example, a lending platform may use an oracle to determine the price of cryptocurrency collateral.
If an attacker manipulates the oracle and artificially increases the asset price:
• The smart contract believes the collateral is highly valuable.
• The attacker borrows large amounts of funds.
• The attacker withdraws the funds.
• The asset price returns to normal.
• The lending platform suffers huge losses.
This type of attack has occurred in several DeFi protocols.
Risks Associated with Oracle Attacks
Incorrect Smart Contract Execution
Smart contracts execute automatically based on oracle data. Incorrect data results in incorrect execution.
Financial Fraud
Attackers can manipulate payment systems and receive unauthorized funds.
Loss of User Trust
Users lose confidence in the DApp if oracle failures cause financial losses.
Market Manipulation
Price oracle manipulation can affect trading platforms and lending protocols.
Systemic Risk
A single compromised oracle can impact thousands of smart contracts simultaneously.
Solutions to the Oracle Problem
Decentralized Oracles
Instead of relying on a single oracle, multiple independent oracles provide data. The smart contract accepts the
majority result.
This reduces the risk of manipulation.
Benefits
• Improved reliability
• Reduced single point of failure
• Better accuracy
Multiple Data Sources
Oracles should collect information from several trusted sources instead of relying on a single source.
This makes data manipulation more difficult.
Reputation-Based Oracle Systems
Oracle providers with a history of accurate reporting receive higher trust scores.
Malicious or inaccurate providers can be removed from the network.
Cryptographic Verification
Digital signatures and cryptographic proofs can verify the authenticity of oracle data.
This prevents unauthorized modifications.
Oracle Networks
Specialized oracle networks such as Chainlink use multiple independent nodes to provide reliable and tamper-
resistant data.
These networks significantly improve security.
Architecture Diagram
Real World Data
(Weather, Flight, Price)
|
v
+-----------+
| Oracle |
+-----------+
|
v
+-------------------+
| Smart Contract |
+-------------------+
|
-----------------
| |
v v
Payment No Payment
 Executed Executed
Advantages of Secure Oracle Systems
Secure oracle systems improve the reliability of blockchain applications by providing trustworthy external data.
They reduce the risk of financial fraud, improve smart contract accuracy, and increase user confidence in
decentralized applications.
Advantages
• Reliable external data
• Improved security
• Reduced fraud
• Better smart contract execution
• Enhanced trust
• Increased transparency
The Oracle Problem arises because blockchains cannot directly access real-world information and must depend
on external data providers called oracles. While oracles enable smart contracts to interact with real-world
events, they also introduce a significant security risk. A compromised or manipulated oracle can provide false
information, causing smart contracts to execute incorrect transactions and resulting in substantial financial
losses. Using decentralized oracle networks, multiple data sources, reputation systems, and cryptographic
verification can significantly reduce these risks and improve the security of blockchain-based payment
applications.

4(b) Explain the working of Sybil Attack, Selfish Mining and 51% Attack with suitable defense
mechanisms for each attack. (7 Marks)
Introduction
Blockchain networks are designed to provide security, transparency, and decentralization. However, malicious
users may attempt to exploit the network through various attacks. Among the most common attacks are Sybil
Attack, Selfish Mining Attack, and 51% Attack. These attacks can affect consensus, transaction validation,
and the overall trustworthiness of the blockchain. Therefore, understanding their working mechanisms and
defense strategies is important for maintaining a secure blockchain ecosystem.
1. Sybil Attack
Working of Sybil Attack
A Sybil Attack occurs when a malicious user creates multiple fake identities or nodes within a blockchain
network. Instead of participating as a single node, the attacker controls many fake nodes that appear to be
independent participants. These fake identities are then used to influence network decisions, manipulate voting
processes, or disrupt communication among honest nodes.
For example, if a blockchain network contains 100 nodes and an attacker creates 40 fake nodes, the attacker
gains significant influence over the network. Even though the nodes appear different, they are all controlled by
the same person.
Effects of Sybil Attack
• Creation of fake identities
• Manipulation of network decisions
• Reduced trust among participants
• Increased network congestion
• Threat to decentralization
Defense Mechanisms
Blockchain networks use consensus mechanisms that make creating multiple identities expensive.
• Proof of Work (PoW) requires computational power.
• Proof of Stake (PoS) requires financial stake.
• Identity verification in permissioned blockchains prevents fake participants.
• Resource-based participation increases attack cost.
2. Selfish Mining Attack
Working of Selfish Mining Attack
Selfish Mining is a strategy where a miner or mining pool does not immediately publish newly mined blocks to
the network. Instead, the miner secretly keeps the blocks and continues mining on a private chain.
When the private chain becomes longer than the public blockchain, the attacker releases it to the network. Since
blockchain protocols accept the longest valid chain, the attacker's chain becomes the official blockchain. Honest
miners who worked on the public chain lose their rewards because their blocks become invalid.
This gives selfish miners an unfair advantage and allows them to earn more rewards than honest participants.
Example
1. Attacker mines a block.
2. Instead of broadcasting it, the attacker keeps it private.
3. Attacker mines additional blocks secretly.
4. Private chain becomes longer than public chain.
5. Attacker releases private chain.
6. Network accepts attacker's chain.
7. Honest miners lose rewards.
Effects of Selfish Mining
• Unfair mining rewards
• Wastage of computational resources
• Increased centralization
• Reduced network efficiency
• Lower trust in the mining process
Defense Mechanisms
Several measures can reduce the effectiveness of selfish mining.
• Faster block propagation across the network.
• Improved consensus protocols.
• Monitoring suspicious mining behavior.
• Encouraging decentralization of mining pools.
• Limiting excessive concentration of hash power.
3. 51% Attack
Working of 51% Attack
A 51% Attack occurs when a miner or group of miners gains control of more than 50% of the total
computational power (hash rate) of the blockchain network. Since blockchain systems follow the longest-chain
rule, the attacker can generate blocks faster than the rest of the network.
With majority control, the attacker can create an alternative blockchain and force the network to accept it. This
allows the attacker to reverse transactions, perform double-spending attacks, and prevent other users'
transactions from being confirmed.
Example
Suppose a blockchain network has:
• Total Hash Power = 100 TH/s
• Honest Miners = 49 TH/s
• Attacker = 51 TH/s
Since the attacker controls the majority of mining power, they can continuously create the longest blockchain
and influence transaction validation.
Double Spending in 51% Attack
The attacker sends cryptocurrency to a merchant and receives goods or services. At the same time, the attacker
secretly mines an alternative blockchain where the payment never occurred.
After receiving the goods, the attacker releases the longer blockchain. The network accepts the attacker's
version, causing the original payment transaction to disappear. As a result, the attacker keeps both the
cryptocurrency and the purchased goods.
Effects of 51% Attack
 • Double spending
• Transaction reversal
• Blocking legitimate transactions
• Network manipulation
• Loss of user confidence
Defense Mechanisms
To reduce the risk of a 51% attack, blockchain networks should ensure mining power remains decentralized.
• Increase participation of independent miners.
• Prevent mining pool dominance.
• Encourage geographic distribution of miners.
• Monitor unusual hash power concentration.
• Require multiple transaction confirmations.
Comparison of Attacks
Attack Objective Impact Defense Mechanism
Sybil Attack Create fake identities Manipulate network decisions PoW, PoS, Identity Verification
Selfish Gain extra mining Wasted resources and Fast propagation, mining
Mining rewards centralization decentralization
Control majority hash Double spending and transaction Decentralization, hash power
51% Attack
power reversal distribution
Sybil Attack, Selfish Mining, and 51% Attack are major threats to blockchain networks. A Sybil Attack uses
multiple fake identities to influence network operations, Selfish Mining exploits hidden blocks to gain unfair
rewards, and a 51% Attack allows attackers to control transaction validation and perform double spending.
Effective defense mechanisms such as decentralization, proof-based participation, rapid block propagation, and
continuous monitoring help maintain blockchain security, fairness, and trustworthiness.

4(c) A multinational pharmaceutical enterprise plans to implement a blockchain-enabled supply chain

management platform to enhance the traceability, security, and efficiency of drug distribution from
production to end consumers. The system must support automated batch tracking, product recalls,
environmental condition monitoring, regulatory compliance management, counterfeit prevention, and
secure information exchange among stakeholders.
Develop a comprehensive blockchain-based smart contract architecture and workflow for this
pharmaceutical supply chain ecosystem. Select and justify suitable blockchain components, including
consensus protocols, oracle services, and security mechanisms. Explain how the proposed solution
leverages immutable records, trusted data feeds, and automated smart contract execution to ensure
product authenticity, real-time monitoring, privacy protection, and transparent verification of supply
chain activities. Illustrate the complete process through an architectural diagram showing the movement
of pharmaceutical products across manufacturers, distribution centers, pharmacies, and customers,
including mechanisms for handling exceptions such as recalls, compliance violations, and temperature
breaches. (10 Marks)
Introduction
The pharmaceutical industry requires a highly secure and transparent supply chain because medicines pass
through multiple stakeholders such as manufacturers, distributors, pharmacies, regulators, and consumers.
Traditional systems face problems such as counterfeit drugs, lack of transparency, data tampering, and delays in
product recalls. A blockchain-enabled pharmaceutical supply chain can solve these issues by providing
immutable records, automated smart contracts, real-time monitoring, and trusted information sharing among all
participants. This ensures drug authenticity, regulatory compliance, patient safety, and efficient supply chain
management.
Blockchain Platform Selection
A Hyperledger Fabric based permissioned blockchain is suitable for this application because pharmaceutical
data is sensitive and should only be accessible to authorized participants. Hyperledger provides privacy,
confidentiality, identity management, and high transaction throughput. Unlike public blockchains, only verified
organizations can participate in the network, making it ideal for enterprise healthcare applications.
Participants in the Pharmaceutical Network
Manufacturer
Manufacturers create medicine batches and register them on the blockchain. Information such as batch ID,
manufacturing date, expiry date, composition, and production details are permanently stored.
Distribution Centers
Distribution centers receive medicines from manufacturers and update logistics information. Every transfer of
ownership is recorded on the blockchain for traceability.
Pharmacies
Pharmacies verify medicine authenticity before selling products to customers. They update inventory and sales
information on the blockchain.
Regulatory Authorities
Regulators monitor compliance, inspect records, verify licenses, and ensure that all pharmaceutical operations
follow legal requirements.
Customers
Customers verify product authenticity using QR codes linked to blockchain records before purchasing
medicines.
Consensus Protocol
Practical Byzantine Fault Tolerance (PBFT)
PBFT is selected because it provides fast transaction confirmation and immediate finality without energy-
intensive mining. The pharmaceutical network contains trusted organizations rather than anonymous miners,
making PBFT highly suitable.
Advantages of PBFT
• Fast consensus
• Low energy consumption
• High throughput
• Immediate transaction finality
• Fault tolerance against malicious nodes
Smart Contract Architecture
1. Batch Registration Smart Contract
When a medicine batch is manufactured, the smart contract automatically stores:
• Batch Number
• Product Name
• Manufacturing Date
• Expiry Date
• Manufacturer Information
• Quantity Produced
This creates a tamper-proof digital identity for every medicine batch.
2. Ownership Transfer Smart Contract
This contract automatically records product movement between stakeholders.
Example
Manufacturer → Distributor → Pharmacy → Customer
Every transfer is validated and permanently recorded on the blockchain.
3. Compliance Verification Smart Contract
The contract automatically checks whether storage and transportation conditions satisfy regulatory
requirements.
Functions
• Validate transportation records
 • Verify certifications
• Check temperature requirements
• Monitor expiry dates
4. Recall Management Smart Contract
If a defective batch is identified, the smart contract automatically traces all affected locations and generates
recall notifications.
Benefits
• Rapid recall process
• Improved patient safety
• Reduced health risks
Oracle Services
Blockchain cannot directly access external information. Oracle services provide trusted real-world data to smart
contracts.
Environmental Monitoring Oracle
Collects data from IoT sensors.
Monitors:
• Temperature
• Humidity
• Storage Conditions
GPS Oracle
Provides shipment location information in real time.
Tracks:
• Delivery routes
• Shipment status
• Transportation history
Regulatory Oracle
Supplies compliance information from government databases.
Provides:
• Drug certifications
• License verification
• Regulatory updates
Security Mechanisms
Immutable Ledger
Every transaction is permanently stored and cannot be modified. This ensures data integrity and complete
traceability.
Digital Signatures
Every participant signs transactions using cryptographic keys, ensuring authentication and non-repudiation.
Access Control
Only authorized participants can access confidential pharmaceutical information.
Encryption
Sensitive business and healthcare data is encrypted before storage.
Audit Trail
Every activity is recorded, enabling complete tracking and auditing of pharmaceutical products.
Counterfeit Prevention
Counterfeit medicines are a major problem in pharmaceutical supply chains.
Each medicine package is assigned:
• Unique Product ID
• QR Code
• Blockchain Record
Customers can scan the QR code and verify:
 • Manufacturer details
• Batch information
• Distribution history
• Expiry date
This makes counterfeiting extremely difficult.
Real-Time Environmental Monitoring
Temperature-sensitive medicines such as vaccines require strict environmental control.
IoT sensors continuously monitor:
• Temperature
• Humidity
• Storage conditions
Sensor data is transmitted through oracle services to the blockchain.
If conditions exceed permissible limits, smart contracts immediately generate alerts.
Workflow of Pharmaceutical Supply Chain
Step 1: Manufacturing
Manufacturer creates medicine batch and registers batch details on the blockchain.
Step 2: Batch Registration
Smart contract generates a unique blockchain record for the batch.
Step 3: Distribution
Products are transferred to distribution centers and ownership records are updated.
Step 4: Transportation Monitoring
IoT sensors continuously monitor temperature, humidity, and location.
Step 5: Pharmacy Verification
Pharmacies verify authenticity before accepting products.
Step 6: Customer Purchase
Customer scans QR code and verifies medicine authenticity.
Step 7: Regulatory Monitoring
Regulators continuously monitor compliance records through the blockchain.
Exception Handling
Product Recall
If a defective medicine batch is discovered:
• Smart contract identifies affected batches.
• Notifications are sent automatically.
• Pharmacies stop selling the product.
• Recall process is recorded on blockchain.
Temperature Breach
If temperature exceeds safe limits:
• IoT sensor sends alert.
• Oracle updates blockchain.
• Smart contract flags the batch.
• Distribution is halted.
Compliance Violation
If transportation or storage rules are violated:
• Violation is recorded.
• Regulators are notified.
• Investigation process begins automatically.
Architectural Diagram
REGULATORY AUTHORITY
|
|
 v
-------------------------
| BLOCKCHAIN NETWORK |
| (Hyperledger Fabric) |
-------------------------
| | |
| | |
v v v

Manufacturer Distributor Pharmacy

| | |
| | |
--------------------------------
|
v

IoT Sensors
(Temperature, Humidity, GPS)
|
v

ORACLES
|
v
CUSTOMER
(QR Verification)

Recall Alerts | Compliance Alerts | Temperature Alerts

Generated Automatically by Smart Contracts
Advantages
The proposed blockchain solution provides complete visibility and transparency throughout the pharmaceutical
supply chain. Smart contracts automate tracking, recalls, compliance verification, and ownership transfer.
Oracle services enable real-time monitoring, while immutable blockchain records ensure authenticity and trust.
This significantly reduces counterfeit drugs, improves regulatory compliance, enhances patient safety, and
increases overall supply chain efficiency.
Advantages
• End-to-end traceability
• Counterfeit prevention
• Real-time monitoring
• Automated recalls
• Regulatory compliance
• Secure information exchange
• Data transparency
• Improved patient safety
A blockchain-enabled pharmaceutical supply chain using Hyperledger Fabric, PBFT consensus, smart
contracts, IoT sensors, and oracle services provides a secure, transparent, and efficient solution for drug
distribution. Immutable records ensure traceability, oracle services provide trusted real-time information, and
smart contracts automate critical operations such as batch tracking, recalls, compliance verification, and
ownership transfer. This architecture enhances product authenticity, privacy protection, operational efficiency,
and patient safety across the entire pharmaceutical ecosystem.