April 2026 answer key

Mark distribution: Definition (1.5 marks), Objectives (1.5 marks)

A Digital Signature is a cryptographic mechanism used to verify the authenticity and integrity of digital data or messages. It acts as a digital equivalent of a handwritten signature but is far more secure, utilizing asymmetric cryptography (public-private key pairs).

Primary Objectives:

1. Authentication: Verifies the identity of the sender, ensuring the message originated from the claimed source.
2. Integrity: Guarantees that the data has not been altered in transit. Any modification invalidates the signature.
3. Non-repudiation: Ensures the sender cannot later deny having signed or sent the message, as only they possess the private key.

Figure: Digital Signature Generation and Verification Process

Mark distribution: Definition (1.5 marks), Significance (1.5 marks)

The Avalanche Effect is a critical property of cryptographic hash functions where a minimal change in the input (even a single bit flip) results in a drastically and completely different output hash. Ideally, changing one bit should alter approximately 50% of the output bits.

Significance in Security:

1. Prevents Prediction: It ensures that attackers cannot deduce any relationship between two similar inputs by observing their corresponding hash outputs.
2. Mitigates Collision Attacks: By drastically changing the output for minor input variations, it becomes computationally infeasible to find two distinct inputs that produce the same hash.
3. Ensures Data Integrity: Even the slightest unauthorized modification to a file or message will produce a completely different hash, instantly revealing tampering.

Figure: Avalanche Effect demonstrating drastic output change for a single bit input modification

Mark distribution: Centralized (1 mark), Decentralized (1 mark), Distributed (1 mark)

Ledger technologies define how data is stored, managed, and accessed across a network. They are categorized based on their architectural control and data replication models.

Key Differences:

• Centralized: A single central authority controls and manages the ledger. All nodes rely on this central point, creating a single point of failure. Example: Traditional banking databases.
• Decentralized: There is no single central authority. Control is spread among multiple nodes or clusters, reducing the risk of a single point of failure while maintaining some structured hierarchy.
• Distributed: Data is replicated and synchronized across multiple independent nodes. A distributed ledger can be either centralized or decentralized, but it ensures high availability and fault tolerance through data replication.

Figure: Architectural comparison of Centralized, Decentralized, and Distributed networks

Mark distribution: Privacy (1 mark), Speed (1 mark), Efficiency (1 mark)

For a consortium of banks, a Private Blockchain (Permissioned Blockchain) offers significant advantages over a Public Blockchain by restricting network access to known, verified entities.

Key Advantages:

1. Privacy and Confidentiality: Only authorized participants (the consortium banks) can join the network, view transaction details, or read the ledger. This ensures sensitive financial data remains strictly confidential and compliant with regulatory frameworks.
2. Speed and Performance: With fewer, known nodes participating in the consensus mechanism, transaction throughput is significantly higher, and block confirmation times are much faster compared to global public networks.
3. Efficiency and Cost: Private blockchains eliminate the need for energy-intensive consensus mechanisms like Proof of Work. This results in lower operational costs, reduced energy consumption, and higher overall computational efficiency.

Figure: Advantages of Private Blockchain for a banking consortium

Mark distribution: Definition (1 mark), Impact (1 mark), Mitigation (1 mark)

A 51% Attack occurs when a single entity or colluding group gains control of more than 50% of the network's mining hash rate or validation stake. This majority control allows them to manipulate the blockchain's consensus mechanism.

Potential Impact:

• Double-Spending: The attacker can reverse confirmed transactions to spend the same coins twice.
• Block Manipulation: They can prevent new transactions from gaining confirmations or exclude specific validators from the network.
• Chain Reorganization: The attacker can create a secret fork and broadcast it to overwrite the honest chain.

Mitigation:
Larger networks with widely distributed validation power are highly resistant to such attacks. The exorbitant financial cost and computational resources required to acquire a majority stake or hash rate act as a strong economic deterrent.

Figure: Execution flow of a 51% Attack on a blockchain network

Mark distribution: Role: First block in blockchain (Block 0). Hardcoded. Ancestor of every other block. No previous hash. (3 marks)

The Genesis Block is the very first block in a blockchain network, commonly referred to as Block 0. It serves as the hardcoded foundation and the ultimate ancestor of every subsequent block in the chain. Because it is the first block, it does not contain a reference to a previous block; therefore, its previous hash field is empty (or set to a default value like all zeros). This hardcoded nature ensures that all nodes in the network start from the exact same initial state, establishing a single source of truth. In Bitcoin, the Genesis block also contains a special message embedded in its coinbase transaction by Satoshi Nakamoto, and it prevents any forks at the very beginning of the ledger, ensuring universal consensus on the starting point.

Figure: The Genesis Block serves as the foundational anchor for all subsequent blocks in the blockchain.

Mark distribution: Examples: Reentrancy Attack, Integer Overflow/Underflow, Timestamp Dependence. (3 marks)

Smart contracts are immutable and handle valuable assets, making them prime targets for exploits. Three primary security vulnerabilities include:

1. Reentrancy Attack: Occurs when a contract calls an external contract before updating its state, allowing the external contract to recursively call back into the original function and drain funds.
2. Integer Overflow/Underflow: Happens when arithmetic operations exceed the maximum or minimum limit of a data type (e.g., adding 1 to the maximum uint256 wraps around to 0), leading to unexpected balance manipulations.
3. Timestamp Dependence: Arises when contract logic relies on the block.timestamp for critical decisions. Since the block producer (a miner under PoW, a validator under PoS) has some freedom in setting the timestamp, this can be exploited to unfairly influence outcomes like lottery wins or auction endings.

Figure: Common smart contract security vulnerabilities and their exploitation mechanisms.

Mark distribution: Enhancement: Public ledger for spending, voting, land registry. Reduces corruption. (3 marks)

Blockchain technology significantly enhances transparency in government services by utilizing a public, immutable ledger to record critical administrative actions. Key applications include:

• Public Spending: Tracking the allocation and expenditure of taxpayer funds in real-time, ensuring every transaction is auditable and preventing misappropriation.
• Voting Systems: Creating tamper-proof digital voting records where every vote is cryptographically secured and publicly verifiable without compromising voter anonymity.
• Land Registry: Maintaining an immutable record of property ownership and transfer history, eliminating fraudulent claims and disputed titles.

By removing information asymmetry and providing a single, verifiable source of truth, blockchain reduces corruption, minimizes bureaucratic friction, and restores public trust in government institutions.

Figure: Blockchain integration in government services to ensure transparency and reduce corruption.

Mark distribution: Concept: Fee paid for computation. Prevents spam/infinite loops. (1.5 marks) Cost: Gas Limit * Gas Price. (1.5 marks)

In the Ethereum network, Gas is the unit measuring the amount of computational effort required to execute operations like transactions or smart contract interactions.

• Concept: Gas acts as a fee paid by the user to the validators. It is crucial because it prevents spam and protects the network from infinite loops or computationally heavy code; if a transaction runs out of gas, it fails, but the user still pays for the computation performed up to that point.
• Cost Calculation: The total transaction cost is calculated by multiplying the maximum amount of gas the user is willing to consume by the price they are willing to pay per unit of gas.

Total Fee = Gas Limit × Gas Price

(Note: Since the September 2022 Merge, Ethereum uses Proof of Stake, so fees are paid to validators rather than miners).

Figure: Gas consumption and transaction fee calculation flow in the Ethereum Virtual Machine.

Mark distribution: Mapping: Key-value store. (1.5 marks) Struct: Custom data type. (1.5 marks)

In Solidity, mapping and struct are essential data structures used to organize and store complex state variables efficiently.

• Mapping: A hash table that stores data as key-value pairs. It is highly efficient for lookups and does not have a length or iterable property. For example, mapping(address => uint) public balances; maps a user's wallet address to their token balance.
• Struct: Allows developers to define custom data types by grouping multiple related variables of different types under a single name. For example, struct User { string name; uint age; } creates a new type to hold a user's specific details.

Example Usage:

contract UserRegistry {
    struct User {
        string name;
        uint age;
    }
    mapping(address => User) public users;

    function register(string memory name, uint age) public {
        users[msg.sender] = User(name, age);
    }
}

This combination allows developers to map unique identifiers to complex, multi-field records seamlessly.

Figure: Relationship between Solidity mapping and struct data types for state management.

(a) Explain the SHA-256 algorithm. Describe the message padding and parsing process. (7 marks)

Mark distribution: Padding: 3 marks, Parsing: 4 marks

Figure: SHA-256 processing: padding, parsing into 512-bit blocks, message schedule and compression.

The SHA-256 (Secure Hash Algorithm 256-bit) is a widely used cryptographic hash function that takes an input of arbitrary length and produces a fixed-size 256-bit (32-byte) hash value. It is a fundamental building block in blockchain technology, utilized for securing data, mining (Proof of Work), and generating cryptographic addresses. The algorithm processes data in fixed-size blocks through a series of complex bitwise operations and modular additions.

Message Padding:
Before the actual hashing begins, the input message must be prepared so that its total length is an exact multiple of 512 bits. The padding process follows a strict sequence:

1. Append '1' bit: A single '1' bit is appended to the end of the original message.
2. Append '0's: Following the '1' bit, '0' bits are continuously appended until the length of the message is exactly 64 bits short of a 512-bit multiple.
3. Append Length: Finally, a 64-bit binary representation of the original message's length (before padding) is appended to the end.
   This ensures the final padded message length is perfectly divisible by 512, preparing it for the block parsing phase.

Parsing and Message Schedule:
Once padded, the message is parsed and broken down into consecutive 512-bit blocks. Each 512-bit block is further divided into sixteen 32-bit words. These 16 words are then expanded into a 64-word message schedule array (W0 to W63). This expansion is achieved using a specific bitwise function that involves right rotations, right shifts, and XOR operations on the initial 16 words. The resulting 64-word message schedule is subsequently fed into the main compression function, which processes the block and updates the internal hash state to produce the final 256-bit output.

Figure: SHA-256 message padding and block parsing process.

(b) Discuss Elliptic Curve Cryptography (ECC). Why is it preferred over RSA for blockchain applications despite similar security levels? (7 marks)

Mark distribution: ECC concept and key size: 3 marks, Benefits and blockchain preference: 4 marks

Elliptic Curve Cryptography (ECC) is a public-key cryptography approach based on the algebraic structure of elliptic curves over finite fields. It provides a highly efficient alternative to traditional algorithms like RSA by achieving the same level of cryptographic security with significantly smaller key sizes. The security of ECC relies on the difficulty of solving the elliptic curve discrete logarithm problem.

Key Size Equivalence:
The primary advantage of ECC is its high security-per-bit ratio. For instance, a 256-bit ECC key provides a similar level of security to a 3072-bit RSA key. This means ECC achieves the exact same cryptographic strength and resistance to brute-force attacks using only a fraction of the key size required by RSA.

Benefits and Blockchain Preference:
Because of the drastically smaller key sizes, ECC offers several operational benefits that make it the preferred choice for blockchain applications:

1. Faster Computation: Smaller keys require less computational power to perform encryption, decryption, and signature generation, leading to faster transaction processing.
2. Lower Storage Requirements: The compact size of ECC keys and signatures reduces the storage footprint on the blockchain ledger.
3. Reduced Bandwidth: Smaller payloads mean less data needs to be transmitted across the peer-to-peer network, improving overall network efficiency.

These benefits make ECC highly ideal for blockchain wallets, mobile devices, and IoT environments where computational resources, memory, and battery life are constrained. Consequently, major blockchain networks like Bitcoin and Ethereum utilize ECC (specifically the secp256k1 curve) for generating public-private key pairs and securing digital signatures.

Figure: Comparison of key sizes and resulting benefits of ECC for blockchain applications.

(a) Illustrate the working of Distributed Hash Tables (DHT) and their role in peer-to-peer networks. (7 marks)

Mark distribution: Concept and node responsibility: 3 marks, Working protocols and use cases: 4 marks

Distributed Hash Tables (DHT) are decentralized distributed systems that provide a lookup service similar to a traditional hash table. They allow participants in a network to store and retrieve key-value pairs in a fully decentralized manner without relying on a central coordinator or single point of failure.

Concept and Node Responsibility:
In a DHT, the total keyspace is partitioned and distributed among the participating nodes in the network. Each node is responsible for storing and managing a specific subset of keys. When a node wants to store a value for a given key, it uses a routing mechanism to forward the request to the specific node responsible for that key's region in the keyspace. This decentralized storage ensures that the network scales efficiently and remains highly resilient, as nodes can freely join or leave without disrupting the overall data availability.

Working and Protocols:
DHTs typically rely on structured overlay routing protocols like Kademlia or Chord to manage the network topology and route queries efficiently. These protocols organize nodes into a structured network, such as a circular ring or a binary tree. When a lookup is requested, the query is forwarded through the network, with each hop significantly reducing the distance to the target node. This results in a highly efficient lookup time complexity of O(log N), where N is the total number of nodes in the network.

DHTs form the foundational backbone for modern peer-to-peer networks. They are heavily utilized in systems like IPFS (InterPlanetary File System) for decentralized content addressing and file retrieval, and in BitTorrent for trackerless peer discovery, enabling massive scalability without central servers.

Figure: Distributed Hash Table network topology showing decentralized key-value storage.

(b) Explain the RSA digital signature algorithm. How does the verification process confirm the authenticity of the message? (7 marks)

Mark distribution: Signing process: 3 marks, Verification process: 4 marks

The RSA digital signature algorithm is a cryptographic mechanism used to verify the authenticity, integrity, and non-repudiation of a digital message. It leverages the mathematical properties of the RSA public-key cryptosystem, utilizing a pair of mathematically linked keys: a private key kept secret by the sender, and a public key shared openly.

Signing Process:
To create a digital signature, the sender first computes the cryptographic hash of the original message, denoted as Hash(M). The sender then encrypts this hash value using their own Private Key. The resulting encrypted hash serves as the digital signature. The sender then transmits both the original plaintext message and the digital signature to the intended receiver.

Verification Process:
Upon receiving the message and the signature, the receiver must verify its authenticity. The receiver independently computes the cryptographic hash of the received original message, generating a new Hash(M). Simultaneously, the receiver decrypts the received digital signature using the sender's publicly available Public Key to retrieve the original hash value that was signed.

The receiver then compares the two hash values. If the decrypted hash perfectly matches the newly computed Hash(M), it mathematically confirms two things:

1. Authenticity: The message was indeed signed by the holder of the corresponding private key, as only the private key could have generated a signature that successfully decrypts with the public key.
2. Integrity: The message has not been altered in transit, because any modification to the message would result in a completely different computed hash, causing the comparison to fail. A match guarantees the message is authentic and unaltered.

Figure: Sequence diagram illustrating the RSA digital signature signing and verification process.

(a) Describe the elements of a block in a blockchain. Explain the significance of the block header. (7 marks)

Mark distribution: Header fields and description (4 marks) + Significance of block header (3 marks)

A block is the fundamental data structure in a blockchain that stores a batch of validated transactions along with metadata linking it to the chain. Every block consists of two primary components: the Block Header and the Block Body.

Figure: Structure of a block in a blockchain showing header fields and body contents

Elements of a Block:

1. Block Header (typically 80 bytes in Bitcoin):

2. Block Body:

• Coinbase Transaction: The first transaction in every block, which creates new coins as a mining reward (block reward + transaction fees). This is the only transaction with no inputs.
• Regular Transactions: A list of validated transactions (typically thousands). Each transaction contains inputs (references to previous unspent outputs), outputs (new ownership conditions), and scripts that define spending conditions.

Significance of the Block Header:

1. Proof of Work Computation: The block header is the data that miners repeatedly hash during the mining process. Miners vary the Nonce field (and modify the coinbase transaction if the 32-bit nonce space is exhausted) until the SHA-256 hash of the header is below the difficulty target. The header is compact (80 bytes), making it efficient for hashing billions of times per second.

2. Chain Immutability and Linking: The Previous Block Hash field in each header creates an unbreakable cryptographic chain. If an attacker modifies any transaction in Block N, the Merkle Root changes, which changes Block N's hash, which invalidates the Previous Block Hash stored in Block N+1's header. This cascading effect makes tampering computationally infeasible — the attacker would need to re-mine all subsequent blocks.

3. Lightweight Verification (SPV): Simplified Payment Verification allows mobile and light clients to verify transaction inclusion without downloading the entire blockchain. A light client downloads only the block headers (80 bytes each) rather than full blocks (megabytes each). Using a Merkle Proof, the client can verify that a specific transaction exists in a block by checking a logarithmic number of hashes (O(log n)), saving enormous storage and bandwidth.

4. Block Validation: Full nodes use the header fields to quickly validate a block before processing its body — checking that the hash meets the difficulty target, the timestamp is within acceptable bounds, and the previous hash correctly references the chain tip.

(b) Analyze the different types of blockchain (Public, Private, Consortium) with examples and suitable use cases for each. (7 marks)

Mark distribution: Public blockchain (2 marks) + Private blockchain (2 marks) + Consortium blockchain (3 marks)

Blockchains are classified based on access permissions (who can read, write, and participate in consensus) and governance (who controls the network). The three primary types are Public, Private, and Consortium blockchains.

Figure: Classification of blockchain types based on access and governance

1. Public Blockchain (Permissionless Blockchain):

A public blockchain is a fully open, decentralized network where anyone can join without permission. Any individual or entity can read transactions, submit transactions, and participate in the consensus process (mining or validation).

Use Cases:

• Cryptocurrency transactions — peer-to-peer value transfer without intermediaries
• Decentralized Finance (DeFi) — lending, borrowing, and trading without banks
• Public record keeping — immutable, censorship-resistant storage of data
• NFTs and digital ownership — provable scarcity and ownership of digital assets

2. Private Blockchain (Permissioned Blockchain):

A private blockchain is a controlled network where access is restricted to authorized participants. A single organization owns, operates, and governs the network. Participants are known and verified before being granted access.

Use Cases:

• Internal supply chain tracking — a single company tracking goods across its operations
• Internal audit trails — immutable logging of internal processes and approvals
• Private asset management — managing internal digital assets with controlled access
• Inter-departmental workflows — streamlining processes across departments of one organization

3. Consortium Blockchain (Federated Blockchain):

A consortium blockchain is a permissioned network governed by a group of organizations rather than a single entity. Multiple pre-selected organizations operate nodes and share governance responsibilities. It balances the trust benefits of permissioned networks with the distributed governance of decentralized systems.

Use Cases:

• Inter-bank settlements — a consortium of banks (e.g., R3 CEFT with 100+ banks) processing cross-border payments and trade finance without a central intermediary
• Trade finance — multiple parties (banks, shipping companies, customs) sharing verified trade documents on a common ledger
• Healthcare data sharing — a group of hospitals sharing patient records securely while maintaining privacy regulations
• Insurance consortiums — multiple insurers sharing claims data to prevent fraud and streamline processing

Comparison Summary:

(a) Explain the concept of decentralization. Discuss the routes to decentralization as applied in blockchain ecosystems. (7 marks)

Mark distribution: Concept of decentralization (2 marks) + Routes to decentralization (5 marks)

Concept of Decentralization:

Decentralization is the distribution of authority, control, and decision-making away from a central entity to multiple participants spread across a network. In a decentralized system, no single point of control exists — power is shared among peers, and the system continues to function even if individual nodes fail or act maliciously.

In traditional systems (banks, governments, corporations), a central authority maintains databases, validates transactions, and enforces rules. This creates vulnerabilities: single points of failure, censorship, corruption, and dependency on trusted intermediaries. Blockchain technology achieves decentralization by replacing the central authority with a distributed network of nodes that collectively maintain a shared, immutable ledger through consensus protocols.

Figure: Comparison of centralized, decentralized, and distributed architectures

Key characteristics of decentralization in blockchain:

• No single point of failure — the network survives even if many nodes go offline
• Censorship resistance — no authority can block valid transactions
• Trust minimization — participants need not trust each other; the protocol enforces rules
• Open participation — anyone can join, validate, and contribute to the network

Routes to Decentralization in Blockchain Ecosystems:

Decentralization in blockchain is achieved through multiple complementary mechanisms that distribute power across different layers of the ecosystem.

1. Disintermediation (Peer-to-Peer Network Architecture):

Disintermediation removes trusted third parties (intermediaries) from transactions and replaces them with direct peer-to-peer (P2P) interactions governed by cryptographic protocols.

• In Bitcoin, users transact directly without banks. The P2P network propagates transactions and blocks across all nodes, ensuring every participant has a copy of the ledger.
• There is no central server — each node connects to multiple peers, forming a mesh network where data flows through redundant paths.
• This eliminates intermediary fees, reduces settlement times, and removes the risk of intermediary failure or corruption.
• Example: Bitcoin's P2P gossip protocol ensures that transactions and blocks are broadcast to all nodes without any central coordinator.

2. Competition (Consensus and Mining/Validation):

Competition among network participants ensures that no single entity can dominate the network. Blockchain protocols use economic incentives and competition to achieve consensus and distribute control.

• Proof of Work (PoW): Miners compete to solve cryptographic puzzles. The competition is open — anyone with hardware can participate. The longest valid chain wins, and the winning miner receives a block reward. This competition distributes block creation across many independent miners globally.
• Proof of Stake (PoS): Validators compete based on their economic stake. The protocol randomly selects validators proportional to their stake, ensuring that attacking the network requires acquiring a majority of the staked tokens — an economically prohibitive proposition.
• This competitive mechanism ensures that control is distributed among many independent actors whose economic interests align with network security.

3. Open Source Protocol (Governance and Development):

Blockchain protocols are typically open source, meaning the code is publicly auditable, forkable, and modifiable by the community. This route to decentralization ensures that no single entity controls the rules of the system.

• Protocol-level decentralization: The consensus rules (e.g., Bitcoin's 21 million coin cap, block size, difficulty adjustment) are encoded in open-source software. Any developer can review, propose changes, or fork the code.
• Governance decentralization: Changes to the protocol require broad community consensus. In Bitcoin, changes need agreement among miners, node operators, developers, and users. No single group can unilaterally alter the rules.
• Forkability: If a group disagrees with protocol changes, they can fork the blockchain, creating an independent version. This was demonstrated when Bitcoin Cash forked from Bitcoin in 2017 over block size disagreements. Forkability acts as a check against centralized control.
• Example: Ethereum's transition from PoW to PoS (The Merge, September 2022) was governed through open discussion among developers, validators, and the community via Ethereum Improvement Proposals (EIPs).

Figure: Three routes to decentralization in blockchain ecosystems

These three routes work together to create a multi-layered decentralized system where no single entity controls the network architecture, the consensus process, or the protocol rules — achieving what is known as full ecosystem decentralization.

(b) Discuss the limitations of blockchain technology regarding scalability and energy consumption. (7 marks)

Mark distribution: Scalability limitations (4 marks) + Energy consumption limitations (3 marks)

Despite its transformative potential, blockchain technology faces significant limitations in scalability and energy consumption that hinder its mass adoption and long-term sustainability.

1. Scalability Limitations:

Scalability refers to a blockchain network's ability to handle a growing number of transactions efficiently. Current blockchain networks suffer from severely limited throughput compared to traditional payment systems.

Root Causes of Scalability Issues:

• Block Size Limits: Bitcoin restricts block size to 1 MB (or ~4 MB with SegWit), limiting the number of transactions per block. Ethereum uses a gas limit per block rather than a strict size limit, but this still constrains throughput. These limits exist to ensure that all nodes can store and validate the blockchain, maintaining decentralization.

• Consensus Overhead: Every node in the network must validate every transaction. In PoW, miners compete to produce blocks, but only one block is added per interval, and all other work is wasted. In PoS, validators must reach agreement across the network, introducing communication overhead. This global replication of computation is inherently slower than centralized databases.

• Network Propagation Delay: Blocks and transactions must propagate across a global P2P network. Larger blocks take longer to propagate, increasing the risk of orphaned blocks (blocks mined simultaneously by different miners). This creates a fundamental trade-off: larger blocks increase throughput but reduce decentralization (only nodes with high bandwidth can keep up).

• State Bloat: As the blockchain grows, every full node must store the entire transaction history. Bitcoin's blockchain exceeds 500 GB; Ethereum's exceeds 1 TB. This storage requirement limits the number of participants who can run full nodes, threatening decentralization.

• Network Congestion and Fees: During high demand, transactions compete for limited block space, driving up fees. Ethereum gas prices can spike to hundreds of dollars during peak periods, making small transactions economically unviable.

Figure: Root causes and consequences of blockchain scalability limitations

Approaches to Address Scalability: Layer 2 solutions (Lightning Network, Rollups), sharding (Ethereum 2.0), and alternative consensus mechanisms aim to improve throughput while maintaining security and decentralization.

2. Energy Consumption Limitations:

Blockchain networks, particularly those using Proof of Work (PoW) consensus, consume enormous amounts of electrical energy, raising serious environmental and sustainability concerns.

• PoW Mining Energy Demand: In PoW, miners perform billions of hash computations per second using specialized hardware (ASICs). This computational work serves no purpose other than securing the network, yet it requires massive electricity. Bitcoin's annual energy consumption is estimated at approximately 150 TWh — comparable to the electricity consumption of entire countries like Poland or Argentina.

• Hardware Waste (E-Waste): Mining hardware becomes obsolete quickly as newer, more efficient ASICs are developed. Bitcoin mining generates significant electronic waste as miners constantly upgrade equipment. Short-lived mining rigs contribute to environmental degradation through improper disposal.

• Carbon Footprint: The environmental impact depends on the energy source. If mining operations rely on fossil fuels (coal, natural gas), the carbon emissions are substantial. While some miners use renewable energy (hydroelectric, solar), the majority of global mining has historically depended on cheap fossil fuel energy.

• Economic Waste: The electricity consumed by PoW mining represents a direct economic cost. Miners spend electricity to earn block rewards, and the difficulty adjustment ensures that mining profitability remains marginal — meaning nearly all revenue is consumed by operational costs (primarily electricity).

• Sustainability Concerns: As blockchain adoption grows, energy consumption scales proportionally. This trajectory is environmentally unsustainable and has drawn criticism from governments, environmental organizations, and the public. Several countries (China, Kosovo, Iran) have banned or restricted cryptocurrency mining due to energy concerns.

Note: Ethereum's transition to Proof of Stake in September 2022 (The Merge) reduced its energy consumption by approximately 99.95%, demonstrating that alternative consensus mechanisms can dramatically address energy concerns while maintaining network security.

(a) Explain the Raft consensus algorithm. How does it handle leader election and log replication? (7 marks)

Mark distribution: Leader Election (3 marks), Log Replication (4 marks)

Raft Consensus Algorithm:
Raft is a consensus algorithm designed to be understandable and provide the same fault tolerance as Paxos, but with a clear separation of concerns. It manages a replicated log of commands across a cluster of nodes, ensuring consistency even if some nodes fail. Raft operates under the assumption of Crash Fault Tolerance (CFT), meaning nodes may crash or become unavailable, but they are not malicious. The algorithm decomposes consensus into three relatively independent subproblems: Leader Election, Log Replication, and Safety.

1. Leader Election:
Raft uses a strong leader approach. At any given time, each server in the cluster is in one of three states: Leader, Follower, or Candidate.

• Followers are passive; they do not issue requests and simply respond to RPCs from Leaders and Candidates.
• Candidates initiate leader elections to become the new Leader.
• Leaders handle all client requests and manage log replication.

Leader Election Process:
Raft divides time into arbitrary-length intervals called Terms. Each term begins with an election. If a Candidate wins, it serves as Leader for the remainder of the term.

1. Timeout and Candidacy: Followers start as followers. If a Follower receives no communication (heartbeats) from a Leader for a randomized election timeout, it transitions to a Candidate.
2. Requesting Votes: The Candidate increments its current Term counter and starts a new election. It votes for itself and sends RequestVote RPCs to all other servers in the cluster.
3. Voting: A Follower votes for a Candidate if the Candidate's term is at least as large as the Follower's current term, and the Follower has not already voted in that term.
4. Winning: A Candidate becomes the Leader if it receives votes from a majority of the servers. Once elected, the Leader begins sending periodic Heartbeats (empty AppendEntries RPCs) to Followers to maintain its authority and prevent new elections.

Figure: Raft Leader Election sequence showing timeout, voting, and heartbeat mechanisms.

2. Log Replication:
Once a Leader is elected, it begins accepting client commands. Each command is encapsulated in a new entry and appended to the Leader's local log.

1. Appending and Replicating: The Leader sends AppendEntries RPCs in parallel to each Follower, containing the new log entry.
2. Committing: The Leader waits for a majority of the servers to acknowledge the replication of the entry. Once the majority has safely replicated the entry, the Leader considers it committed and applies it to its state machine.
3. Follower Application: Followers also apply committed entries to their own state machines.
4. Consistency Guarantee: Raft guarantees that if two servers have applied a given log entry at the same index, the entries will be identical. This is enforced by the Leader's log matching property: if a Follower's log conflicts with the Leader's at a given index, the Leader overwrites the Follower's conflicting entries.

Figure: Raft Log Replication flow showing command reception, parallel replication, majority acknowledgment, and state machine application.

(b) Compare Crash Fault Tolerance (CFT) and Byzantine Fault Tolerance (BFT) algorithms. (7 marks)

Mark distribution: CFT (3 marks), BFT (4 marks)

In distributed systems, fault tolerance refers to the ability of a system to continue operating correctly in the event of the failure of some of its components. The two primary categories of fault tolerance in consensus algorithms are Crash Fault Tolerance (CFT) and Byzantine Fault Tolerance (BFT).

1. Crash Fault Tolerance (CFT):
CFT algorithms are designed to handle crash failures, where a node simply stops functioning, crashes, or becomes temporarily disconnected from the network.

• Assumption: Nodes are assumed to be honest and non-malicious. They will not send incorrect or conflicting data; they will only fail by stopping.
• Mechanism: CFT algorithms like Raft and Paxos rely on a majority quorum (e.g., $N/2 + 1$ nodes out of $N$ total nodes) to make decisions. If a minority of nodes crash, the remaining majority can still reach consensus and keep the system running.
• Performance: CFT algorithms are generally highly efficient, offering high throughput and low latency because they do not need to verify the authenticity of messages or protect against malicious behavior.
• Use Cases: Ideal for permissioned, enterprise environments where all participating nodes are known, trusted, and operate under a single administrative domain (e.g., internal bank databases, Hyperledger Fabric using Raft).

2. Byzantine Fault Tolerance (BFT):
BFT algorithms are designed to handle Byzantine failures, which are the most severe type of failure. A Byzantine node may crash, but it can also act maliciously—sending conflicting messages, forging data, or intentionally trying to disrupt the consensus process.

• Assumption: Nodes can be malicious or compromised. The system must reach consensus even if some nodes are actively trying to subvert it.
• Mechanism: BFT algorithms like PBFT (Practical Byzantine Fault Tolerance), Proof of Work (PoW), and Proof of Stake (PoS) require a higher threshold of agreement. For traditional BFT (like PBFT), the system can tolerate up to $f$ faulty nodes only if there are at least $3f + 1$ total nodes (tolerates 1/3 traitors).
• Performance: BFT algorithms are more complex and typically have higher communication overhead and lower throughput compared to CFT. For example, PBFT requires multiple rounds of message exchange (Pre-prepare, Prepare, Commit) among all nodes.
• Use Cases: Essential for permissionless, decentralized environments like public blockchains (Bitcoin, Ethereum) where participants are anonymous, untrusted, and economically incentivized to attack the network.

Comparison Table:

Figure: Class diagram illustrating the inheritance and distinct properties of CFT and BFT fault tolerance models.

(a) Describe the structure of a Bitcoin transaction. Explain the roles of inputs, outputs, and scripts. (7 marks)

Mark distribution: Inputs (3 marks), Outputs (3 marks), Role/Scripts (1 mark)

A Bitcoin transaction is a digitally signed data structure that transfers value across the Bitcoin network. Unlike traditional bank accounts that maintain a balance, Bitcoin uses an Unspent Transaction Output (UTXO) model. A transaction does not hold a "balance"; rather, it consumes previous UTXOs as inputs and creates new UTXOs as outputs.

Structure of a Bitcoin Transaction:
A standard Bitcoin transaction consists of several key components:

1. Version: Specifies the transaction version (e.g., version 1 or 2) to indicate which rules apply.
2. Input Count: Number of inputs in the transaction.
3. Inputs: List of transaction inputs.
4. Output Count: Number of outputs in the transaction.
5. Outputs: List of transaction outputs.
6. Locktime: Specifies the earliest time or block height at which the transaction can be added to a block (default is 0, meaning immediate).

Figure: Structural breakdown of a Bitcoin transaction showing version, inputs, outputs, and locktime components.

1. Transaction Inputs:
Inputs are the sources of the Bitcoin being spent. They reference previously unspent outputs from older transactions.

• Previous Transaction Hash (TXID): A 32-byte hash pointing to the specific previous transaction that contains the UTXO being spent.
• Output Index (vout): A 4-byte integer indicating which output of the referenced transaction is being spent (e.g., 0 for the first output).
• ScriptSig (Unlocking Script): A variable-length script containing the cryptographic proof (digital signature and public key) that satisfies the locking conditions of the referenced UTXO. It proves the sender has the authority to spend the funds.
• Sequence Number: Originally intended for transaction replacement, now mostly used for locktime and relative time locks (e.g., 0xFFFFFFFF means final).

2. Transaction Outputs:
Outputs define where the Bitcoin is going and how much is being sent. Each output creates a new UTXO that can be spent in a future transaction.

• Value (Amount): An 8-byte integer representing the amount of Bitcoin being transferred, measured in Satoshis (1 BTC = 100,000,000 Satoshis).
• ScriptPubKey (Locking Script): A variable-length script that defines the conditions required to spend this output in the future. The most common is P2PKH (Pay-to-Public-Key-Hash), which locks the funds to a specific Bitcoin address.

3. Roles of Inputs, Outputs, and Scripts:

• Role of Inputs & Outputs: Together, they define the value transfer. The total value of all inputs must be greater than or equal to the total value of all outputs. The difference between the input sum and output sum is the transaction fee, which is claimed by the miner who includes the transaction in a block.
• Role of Scripts (Scripting Language): Bitcoin uses a simple, stack-based, non-Turing-complete scripting language. The ScriptSig (from the input) and ScriptPubKey (from the output) are concatenated and executed by the Bitcoin network nodes. If the combined script evaluates to TRUE, the transaction is valid, proving ownership and authorizing the transfer. This mechanism ensures that only the rightful owner can spend the UTXO.

Figure: Flow of value in a Bitcoin transaction showing inputs consuming UTXOs and outputs creating new UTXOs for the recipient and change. The miner fee is not an output; it is the leftover value (2.0 − 1.999 = 0.001 BTC) that the miner collects.

(b) Illustrate the concept of Wallets in Bitcoin. Differentiate between Hot and Cold wallets. (7 marks)

Mark distribution: Concept (2 marks), Hot Wallets (2.5 marks), Cold Wallets (2.5 marks)

Concept of Bitcoin Wallets:
A common misconception is that a Bitcoin wallet stores actual Bitcoins. In reality, a Bitcoin wallet does not store coins; the coins exist only on the blockchain as UTXOs. Instead, a wallet securely stores the user's cryptographic keys: the Private Key (used to sign transactions and prove ownership) and the Public Key (used to derive the Bitcoin address where funds are received). The wallet software manages these keys, constructs transactions, broadcasts them to the network, and tracks the UTXOs associated with the wallet's addresses.

Figure: Conceptual diagram of a Bitcoin wallet showing key generation, address derivation, and transaction signing.

Types of Wallets:
Bitcoin wallets are broadly categorized based on their connectivity to the internet, which directly impacts their security and convenience.

1. Hot Wallets:
Hot wallets are cryptocurrency wallets that are connected to the internet. They are typically software-based and designed for frequent, everyday transactions.

• Examples: Mobile wallets (e.g., Trust Wallet, MetaMask), desktop wallets (e.g., Exodus), and web-based exchange wallets (e.g., Binance, Coinbase).
• Convenience: Highly convenient for daily use, quick payments, and trading. They offer user-friendly interfaces and instant access to funds.
• Security: Because the private keys are stored on an internet-connected device, they are vulnerable to hacking, malware, phishing attacks, and remote exploits. If the device is compromised, the attacker can steal the private keys and drain the funds.
• Best Use Case: Storing small amounts of cryptocurrency for daily spending, trading, or interacting with decentralized applications (DApps).

2. Cold Wallets:
Cold wallets are cryptocurrency wallets that are completely offline and never connected to the internet. They are designed for long-term, secure storage of large amounts of cryptocurrency.

• Examples: Hardware wallets (e.g., Ledger Nano, Trezor) and Paper wallets (private keys printed or written on physical paper/metal).
• Convenience: Less convenient for frequent transactions. To spend funds, the user must physically connect the hardware wallet to a computer or manually import a paper wallet's keys, which takes time and effort.
• Security: Highly secure. Since the private keys are generated and stored offline, they are immune to remote hacking, malware, and online phishing attacks. The transaction signing happens internally on the offline device (for hardware wallets), and only the signed transaction is sent to the online network.
• Best Use Case: Long-term holding (HODLing), storing large amounts of wealth, and institutional custody.

Comparison Table:

Figure: Categorization of Bitcoin wallets into Hot (internet-connected) and Cold (offline) storage solutions.

(a) Define Decentralized Autonomous Organizations (DAO). Explain the structure and governance mechanism of a DAO. (7 marks)

Mark distribution: Definition: Organization runs on code. (2 marks) | Governance: Token holders vote on proposals. Smart contracts execute decisions automatically. No CEO. (5 marks)

A Decentralized Autonomous Organization (DAO) is an organizational structure whose rules, governance mechanisms, and operational logic are entirely encoded into smart contracts on a blockchain. Unlike traditional organizations that rely on hierarchical management, legal frameworks, and centralized leadership, a DAO operates autonomously through code. It is transparent, controlled collectively by its members, and typically lacks a central management structure or a Chief Executive Officer (CEO). Once deployed on the blockchain, the core rules cannot be altered unless a consensus mechanism defined within the code is met, ensuring trustless execution.

Structure of a DAO:
The structure of a DAO is fundamentally flat and code-driven, consisting of three primary components:

1. Smart Contracts (The Core Logic): These define the organization's rules, treasury management, and operational workflows. They act as the immutable "constitution" of the DAO.
2. Governance Tokens: Members hold native tokens that represent their stake, voting power, and ownership within the organization.
3. Treasury: A multi-signature wallet or smart contract-controlled fund that holds the DAO's assets, which can only be moved if a proposal passes.

Governance Mechanism:
The governance of a DAO is a continuous, transparent process driven by its community rather than a board of directors.

Figure: DAO Governance and Execution Flow

1. Proposal Creation: Any token holder can draft and submit a proposal (e.g., upgrading the protocol, changing fee structures, or allocating treasury funds).
2. Discussion and Debate: The community discusses the proposal on decentralized forums to gauge sentiment and refine the idea.
3. Voting Phase: Token holders cast their votes directly on the blockchain. Voting power is usually proportional to the number of governance tokens held or staked.
4. Quorum and Execution: If the proposal meets the predefined quorum (minimum participation threshold) and receives a majority of "Yes" votes, the smart contract automatically executes the decision. There is no need for manual intervention, bank approvals, or managerial sign-offs. If the quorum is not met or the vote fails, the proposal is rejected.

This mechanism ensures absolute transparency, as all votes and executions are recorded on the public ledger, eliminating the agency problems and opaque decision-making common in traditional corporate structures.

(b) Discuss the integration of Blockchain with Artificial Intelligence. How can blockchain improve data integrity for AI models? (7 marks)

Mark distribution: Integration: AI needs data; Blockchain provides trusted data. (2 marks) | Data Integrity: Immutable audit trail for AI training data prevents poisoning. Explainable AI. (5 marks)

The integration of Blockchain and Artificial Intelligence (AI) represents a powerful synergy where the strengths of one technology compensate for the inherent weaknesses of the other. AI systems, particularly deep learning models, require massive amounts of data to train, validate, and operate effectively. However, AI models are often "black boxes" that suffer from data opacity, centralization, and vulnerability to manipulation. Blockchain, conversely, is a decentralized, immutable ledger that excels at providing trusted, verifiable, and transparent data. By integrating the two, blockchain provides the secure data infrastructure that AI needs, while AI can optimize blockchain operations (e.g., smart contract auditing or consensus optimization).

Improving Data Integrity for AI Models:
One of the most critical vulnerabilities in AI is data poisoning, where malicious actors alter the training data to compromise the model's output. Blockchain fundamentally solves this through several mechanisms:

1. Immutable Audit Trail for Training Data:
   By hashing datasets and storing the cryptographic hashes on a blockchain, organizations can create an immutable, timestamped audit trail of the exact data used to train an AI model. Any subsequent attempt to alter the training data will result in a hash mismatch, instantly flagging the data as tampered. This guarantees the provenance and integrity of the data feeding the AI.

2. Decentralized Data Marketplaces:
   Blockchain enables the creation of decentralized data marketplaces where data providers can monetize their datasets without relying on centralized tech giants. Smart contracts ensure that data providers are compensated automatically and that the data delivered matches the agreed-upon specifications, reducing the risk of biased or malicious data injection.

3. Explainable AI (XAI) and Model Tracking:
   Blockchain can log every decision made by an AI model, along with the specific data inputs and model versions used at the time. This creates a transparent, tamper-proof log that allows auditors to trace back an AI's decision to its exact origin, fostering Explainable AI. This is particularly crucial in regulated industries like healthcare and finance, where understanding why an AI made a specific decision is a legal requirement.

Figure: Blockchain Integration with AI for Data Integrity

Through these mechanisms, blockchain ensures that AI models are trained on verified, untampered data, and their subsequent operations remain transparent and accountable, bridging the trust gap in autonomous AI systems.

(a) Explain the role of Oracles in blockchain. Differentiate between hardware and software oracles. (7 marks)

Mark distribution: Software: Online data (APIs, prices). (3 marks) | Hardware: Sensors (IoT, RFID) for supply chain. (3 marks) | Role: Feed real-world data to smart contracts. (1 mark)

Figure: Generic oracle data flow from external source to consumer contract.

Smart contracts are self-executing programs that run entirely within the deterministic, closed environment of a blockchain network (like the Ethereum Virtual Machine). Because of this isolated execution environment, smart contracts cannot natively access external, real-world data. This is where Oracles play a critical role.

Role of Oracles:
The primary role of an Oracle is to act as a secure bridge that feeds real-world data into smart contracts. Oracles fetch external information, verify it, and transmit it onto the blockchain so that smart contracts can execute their logic based on real-world events. Without oracles, smart contracts would be limited to internal blockchain state and could not interact with external variables like weather conditions, stock prices, or sports scores.

Types of Oracles:

1. Software Oracles:
   Software oracles interact with online sources of information and transmit real-time data to the blockchain. They typically pull data from existing internet infrastructure.

   • Data Sources: They utilize APIs, web scraping, and online databases.
   • Use Cases: Fetching real-time cryptocurrency prices (e.g., Chainlink price feeds), weather data for crop insurance smart contracts, flight status for delayed flight insurance, or stock market indices.
   • Characteristics: Highly scalable, fast, and capable of processing vast amounts of digital data continuously.

2. Hardware Oracles:
   Hardware oracles interface with the physical world through electronic sensors, IoT (Internet of Things) devices, and RFID tags. They translate physical real-world events into digital data that the blockchain can understand.

   • Data Sources: Physical sensors, barcode scanners, RFID readers, and IoT devices.
   • Use Cases: Supply chain management (tracking the temperature of a cold-chain shipment via IoT sensors), smart logistics (verifying when a shipping container physically passes through a port gate), and real estate (verifying physical access via smart locks).
   • Characteristics: Bridges the physical-digital divide, though they are susceptible to physical tampering or sensor degradation, requiring robust cryptographic verification.

Figure: Oracle Data Flow from External Source to Smart Contract

By utilizing both software and hardware oracles, blockchain ecosystems can extend their utility far beyond simple financial transactions, enabling complex, real-world decentralized applications.

(b) Elaborate on the application of blockchain technology in the Finance sector, specifically for cross-border payments. (7 marks)

Mark distribution: Problem: Slow, expensive (SWIFT). (2 marks) | Solution: Ripple/XRP. Instant settlement, low fees, 24/7. (5 marks)

The application of blockchain technology in the finance sector has disrupted traditional banking paradigms, with cross-border payments being one of the most transformative use cases.

The Problem with Traditional Cross-Border Payments:
Historically, international money transfers have relied on the SWIFT (Society for Worldwide Interbank Financial Telecommunication) network and a complex web of correspondent banks. This traditional system suffers from severe inefficiencies:

1. Slow Settlement Times: Transactions often take 3 to 5 business days to clear because they must pass through multiple intermediary banks across different time zones and regulatory jurisdictions.
2. High Costs: Each intermediary bank charges a fee for processing, currency conversion, and compliance checks, resulting in high transaction costs for the end user.
3. Limited Operating Hours: Traditional banking systems operate only during specific business hours and close on weekends and holidays, delaying processing.
4. Lack of Transparency: Senders often cannot track the exact status of their funds or predict the final exchange rate and fees until the transaction is complete.

The Blockchain Solution:
Blockchain technology, specifically through networks like Ripple (XRP Ledger) and various stablecoin protocols, provides a decentralized alternative that bypasses the need for correspondent banks.

1. Instant Settlement: Blockchain enables peer-to-peer value transfer without intermediaries. Transactions are validated by the network and settled in seconds or minutes, regardless of geographic borders.
2. Drastically Reduced Fees: By eliminating correspondent banks and their associated fees, blockchain networks reduce the cost of cross-border remittances to a fraction of a cent.
3. 24/7/365 Operation: Blockchain networks never sleep. Transactions can be initiated, validated, and settled at any time of the day, on weekends, and during holidays.
4. Liquidity and Currency Conversion: Networks like Ripple use digital assets (like XRP) as a bridge currency. Instead of pre-funding nostro/vostro accounts in every destination country, financial institutions can convert fiat to XRP, transfer it instantly, and convert it to the target fiat, freeing up massive amounts of trapped capital.
5. Transparency and Traceability: Every transaction is recorded on a public or permissioned ledger, allowing both the sender and receiver to track the payment in real-time with absolute certainty.

Figure: Traditional vs Blockchain Cross-Border Payment Flow

By transitioning to blockchain-based cross-border payment systems, financial institutions can offer faster, cheaper, and more transparent services, fundamentally modernizing global remittances and international trade finance.

(a) Explain the Ethereum Virtual Machine (EVM) architecture. How does it ensure platform independence? (7 marks)

Mark distribution: Stack-based architecture and 256-bit word size (2 marks); Platform independence, bytecode execution across OS/Hardware, and the "World Computer" concept (5 marks).

The Ethereum Virtual Machine (EVM) is the core runtime environment responsible for executing smart contracts on the Ethereum network. It operates as a state machine that processes transactions and updates the global state of the blockchain. Following the transition to Proof of Stake in September 2022, validators execute the EVM to verify state transitions rather than traditional miners.

EVM Architecture:
The EVM is fundamentally a stack-based architecture with a maximum stack depth of 1024. It utilizes a 256-bit word size, which is specifically chosen to natively support 256-bit cryptographic operations, such as Keccak-256 hashing and elliptic curve mathematics, making it highly efficient for blockchain-specific computations.

The architecture comprises several distinct memory areas:

1. Stack: Used for most EVM operations, operating on a Last-In-First-Out (LIFO) basis with 256-bit elements.
2. Memory: A volatile, byte-addressable linear memory used during contract execution. It expands dynamically and is wiped after execution.
3. Storage: A persistent, non-volatile key-value store (where both keys and values are 256-bit). It represents the contract's long-term state and is written to the blockchain.
4. Calldata: A read-only, non-persistent data region containing the function arguments and data passed during a transaction.

Figure: EVM Architecture showing core execution components and memory structures.

Platform Independence and the "World Computer":
The EVM ensures absolute platform independence through its use of bytecode. When a smart contract is written in a high-level language like Solidity, it is compiled into EVM bytecode rather than native machine code. This bytecode is a low-level, platform-agnostic instruction set.

Every node participating in the Ethereum network runs an independent implementation of the EVM. Because the bytecode is deterministic and strictly defined, it executes identically on any node, regardless of the underlying Operating System (Linux, Windows, macOS) or Hardware architecture (x86, ARM, etc.). This uniform execution environment guarantees that all nodes reach the exact same state transition given the same input, which is the foundational requirement for blockchain consensus. This global, synchronized execution of code across thousands of decentralized nodes is why Ethereum is famously referred to as the "World Computer".

(b) Develop a Solidity smart contract for a Simple Banking System. Include functions to deposit, withdraw, and check balance. (7 marks)

Mark distribution: Correct Solidity syntax, mapping for balances, payable deposit function, withdraw function with balance checks and transfers, and view function for checking balance (7 marks).

Below is the complete, compilable Solidity smart contract for a Simple Banking System. It utilizes a mapping to track user balances, a payable function to accept Ether deposits, a secure withdrawal function, and a view function to query balances.

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

contract SimpleBank {
    // State variable to store the balance of each address
    mapping(address => uint256) private balances;

    // Events to log banking activities
    event Deposit(address indexed user, uint256 amount);
    event Withdrawal(address indexed user, uint256 amount);

    // Function to deposit Ether into the bank
    function deposit() public payable {
        require(msg.value > 0, "Deposit amount must be greater than zero");

        // Update the sender's balance
        balances[msg.sender] += msg.value;

        // Emit event for frontend tracking
        emit Deposit(msg.sender, msg.value);
    }

    // Function to withdraw Ether from the bank
    function withdraw(uint256 amount) public {
        // Check if the user has sufficient balance
        require(balances[msg.sender] >= amount, "Insufficient balance");

        // Update the balance before transferring to prevent reentrancy
        balances[msg.sender] -= amount;

        // Transfer the Ether to the sender
        payable(msg.sender).transfer(amount);

        emit Withdrawal(msg.sender, amount);
    }

    // Function to check the balance of the caller
    function getBalance() public view returns (uint256) {
        return balances[msg.sender];
    }
}

Logic Explanation:

1. State Management: The balances mapping associates each user's address with their uint256 balance. It is marked private to enforce encapsulation, allowing access only through the getBalance() function.
2. Deposit Function: The deposit() function is marked payable, allowing it to receive Ether. The msg.value global variable automatically captures the amount of Ether sent. The balance is updated, and a Deposit event is emitted.
3. Withdraw Function: The withdraw(amount) function first uses a require statement to ensure the user's mapped balance is greater than or equal to the requested amount. Crucially, the state (balance) is updated before the external call (transfer) to mitigate reentrancy vulnerabilities. The transfer function sends the Ether and automatically reverts the transaction if it fails.
4. View Function: The getBalance() function is marked view, meaning it reads state without modifying it and costs no gas when called off-chain.

Figure: Sequence flow illustrating the deposit and withdrawal logic in the Simple Banking contract.

(a) Describe the concept of Events and Logging in Solidity. How are they useful for DApp front-ends? (7 marks)

Mark distribution: Concept of events, event declaration, emit keyword, and storage in transaction logs (3 marks); Usefulness for DApp front-ends, Web3 listening, and cheaper storage compared to state variables (4 marks).

Concept of Events and Logging:
In Solidity, Events are inheritable members of contracts that allow developers to log specific occurrences during smart contract execution. When an event is triggered using the emit keyword, the EVM generates a log entry in the block's transaction receipt.

The arguments passed to the event are stored in a special data structure called the transaction log, which is a map of addresses to log entries. These logs are permanently recorded on the blockchain and are indexed for efficient retrieval. However, unlike state variables, log data is not accessible from within the smart contract code itself; it is strictly designed for external consumption.

// Example of Event Declaration and Emission
contract Payments {
    event FundsTransferred(address indexed sender, address indexed receiver, uint256 amount);

    function transferFunds(address payable receiver) public payable {
        receiver.transfer(msg.value);
        emit FundsTransferred(msg.sender, receiver, msg.value);
    }
}

Usefulness for DApp Front-ends:
Events are the primary communication bridge between a deployed smart contract and a Decentralized Application (DApp) front-end.

1. Efficient UI Updates via Web3.js/Ethers.js: Front-end applications (using libraries like Web3.js or Ethers.js) can subscribe and listen to specific events. When the smart contract emits an event, the blockchain node pushes a notification to the listening front-end. This allows the UI to update instantly and efficiently in real-time without the need for continuous, gas-costly polling of the contract's state variables.
2. Cheaper Storage Mechanism: Storing data in the blockchain's state (Storage) is extremely expensive in terms of Gas. Storing data in transaction logs via events is significantly cheaper. For historical data that the smart contract itself doesn't need to compute against (like a history of past transfers or auction bids), emitting an event is the most cost-effective way to record it on-chain for the front-end to display.

Figure: Data flow of Solidity events from smart contract execution to DApp frontend UI updates.

(b) Develop a Solidity smart contract for a Crowdfunding Campaign. The contract should accept contributions and allow the owner to withdraw only if the goal is met. (7 marks)

Mark distribution: Target amount, deadline, and raised amount logic (1 mark); contribute() payable function tracking contributions (2 marks); withdrawOwner() restricted to owner and goal met (2 marks); refund() logic for failed campaigns (2 marks).

Below is the complete Solidity smart contract for a Crowdfunding Campaign. It includes a constructor to set the campaign parameters, a payable function to accept contributions, a withdrawal function for the owner, and a refund mechanism for contributors if the funding goal is not reached.

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

contract Crowdfunding {
    address public owner;
    uint256 public targetAmount;
    uint256 public deadline;
    uint256 public raisedAmount;
    bool public fundsWithdrawn;

    // Mapping to track individual contributions
    mapping(address => uint256) public contributions;

    // Events for tracking campaign state
    event Contributed(address indexed contributor, uint256 amount);
    event FundsWithdrawn(address indexed owner, uint256 amount);
    event Refunded(address indexed contributor, uint256 amount);

    // Constructor to initialize the campaign
    constructor(uint256 _targetAmount, uint256 _durationInSeconds) {
        owner = msg.sender;
        targetAmount = _targetAmount;
        deadline = block.timestamp + _durationInSeconds;
    }

    // Function for users to contribute to the campaign
    function contribute() public payable {
        require(block.timestamp < deadline, "Campaign has ended");
        require(msg.value > 0, "Contribution must be greater than zero");

        contributions[msg.sender] += msg.value;
        raisedAmount += msg.value;

        emit Contributed(msg.sender, msg.value);
    }

    // Function for the owner to withdraw funds if the target is met
    function withdrawOwner() public {
        require(msg.sender == owner, "Only owner can withdraw");
        require(block.timestamp >= deadline, "Campaign not yet ended");
        require(raisedAmount >= targetAmount, "Target not met");
        require(!fundsWithdrawn, "Funds already withdrawn");

        fundsWithdrawn = true; // update state before transfer (prevents reentrancy and double withdrawal)
        uint256 amount = address(this).balance;
        payable(owner).transfer(amount);

        emit FundsWithdrawn(owner, amount);
    }

    // Function for contributors to claim a refund if the target is not met
    function refund() public {
        require(block.timestamp >= deadline, "Campaign not yet ended");
        require(raisedAmount < targetAmount, "Target was met, no refund");
        require(contributions[msg.sender] > 0, "No contribution to refund");

        uint256 amount = contributions[msg.sender];
        contributions[msg.sender] = 0; // Reset contribution to prevent double claims
        payable(msg.sender).transfer(amount);

        emit Refunded(msg.sender, amount);
    }
}

Logic Explanation:

1. Initialization: The constructor sets the owner to the deployer, defines the targetAmount, and calculates the deadline by adding the duration to the current block.timestamp.
2. Contributions: The contribute() function is payable. It first checks that the campaign is still active (before the deadline). It then updates the user's specific contribution in the mapping and increments the total raisedAmount.
3. Owner Withdrawal: The withdrawOwner() function enforces strict access control (msg.sender == owner). It ensures the deadline has passed and the raisedAmount meets or exceeds the targetAmount. It then sets fundsWithdrawn = true before transferring the collected funds to the owner, so the owner cannot withdraw twice. raisedAmount is left unchanged, so the campaign still counts as successful and contributors cannot claim refunds afterwards.
4. Refund Mechanism: If the deadline passes and the targetAmount was not met, the refund() function allows contributors to reclaim their funds. It checks the user's mapped contribution, resets it to zero to prevent multiple refund claims, and transfers the Ether back to the contributor.

Figure: Flowchart illustrating the state transitions and logic flow of the Crowdfunding smart contract.