September 2026 answer key

Mark distribution: Definition/Foundation (1 mark), Features (1 mark), Use in blockchain (1 mark)

Elliptic Curve Cryptography (ECC) is an asymmetric cryptographic system based on the discrete logarithm problem founded upon elliptic curves over finite fields.

Features: It provides equivalent security to RSA with significantly smaller key sizes (e.g., 256-bit ECC ≈ 3072-bit RSA). This results in faster computations, lower power consumption, and reduced storage and bandwidth requirements, making it highly efficient.

Use in Blockchain: Blockchain signing typically uses ECC, such as the Elliptic Curve Digital Signature Algorithm (ECDSA), for its efficiency and security with shorter key lengths. It is extensively used for generating public-private key pairs, creating account addresses, and digitally signing transactions in networks like Bitcoin (using the secp256k1 curve) and Ethereum.

Figure: Point doubling over R in Elliptic Curve Cryptography.

Mark distribution: Definition (1 mark), Working/Example (1.5 marks), Advantage/Use (0.5 marks)

A Merkle tree is a binary tree data structure where each leaf node contains the cryptographic hash of a data block (transaction), and each non-leaf node contains the hash of its child nodes, culminating in a single root hash called the Merkle root.

Working and Example: Consider four transactions with hashes A, B, C, and D. The leaf nodes are hashed in pairs to form parent nodes: Hash AB = SHA-256(A + B) and Hash CD = SHA-256(C + D). Finally, the parent nodes are hashed together to form the Merkle root: Root = SHA-256(AB + CD). This structure allows efficient verification of data integrity and membership (Simplified Payment Verification) without needing to download the entire dataset, as any change in a leaf propagates up and changes the root.

Figure: Merkle tree structure showing leaf hashes combined to form the root hash.

Mark distribution: Proof-based (1.5 marks), Fault Tolerant-based (1.5 marks)

Proof-based Consensus: In this mechanism, nodes compete in a leader-election lottery (e.g., solving computational puzzles), and the node that wins proposes the final value. It is used in fully decentralized, permissionless blockchains (e.g., PoW in Bitcoin). It scales very well but performs slowly due to compute-intensive operations.

Fault Tolerant-based Consensus: This traditional approach involves no compute-intensive operations. Instead, it relies on nodes publishing and verifying signed messages in a number of phases or rounds until an agreement is reached. It is used in permissioned or consortium blockchains (e.g., PBFT, Paxos, Raft). It performs well with a limited number of nodes but does not scale well for large networks.

Figure: Classification of consensus mechanisms in blockchain.

Mark distribution: Disintermediation (1.5 marks), Competition (1.5 marks)

There are two primary methods to achieve decentralization in blockchain:

1. Disintermediation: This involves removing intermediaries (middlemen) from transactions or processes to create direct peer-to-peer connections. For example, sending money directly to a friend in another country without relying on a bank. This achieves complete decentralization.

2. Competition (Contest-driven decentralization): Different service providers compete with each other to be selected for the provision of services. For instance, smart contracts can choose an external data provider based on reputation, previous scores, reviews, and quality of service. This cultivates an environment of competition and achieves partial decentralization by preventing monopolies.

Figure: Scale of decentralization showing conventional, competing intermediaries, and complete disintermediation.

Mark distribution: Definition (1 mark), Purpose/Inputs (1 mark), Maturity Rule (1 mark)

A coinbase transaction (also known as a generation transaction) is a special type of transaction that is always the very first transaction in a newly mined block.

Key Characteristics:

• No Inputs: Unlike regular transactions, it does not reference any previous transaction outputs. Instead, it contains a special coinbase data field.
• Block Reward: It creates new cryptocurrency out of thin air to pay the block reward (newly minted coins) and accumulated transaction fees to the miner who successfully created the block.
• Maturity Rule: The newly generated coins cannot be spent until a certain number of blocks (e.g., 100 blocks in Bitcoin) have been added to the chain. This prevents issues in case the block is later declared stale or orphaned during a blockchain reorganization.

Figure: Position and purpose of the coinbase transaction within a block.

Mark distribution: Concept of decentralized identity (1 mark), Mechanism (1 mark), Examples/Standards (1 mark)

Blockchain-based digital identity, or decentralized identity, shifts control of personal credentials from centralized authorities back to the individual identity holder. Instead of relying on a single central server to verify who a user is, the identity is cryptographically secured on a distributed ledger. This enables users to control exactly when, how, and with whom they share their credentials, solving privacy and data breach issues inherent in traditional Web 2 systems. The identity is typically represented using Decentralized Identifiers (DIDs), a standard developed by the W3C. Prime examples include Microsoft’s Identity Overlay Network (ION) built on the Bitcoin blockchain, as well as similar initiatives by IBM. This model ensures that identity verification is trustless, user-centric, and resistant to single points of failure, allowing seamless and secure authentication across various decentralized applications without exposing underlying personal data.

Mark distribution: Inbound Oracle definition (1 mark), Outbound Oracle definition (1 mark), Examples for both (1 mark)

In the context of smart contracts, oracles bridge the gap between the trustless blockchain and external systems. They are broadly categorized into inbound and outbound oracles based on the direction of data flow.

Inbound Oracles: These receive incoming data from external off-chain services and feed it into the smart contract. They allow the contract to react to real-world events. Example: A crop insurance smart contract receiving weather data from an external meteorological API to automatically trigger a payout.

Outbound Oracles: These allow smart contracts to send data out to external systems, triggering actions or events in the off-chain world. Example: A smart contract notifying an external IoT system to unlock a smart lock, or sending a payment instruction to a traditional banking API to release fiat currency.

Figure: Data flow of Inbound and Outbound Oracles.

Mark distribution: Definition of double spending (1 mark), Resolution mechanism in Bitcoin (1.5 marks), Brief explanation of how it works (0.5 marks)

The double-spending problem occurs in digital currency systems when the same digital token or coin is spent more than once. Since digital data can be easily copied, this is a critical issue that undermines the integrity of the currency.

Bitcoin resolves this problem in a completely trustless environment using a combination of its Proof of Work (PoW) consensus mechanism and the blockchain (an ordered list of blocks). When a transaction is broadcast, miners validate it and group it into a block. The PoW mechanism requires significant computational effort to add a block, ensuring that miners have spent resources. Once added, the transaction is cryptographically secured and linked to previous blocks. If a malicious actor attempts to broadcast a conflicting transaction (double spend), the network nodes will only accept the transaction that is included in the longest valid chain, effectively rejecting the duplicate and preventing fraud.

Figure: Bitcoin transaction validation and block addition flow.

Mark distribution: Control mechanism (1 mark), Code presence (1 mark), Message/Transaction initiation (1 mark)

In Ethereum, accounts are the building blocks used to interact with the blockchain. They are divided into two types: Externally Owned Accounts (EOAs) and Contract Accounts (CAs).

1. Control and Association: EOAs are controlled by private keys and are associated with human users. CAs are not intrinsically associated with any human actor and are controlled by their deployed code.
2. Code Presence: EOAs do not have any associated code. CAs have EVM code associated with them, which is kept in memory/storage on the blockchain and executed by the EVM.
3. Message and Transaction Initiation: EOAs can initiate transaction messages but cannot initiate call messages. Conversely, CAs cannot start transaction messages, but they can initiate call messages to interact with other contracts. Both types maintain an ether balance and a key-value store for their state.

Mark distribution: Correct event declaration (1 mark), Function definition with correct signature and condition (1 mark), Emitting the event inside the condition and returning true (1 mark)

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

contract ValueChecker {
    uint8 public price = 10;

    // Event declaration
    event ValueMatched(bool returnValue);

    // Function that returns true and emits event when condition is met
    function checkValue(uint8 x) public returns (bool) {
        if (x >= price) {
            emit ValueMatched(true);
            return true;
        }
        return false;
    }
}

The code defines a ValueChecker contract with a state variable price. The ValueMatched event is declared to log boolean outcomes. The checkValue function takes a uint8 parameter x. If x is greater than or equal to price, the function emits the ValueMatched event with a true argument and returns true. Otherwise, it returns false. This demonstrates how Solidity uses events to log state changes or conditions to the blockchain's transaction logs while returning a boolean value to the caller.

(a) Alice wants to send Bob a message M=8 using RSA where Prime numbers chosen are 7 and 11 and public key of Alice is 17. Perform the encryption and decryption process in RSA. (7 marks)

Mark distribution: Modulus calculation (1 mark), Euler's totient calculation (1 mark), Private key calculation using Extended Euclidean Algorithm (2 marks), Encryption (1.5 marks), Decryption (1.5 marks)

RSA Key Generation:
Given: p = 7, q = 11, e = 17, M = 8.

Step 1: Calculate Modulus (n)
n = p × q = 7 × 11 = 77

Step 2: Calculate Euler's Totient (φ(n))
φ(n) = (p - 1) × (q - 1) = 6 × 10 = 60

Step 3: Calculate Private Key (d)
We need to find d such that (d × e) ≡ 1 mod φ(n).
(d × 17) ≡ 1 mod 60
Using the Extended Euclidean Algorithm:
60 = 3 × 17 + 9
17 = 1 × 9 + 8
9 = 1 × 8 + 1

Back-substitution:
1 = 9 - 1 × 8
1 = 9 - 1 × (17 - 1 × 9) = 2 × 9 - 17
1 = 2 × (60 - 3 × 17) - 17 = 2 × 60 - 7 × 17
Thus, -7 × 17 ≡ 1 mod 60.
d = -7 mod 60 = 53.
Private Key: (d=53, n=77). Public Key: (e=17, n=77).

Step 4: Encryption
Ciphertext C = M^e mod n
C = 8^17 mod 77
Using repeated squaring:
8^1 = 8
8^2 = 64
8^4 = 64^2 = 4096 mod 77 = 15
8^8 = 15^2 = 225 mod 77 = 71
8^16 = 71^2 = 5041 mod 77 = 36
8^17 = 8^16 × 8^1 = 36 × 8 = 288 mod 77 = 57.
C = 57.

Step 5: Decryption
Plaintext M = C^d mod n
M = 57^53 mod 77
Using repeated squaring:
57^1 = 57
57^2 = 3249 mod 77 = 15
57^4 = 15^2 = 225 mod 77 = 71
57^8 = 71^2 = 5041 mod 77 = 36
57^16 = 36^2 = 1296 mod 77 = 64
57^32 = 64^2 = 4096 mod 77 = 15
53 = 32 + 16 + 4 + 1
57^53 = 57^32 × 57^16 × 57^4 × 57^1
= 15 × 64 × 71 × 57 mod 77
15 × 64 = 960 mod 77 = 36
36 × 71 = 2556 mod 77 = 15
15 × 57 = 855 mod 77 = 8.
M = 8. (Original message recovered).

(b) Illustrate the working of SHA256 algorithm and highlight its applications. (7 marks)

Mark distribution: Pre-processing (1.5 marks), Hash computation (2 marks), Diagram (1.5 marks), Applications (2 marks)

Working of SHA-256 Algorithm:
SHA-256 is a cryptographic hash function based on the Merkle-Damgard construction. It processes an input message of arbitrary length (up to 2^64 - 1 bits) and produces a fixed 256-bit hash digest. The block size is 512 bits, and the word size is 32 bits.

1. Pre-processing:

• Padding: The message is padded with a '1' bit, followed by '0' bits, and finally the 64-bit representation of the original message length, ensuring the total length is a multiple of 512 bits.
• Parsing: The padded message is divided into equal 512-bit blocks.
• Initial Hash Value: An initialization vector consisting of eight 32-bit words (derived from the fractional parts of the square roots of the first eight prime numbers) is set up.

2. Hash Computation:

• The algorithm processes each 512-bit block sequentially through 64 rounds.
• In each round, a message schedule is prepared, and eight working variables are updated using a compression function.
• The compression function applies bitwise operations, rotations, and adds round constants.
• After all blocks are processed, the final intermediate hash values are concatenated to produce the 256-bit output digest.

Figure: Merkle-Damgard Construction used in SHA-256

Applications of SHA-256:

1. Proof of Work (PoW): Used in Bitcoin's mining algorithm to verify the computational effort spent by miners.
2. Merkle Trees: Used to guarantee the integrity of the transaction structure in the blockchain by hashing transactions into a single Merkle root.
3. Digital Signatures: Used to generate message digests before signing data with a private key.
4. Address Generation: Used in combination with other hash functions (like RIPEMD-160) to generate cryptocurrency wallet addresses.

(a) Explain Advanced Encryption Standard (AES) and its operations with the help of neat diagram. (7 marks)

Mark distribution: AES Basics (1.5 marks), Operations (3 marks), Diagram (1.5 marks), Final round (1 mark)

Advanced Encryption Standard (AES):
AES is a symmetric block cipher standardized by NIST. It encrypts data in fixed blocks of 128 bits. The number of rounds depends on the key size: 10 rounds for 128-bit keys, 12 rounds for 192-bit keys, and 14 rounds for 256-bit keys. During processing, the 128-bit block is represented as a 4x4 array of bytes known as the state matrix.

AES Round Operations:
Each round (except the final one) consists of four sequential operations:

1. SubBytes: A non-linear substitution step where each byte in the state matrix is replaced with a corresponding entry from a fixed 16x16 lookup table called the S-box. This provides confusion.
2. ShiftRows: A permutation step where the rows of the state matrix are cyclically shifted to the left by different offsets. Row 0 is unchanged, Row 1 shifts by 1, Row 2 by 2, and Row 3 by 3 positions.
3. MixColumns: A linear transformation step that mixes the bytes within each column of the state matrix by multiplying it with a fixed polynomial matrix in GF(2^8). This provides diffusion.
4. AddRoundKey: The state matrix is XORed with a round subkey derived from the master key using the key expansion schedule.

Figure: AES Encryption Round Operations

Final Round Exception:
In the final round (10th, 12th, or 14th), the MixColumns step is omitted. The round consists only of SubBytes, ShiftRows, and AddRoundKey to ensure the cipher cannot be easily reversed.

(b) Elaborate the functioning of digital signatures with an example from real-world scenario. (7 marks)

Mark distribution: Signing Process (1.5 marks), Verification Process (1.5 marks), Properties (1.5 marks), Real-world Example (2.5 marks)

Functioning of Digital Signatures:
A digital signature is a cryptographic mechanism used to verify the authenticity, integrity, and origin of a digital message. It relies on asymmetric cryptography and hash functions.

1. Signing Process (Sender):

• The sender first computes a cryptographic hash of the original message. This ensures data integrity.
• The sender then encrypts this hash value using their private key. The resulting encrypted hash is the digital signature, which is attached to the message and sent to the receiver.

2. Verification Process (Receiver):

• Upon receiving the message and signature, the receiver decrypts the signature using the sender's public key to retrieve the original hash.
• The receiver independently computes the hash of the received message.
• If the two hashes match exactly, the signature is valid. This proves the message was not altered (integrity) and was sent by the owner of the private key (authentication).

Figure: Digital Signature Signing and Verification Process

Properties of Digital Signatures:

• Authenticity: Verifiable by the receiving party, confirming the sender's identity.
• Unforgeability (Non-repudiation): Only the sender possesses the private key, meaning they cannot deny having signed the message.
• Non-reusability: The signature is firmly bound to the specific message and cannot be cut and pasted onto another document.

Real-World Example: Blockchain Transaction Signing
In blockchain networks like Bitcoin and Ethereum, digital signatures (specifically ECDSA) are used to authorize the transfer of digital assets.

• When a user initiates a transaction, the transaction data is hashed and signed with the user's private key.
• This signature is broadcast to the network along with the user's public key.
• Network nodes verify the signature using the public key. If valid, it proves the user owns the funds and authorized the transfer, preventing unauthorized spending and ensuring non-repudiation without needing a central bank.

(a) Explain the layered blockchain architecture with the help of a diagram. (7 marks)

Mark distribution: Definition of layered architecture and its purpose (1 mark), Network and P2P layers explanation (1.5 marks), Cryptography and Consensus layers explanation (1.5 marks), Execution and Applications layers explanation (1.5 marks), Diagram (1.5 marks)

The layered blockchain architecture organizes the system into distinct functional layers, facilitating modularity, scalability, and security. According to the textbook, blockchain acts as a layer of a distributed peer-to-peer network running on top of the internet, analogous to SMTP or HTTP running on TCP/IP. The architecture consists of six primary layers:

1. Network Layer: The lowest layer, usually the internet, which provides the base communication layer for any blockchain.
2. Peer-to-Peer Network Layer: Runs on top of the Network layer. It consists of information propagation protocols such as gossip or flooding protocols to disseminate data across nodes without a central server.
3. Cryptography Layer: Contains crucial cryptographic protocols that ensure the security, integrity, and consensus of the blockchain. It consists of public key cryptography, digital signatures, and cryptographic hash functions. Sometimes abstracted away, it plays a fundamental role in blockchain operations.
4. Consensus Layer: Concerned with the usage of various consensus mechanisms to ensure agreement among different participants. It includes techniques like State Machine Replication (SMR), proof-based mechanisms, and traditional Byzantine fault-tolerant protocols.
5. Execution Layer: Consists of virtual machines (like the Ethereum Virtual Machine), blocks, transactions, and smart contracts. It provides execution services such as value transfer, smart contract execution, and block generation.
6. Applications Layer: The topmost layer composed of smart contracts, decentralized applications (DApps), Decentralized Autonomous Organizations (DAOs), and autonomous agents. Users interact with the blockchain via these decentralized applications.

These layers work together to provide a trustless, decentralized environment where users can exchange value without a centrally trusted arbitrator.

Figure: The architectural view of a generic blockchain.

(b) How does blockchain enable the decentralization of processing power? Describe the mechanism behind it. (7 marks)

Mark distribution: Concept of decentralized processing power (1.5 marks), Distributed P2P Network and DLT (2 marks), Consensus Mechanisms and Distributed Mining (2 marks), Distributed Transaction Processing and Storage (1.5 marks)

Decentralization of computing or processing power is achieved by blockchain technology by distributing computational tasks across a network of independent nodes, eliminating the need for a central authority. This is accomplished through the following mechanisms:

1. Distributed Peer-to-Peer Network Architecture: The network operates without a central server; all nodes are equal peers. Each node independently stores a copy of the blockchain and communicates directly with others. Transaction validation is distributed across all nodes, ensuring no single processing unit is relied upon.
2. Distributed Ledger Technology (DLT): Every participating node maintains a complete copy of the blockchain. When a new transaction occurs, it is broadcast to all nodes, and each node independently validates and updates its local copy, ensuring redundancy and fault tolerance.
3. Consensus Mechanisms: Blockchain uses protocols like Proof of Work (PoW) and Proof of Stake (PoS) to achieve agreement without a central coordinator. In PoW, thousands of miners globally compete to solve cryptographic puzzles, distributing mining power geographically and economically. In PoS, validators are selected based on staked cryptocurrency, distributing validation power among token holders.
4. Distributed Transaction Processing: Transaction creation occurs on local wallets. Validation (checking digital signatures and balances) is performed by every node. Inclusion in blocks is determined by miners/validators competing, and state updates are independently executed by all nodes, ensuring deterministic consistency.
5. Distributed Mining and Validation Power: Mining hardware (ASICs, GPUs) and stake are distributed among numerous participants. This geographic and economic distribution prevents single-jurisdiction control and makes coordination for attacks extremely difficult.
6. Data Storage and Redundancy: Full nodes store the complete blockchain history. The storage load is distributed globally, meaning data loss requires all nodes to fail simultaneously. Read access can be served from the nearest node, eliminating central database bottlenecks.

Figure: Decentralized transaction processing and validation flow.

(a) Describe the structure of blockchain and elaborate the various types of blockchain. (7 marks)

Mark distribution: Structure of blockchain (3 marks), Types of blockchain (3 marks), Diagram (1 mark)

The structure of a blockchain is fundamentally composed of blocks linked together cryptographically. Each block consists of two main parts:

1. Block Header: Contains metadata including the hash of the previous block's header (which links the blocks and ensures immutability), the timestamp, the nonce (used in mining/consensus), and the Merkle root (a hash of all transactions in the block).
2. Block Body: Contains the actual transactions that make up the block.

Additionally, the generic elements of a blockchain include addresses, accounts, transactions, blocks, a peer-to-peer network, a scripting or programming language, a virtual machine (e.g., EVM), a state machine, nodes, and smart contracts.

Based on their evolution and usage, blockchains are classified into various types:

• Public Blockchains: Open, decentralized, and permissionless. Anyone can participate as a node in the decision-making process. Examples include Bitcoin and Ethereum.
• Private Blockchains: Accessible only to a selected group or consortium of individuals/organizations. Examples include Kadena and Quorum.
• Semi-Private Blockchains: A hybrid model where part of the blockchain is private (controlled by a group) and part is public (open to anyone).
• Sidechains and Pegged Sidechains: Independent blockchains linked to a main chain to offload computational load. They use a two-way peg mechanism to transfer assets. Examples include Rootstock (RSK) and Liquid.
• Permissioned Ledgers: Blockchains with regulated access control where participants are known and trusted. Validators are preselected by a central authority, and an agreement protocol maintains the shared truth.
• Tokenized Blockchains: Generate cryptocurrency as part of the consensus process via mining or initial distribution (e.g., Bitcoin).
• Tokenless Blockchains: Designed without a native cryptocurrency for value transfer, used mainly for sharing data among trusted parties (e.g., Hyperledger Fabric).

Figure: The generic structure of a block.

(b) Discuss the role of consensus in blockchain technology and explain any three consensus algorithms. (7 marks)

Mark distribution: Role of consensus (2.5 marks), Proof of Work explanation (1.5 marks), Proof of Stake explanation (1.5 marks), Practical Byzantine Fault Tolerance explanation (1.5 marks)

Consensus is the backbone of a blockchain, providing the decentralization of control through an optional process known as mining. It is the process of achieving agreement between distrusting nodes on the final state of data without a central authority. The requirements for a consensus mechanism include:

• Agreement: All honest nodes decide on the same value.
• Integrity: No node can make the decision more than once in a single consensus cycle.
• Validity: The value agreed upon must be the same as the initial value proposed by at least one honest node.
• Fault tolerant: The algorithm must run correctly in the presence of faulty or malicious (Byzantine) nodes.
• Termination: All honest nodes eventually terminate the execution and reach a decision.

Three prominent consensus algorithms used in blockchain are:

1. Proof of Work (PoW): A proof-based, leader-election lottery mechanism. It relies on proof that adequate computational resources have been spent before proposing a value. Miners compete to solve a mathematical puzzle (finding a nonce that produces a hash below a target threshold). The first to solve it wins the right to add the next block. It is highly secure against Sybil attacks but energy-intensive. Used in Bitcoin.
2. Proof of Stake (PoS): Works on the idea that a node or user has an adequate stake in the system. The chances of proposing and signing the next block increase with the user's stake or coin age (the amount of time and number of coins not spent). It is more energy-efficient than PoW and penalizes malicious behavior by slashing the stake. Used in Ethereum.
3. Practical Byzantine Fault Tolerance (PBFT): A traditional fault tolerance-based mechanism that achieves State Machine Replication (SMR). It relies on nodes publishing and verifying signed messages in multiple phases (Pre-prepare, Prepare, Commit). It provides tolerance against Byzantine nodes and performs well with a limited number of known nodes, making it suitable for permissioned blockchains.

Figure: General consensus mechanism workflow in blockchain.

(a) Illustrate the working of Crash Fault Tolerant Consensus algorithm that uses consensus over a value under unreliable communications and makes use of (2F + 1) processes to ensure fault tolerance in a network. (7 marks)

Mark distribution: Definition and context (1.5 marks), Roles (1.5 marks), Phase 1 - Prepare (2 marks), Phase 2 - Accept (2 marks)

The Crash Fault Tolerant (CFT) consensus algorithm described is Paxos, developed by Leslie Lamport. It solves the consensus problem over a value under unreliable communications where processes may experience benign failures (crash faults or message loss). Paxos makes use of 2F + 1 processes to ensure fault tolerance in a network, meaning it can tolerate up to F crash failures.

Figure: Paxos protocol working mechanism

Roles in Paxos:
Processes in Paxos can assume three distinct roles:

1. Proposers: Elected leaders that propose a new value to be decided.
2. Acceptors: Participate in the protocol to provide a majority decision and store accepted values.
3. Learners: Observe the decision process and learn the final decided value.

Working of Paxos (Two-Phase Protocol):

Phase 1: Prepare Phase

1. The Proposer initiates consensus by broadcasting a <prepare(n)> message to all Acceptors, where n is a unique proposal number.
2. Upon receiving the prepare message, an Acceptor responds with an acknowledgment <ack(n, v, s)> if n is the highest proposal number it has responded to so far.
3. The acknowledgment contains the proposal value v and sequence number s of the highest-numbered proposal the Acceptor has already accepted. This ensures the Proposer learns about any previously accepted values.

Phase 2: Accept Phase
4. If the Proposer receives acknowledgment messages from a majority of the Acceptors, it determines the value to propose. If any Acceptor reported a previously accepted value, the Proposer must propose the value from the highest-numbered proposal; otherwise, it proposes its own value.
5. The Proposer then broadcasts an <accept(n, v)> message to the Acceptors.
6. An Acceptor accepts the proposal if it has not already promised to accept a proposal with a number greater than n. It then broadcasts an <accepted(n, v)> message.
7. Once a majority of Acceptors accept the proposed value, agreement is achieved, and the Learners are informed of the decided value.

Safety and Liveness:
Paxos guarantees safety (agreement, validity, and integrity—no two different values are chosen) and liveness (termination—eventually a value is decided), provided there is a period with only one fault-free proposer.

(b) Elaborate the concept of Proof of Stake (PoS) consensus algorithm and its types. (7 marks)

Mark distribution: Concept of PoS (2.5 marks), Chain-based PoS (1.5 marks), Committee-based PoS (1.5 marks), Delegated PoS (1.5 marks)

Concept of Proof of Stake (PoS):
Proof of Stake (PoS) is an energy-efficient alternative to the Proof of Work (PoW) algorithm. In PoS, there is no concept of traditional mining requiring massive computational power. Instead, the "stake" represents the number of coins (money) staked by a blockchain participant. The key idea is that if a participant has a financial stake in the system, they are economically incentivized not to sabotage it.

The chance of being selected to propose the next block is directly proportional to the value staked by the participant. A stake calculator function calculates the staked funds and selects a new proposer. The process of earning revenue is sometimes called "virtual mining," and a PoS miner is referred to as a validator, minter, or stakeholder.

Figure: Proof of Stake mechanism showing stake calculator and proposer selection

Types of PoS:

1. Chain-based PoS:
This mechanism is similar to PoW but changes the block generation method. A block is generated by checking if the hash of the block header concatenated with the clock time is less than the product of the target value and stake value:
Hash (B || clock time) < target x stake value
Instead of competing continuously, the hashing puzzle is solved at regular intervals based on a constant clock tick. The puzzle becomes easier to solve if the minter's stake value is high.

2. Committee-based PoS:
In this scheme, a group of stakeholders is chosen randomly, typically using a Verifiable Random Function (VRF). The VRF produces a random set of stakeholders based on their stake and the current blockchain state. This chosen committee becomes responsible for proposing blocks in sequential order. This mechanism is used in the Ouroboros PoS consensus (e.g., Cardano).

3. Delegated PoS (DPoS):
DPoS is similar to committee-based PoS, but the group of stakeholders is chosen by stake delegation rather than a random function. Network users vote for delegates proportional to their stake. The selected fixed number of minters create blocks in a round-robin fashion. While highly scalable, it is less decentralized since a small number of known users are responsible for generating blocks (e.g., EOS, Lisk, Cosmos).

(a) Explain the working of the consensus algorithm designed to achieve consensus in the presence of Byzantine faults. (7 marks)

Mark distribution: Definition and Fault Model (1.5 marks), Pre-prepare phase (1.5 marks), Prepare phase (1.5 marks), Commit phase (1.5 marks), View Change (1 mark)

The consensus algorithm designed to achieve agreement in the presence of Byzantine (malicious or arbitrary) faults is Practical Byzantine Fault Tolerance (PBFT). PBFT ensures that the system can reach consensus and continue operating correctly even if some nodes act maliciously or fail arbitrarily, provided the network has at least N = 3F + 1 nodes (where F is the number of faulty nodes).

Figure: PBFT normal operation sequence showing Pre-prepare, Prepare, and Commit phases

Working of PBFT:
PBFT operates in rounds. In each round, an elected leader node called the Primary handles communication with the client, while the remaining nodes act as Backups (replicas). The protocol progresses through three sequential phases:

1. Pre-prepare Phase:
The Primary receives a request from the client and assigns a unique sequence number to it. The Primary then broadcasts a pre-prepare message containing the request details to all backup replicas. Backups validate the digital signature, view number, sequence number, and message digest. If valid, they accept the message and update their local state.

2. Prepare Phase:
Upon accepting the pre-prepare message, each backup broadcasts a prepare message to all other replicas in the system. This phase ensures that honest replicas agree on the total order of requests within the current view. Each replica waits until it receives at least 2F + 1 matching prepare messages (including its own). Once this threshold is met, the replica enters the "prepared" state.

3. Commit Phase:
Replicas in the prepared state broadcast a commit message to all other nodes. This phase ensures agreement on the total order of requests across different views. Replicas wait for 2F + 1 valid commit messages. Once received, the replica executes the client's request, updates its state to reflect the commit, and sends a reply message containing the execution result back to the client. The client accepts the result only after receiving F + 1 matching replies.

View Change (Fault Handling):
If backup replicas suspect the Primary is faulty (e.g., due to a timeout), they initiate a view-change sub-protocol. They stop accepting messages for the current view and broadcast view-change messages to all replicas. A new Primary is selected (typically in a round-robin fashion), who then broadcasts a new-view message to synchronize the network and resume normal operation, ensuring liveness.

(b) What are the different tasks of a Bitcoin miner? Explain the mining algorithm used in Bitcoin with the help of a diagram. (7 marks)

Mark distribution: Tasks of a miner (3 marks), Mining algorithm steps (2.5 marks), Flowchart diagram illustrating the mining loop and nonce… (1.5 marks)

Tasks of a Bitcoin Miner:
Once a node connects to the Bitcoin network and decides to mine, it performs several critical tasks to maintain and secure the blockchain:

1. Synching up with the network: Downloading the blockchain by requesting historical blocks from other nodes to get the current state.
2. Transaction validation: Listening to the network, collecting unconfirmed transactions from the mempool, and validating their digital signatures and outputs to prevent double-spending.
3. Block validation: Evaluating blocks received from other miners against consensus rules, including verifying the nonce value and all contained transactions.
4. Create a new block: Assembling validated transactions into a new candidate block, including a special coinbase transaction for the block reward.
5. Perform PoW: Solving the computational puzzle by repeatedly varying the 32-bit nonce in the block header until the resultant hash is less than the predetermined network difficulty target.
6. Fetch reward: Broadcasting the successfully mined block to the network. Once accepted by other nodes, the miner claims the block reward (newly minted bitcoins) and associated transaction fees.

Bitcoin Mining Algorithm:
The mining algorithm is the process of solving the Proof of Work (PoW) puzzle. It consists of the following steps:

1. Retrieve the previous block's header from the network.
2. Assemble a set of validated transactions into the new block and calculate the Merkle root.
3. Construct the block header and compute the double hash (SHA-256 applied twice) of the header combined with a nonce.
4. Check if the resulting hash is lower than the current network difficulty target.
5. If it is lower, PoW is solved; the block is broadcasted, and the reward is fetched.
6. If it is not lower, the nonce is incremented, and the hashing process is repeated. If the 32-bit nonce is exhausted, an extra nonce in the coinbase transaction is updated to expand the search space.

Figure: Bitcoin mining algorithm — box numbers ①–⑥ match steps 1–6 above

(a) Explain the generic data flow of Oracle in smart contracts. Describe any three types of Oracles used in blockchain to interact with the external world. (7 marks)

Mark distribution: Request initiation (1.5 marks), Attestation (1.5 marks), Optional decentralized storage (1 mark), Software oracle (1 mark), Hardware oracle (1 mark), Decentralized or other valid oracle (1 mark)

Smart contracts operate in a closed, deterministic environment and cannot natively access external, off-chain data. Oracles act as the trusted bridge between the blockchain and the real world. However, relying on a single centralized oracle introduces the "Blockchain Oracle Problem"—a conflict of trust between a presumably trusted third-party data source and a completely trustless blockchain. To solve this, the generic data flow incorporates cryptographic attestation to guarantee data authenticity.

Generic Data Flow of an Oracle:

1. Request Initiation: A smart contract identifies the need for external data (e.g., flight delays, asset prices) and sends a data request to the oracle service.
2. Data Fetching: The oracle executes the request by querying the external data source. This involves invoking APIs, calling web services, or reading from enterprise databases.
3. Attestation and Proof Generation: The fetched raw data is sent to a notary or attestation service (e.g., TLSNotary, Android proof, or trusted hardware like Intel SGX). This service generates cryptographic proof (usually a digital signature) to verify the data's validity and authenticity.
4. Oracle Receipt: The data, along with its cryptographic proof of validity, is sent back to the oracle service.
5. Decentralized Storage (Optional): If the proofs of authenticity are large, the data and proof can be optionally saved on a decentralized storage system like Swarm or IPFS to avoid bloating the blockchain.
6. Final Delivery: Finally, the oracle submits the data, complete with its cryptographic proof, to the requesting smart contract via an on-chain transaction. The smart contract verifies the proof and executes its business logic based on the trusted data.

Figure: Generic oracle data flow — arrow numbers ①–⑥ match steps 1–6 above

Types of Oracles:

1. Software Oracles: These acquire information from online services on the Internet. They source data such as weather information, financial market data, exchange rates, and travel information from third-party APIs or internal enterprise systems. They are the most common type of inbound oracle.
2. Hardware Oracles: These source data directly from physical hardware sources such as IoT devices, telemetry sensors, or RFID scanners. They are highly useful in insurance and supply chain use cases where real-world physical events (e.g., vehicle speed, temperature, location) must trigger smart contract logic.
3. Decentralized Oracles: To fully address the oracle problem and eliminate single points of failure, decentralized oracles use a distributed mechanism. They aggregate data from multiple independent sources and nodes, often relying on distributed consensus or crowd wisdom (e.g., Augur) to ensure the data fed to the blockchain is authentic and untampered, without relying on a single trusted third party.

(b) How can Blockchain technology enhance healthcare, aligning with the sustainable development goals ? (7 marks)

Mark distribution: Identification of core Healthcare Challenges (2 marks), Blockchain Benefits (2 marks), Specific Use Cases (2 marks), Alignment with SDGs (1 mark)

The healthcare industry traditionally suffers from major issues such as privacy compromises, data breaches, high operational costs, and fraud. These problems largely arise from a lack of interoperability between hospitals, overly complex administrative processes, and centralized databases that present single points of failure. Furthermore, the distribution of counterfeit medicines remains a burning issue, especially in developing nations. Blockchain technology offers a transformative solution by providing an immutable, auditable, and transparent system that aligns directly with the United Nations Sustainable Development Goals, particularly SDG 3 (Good Health and Well-being).

Enhancing Healthcare through Blockchain:

1. Immutable and Auditable Medical Records: Blockchain provides a secure, decentralized infrastructure for patient records. Instead of complex, centralized PKI networks, blockchain ensures that medical histories are tamper-proof. Patients can grant cryptographic access to their data to different specialists, solving the interoperability issue while maintaining strict privacy and control. This reduces administrative errors and speeds up the processing of insurance claims.
2. Preventing Counterfeit Medicines: By implementing blockchain in supply chain management, every step of a pharmaceutical product's journey—from manufacturing to distribution—can be tracked. Cryptographic hashes and IoT sensors can verify the provenance of drugs, ensuring that counterfeit medicines are instantly flagged and prevented from reaching consumers.
3. Cost Savings and Trust: The elimination of intermediaries and the automation of claim verifications via smart contracts lead to significant cost savings. High availability and the removal of operational errors due to complex legacy procedures increase trust among patients, providers, and insurers.

Figure: Blockchain Integration in Healthcare for SDG Alignment

Alignment with Sustainable Development Goals:
By ensuring data integrity, securing the pharmaceutical supply chain, and enabling secure, interoperable health records across institutions without a central point of failure, blockchain directly supports sustainable healthcare infrastructure. It reduces waste caused by fraudulent claims and counterfeit drugs, ensuring that medical resources are efficiently allocated and accessible, thereby promoting long-term well-being and sustainable health systems globally.

(a) Discuss the legal and ethical implications of Blockchain technology. (7 marks)

Mark distribution: Privacy vs Immutability (1.5 marks), Regulatory and Jurisdictional Challenges (1.5 marks), Money Laundering and Illicit Activities (1.5 marks), Environmental and Energy Consumption Concerns (1.5 marks), Smart Contract Liability / Code as Law (1 mark)

Blockchain technology, while revolutionary in establishing trust and decentralization, raises significant legal and ethical concerns that challenge existing regulatory frameworks. The following are the primary implications:

1. Privacy and GDPR Compliance (Right to be Forgotten vs. Immutability)
Blockchain's core feature—immutability—directly conflicts with data protection regulations like the EU's General Data Protection Regulation (GDPR). Article 17 of GDPR grants individuals the "right to erasure," allowing them to request the deletion of personal data. However, once data is recorded on a blockchain, it cannot be modified or deleted. This creates a fundamental tension between regulatory compliance and blockchain architecture, forcing developers to explore off-chain storage or zero-knowledge proofs.

2. Regulatory and Jurisdictional Challenges
Blockchain networks operate across international boundaries without a central authority, making it unclear which jurisdiction's laws apply. A transaction initiated in one country, validated by nodes in another, and affecting parties in a third country raises complex questions about applicable law, taxation, and legal enforcement. Different countries have varying and often conflicting regulations regarding cryptocurrency and smart contracts, creating uncertainty for businesses.

3. Money Laundering and Illicit Activities
The pseudonymous nature of blockchain transactions has raised ethical and legal concerns about facilitating money laundering, terrorist financing, and ransomware payments. While transactions are publicly visible, connecting wallet addresses to real-world identities is difficult without KYC (Know Your Customer) mechanisms. Regulatory bodies have responded with Anti-Money Laundering (AML) requirements for centralized exchanges, but decentralized protocols and privacy coins continue to pose significant challenges.

4. Environmental and Energy Consumption Concerns
Proof of Work (PoW) consensus mechanisms consume enormous amounts of electricity, raising ethical concerns about environmental sustainability and resource allocation. The carbon footprint of mining operations contributes to climate change, leading to questions about whether the benefits of decentralization justify the environmental cost. This has accelerated the ethical push toward energy-efficient alternatives like Proof of Stake.

5. Smart Contract Liability
When a smart contract executes incorrectly due to a bug or vulnerability, determining legal liability is highly unclear. While the ethos of blockchain is "code is law," traditional legal systems may not recognize autonomous code execution as a binding contract, leaving victims of smart contract exploits without legal recourse.

Figure: Key Legal and Ethical Implications of Blockchain Technology

(b) In the context of advancing Artificial Intelligence, how does Blockchain technology serve as a pivotal enabler? (7 marks)

Mark distribution: Data Integrity and Provenance (1.5 marks), Decentralized Data Marketplaces / Federated Learning (1.5 marks), Decentralized Compute Networks (1.5 marks), Transparent and Explainable AI (1.5 marks), Autonomous Agents and AIDAOs (1 mark)

The convergence of Artificial Intelligence (AI) and Blockchain creates a powerful synergy where the strengths of one technology compensate for the inherent weaknesses of the other. AI requires massive amounts of data and compute power, often leading to centralized data silos, privacy concerns, and opaque "black box" decision-making. Blockchain, conversely, is a decentralized, immutable ledger that excels at establishing trust, securing data, and enabling peer-to-peer coordination. Blockchain serves as a pivotal enabler for AI in the following ways:

1. Data Integrity and Provenance:
A critical vulnerability in AI is "data poisoning," where malicious actors alter training data to compromise the model's output. Blockchain solves this by hashing datasets and storing the cryptographic hashes on an immutable, timestamped ledger. This creates an auditable trail of the exact data used to train an AI model, guaranteeing provenance and ensuring that any subsequent tampering is instantly flagged.

2. Decentralized Data Marketplaces and Federated Learning:
Blockchain enables decentralized data marketplaces where individuals can securely share data for AI training and be automatically compensated via smart contracts. Furthermore, it coordinates "Federated Learning," where AI models are trained across multiple decentralized devices holding local data. The blockchain securely records and verifies the model updates (gradients) submitted by each node, preserving user data privacy while preventing malicious nodes from poisoning the global model.

3. Decentralized Compute Networks:
Training advanced AI models requires immense GPU power, currently dominated by centralized tech giants. Blockchain enables decentralized compute networks where individuals can rent out their idle GPU resources to AI developers. The blockchain handles the verification of compute work and the distribution of token-based payments, creating a distributed, cost-effective supercomputer.

4. Transparent and Explainable AI (XAI):
To address the "black box" nature of AI, blockchain can log every decision made by an AI model, along with the specific data inputs and model versions used. This creates a transparent, tamper-proof audit trail that allows regulators and users to trace an AI's decision back to its exact origin, fostering Explainable AI and ensuring regulatory compliance.

5. Autonomous Agents (AAs) and AIDAOs:
Blockchain enables the creation of Artificially Intelligent Decentralized Autonomous Organizations (AIDAOs). Intelligent agents (AAs) can act on the blockchain, making rational decisions on behalf of humans, learning over time using machine learning processes, and executing complex organizational tasks autonomously in a trustless environment.

Figure: Blockchain as a Pivotal Enabler for Artificial Intelligence

(a) Explain the EVM operation and block difficulty mechanism in Ethereum. (7 marks)

Mark distribution: EVM Architecture (2 marks), EVM Execution Flow (1.5 marks), Block Difficulty Algorithm (2 marks), Difficulty Bomb / Ice Age mechanism (1 mark), Note on the Merge (0.5 marks)

EVM Operation:
The Ethereum Virtual Machine (EVM) is a simple, stack-based execution machine that runs bytecode instructions to transform the system state. It operates in an isolated, sandboxed runtime environment with a 256-bit word size.
The EVM utilizes three main types of storage:

1. Memory: Volatile, word-addressed byte array (cleared after execution).
2. Storage: Persistent key-value store (256-bit keys and values) permanently saved on the blockchain.
3. Stack: LIFO queue with a maximum depth of 1024 elements, used for computations.

The program code is stored in virtual read-only memory (virtual ROM). During execution, the CODECOPY instruction copies the program code into the main memory. The EVM reads instructions from main memory using a Program Counter, which increments with each step. Elements are pushed and popped from the EVM stack to execute operations, updating the state accordingly.

Figure: EVM Operation Flow

Block Difficulty Mechanism:
In Ethereum's PoW era (Homestead release), block difficulty was adjusted dynamically to maintain a consistent block generation time (~10-15 seconds). The algorithm evaluated the timestamp difference between the current block and the parent block:

• If the time difference was less than 10 seconds, the difficulty increased.
• If the time difference was between 10 and 19 seconds, the difficulty remained the same.
• If the time difference was 20 seconds or more, the difficulty decreased proportionally.

Additionally, an exponential increase was applied every 100,000 blocks, known as the difficulty bomb or ice age. This mechanism was designed to make PoW mining progressively harder, forcing the network to eventually transition to Proof of Stake (PoS).
Note: Following the Merge in September 2022, Ethereum transitioned to PoS, rendering the PoW block difficulty adjustment mechanism obsolete on the mainnet.

(b) Design a smart contract in solidity for Simple Open Auction system depicting the key functions and deployment methods. (7 marks)

Mark distribution: Correct Solidity Syntax and Structure (2.5 marks), Implementation of bid and withdraw logic (2 marks), Implementation of auctionEnd and Events (1.5 marks), Explanation of Deployment Methods (1 mark)

Simple Open Auction Smart Contract:

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

contract SimpleAuction {
    address public beneficiary;
    uint public auctionEndTime;

    address public highestBidder;
    uint public highestBid;

    mapping(address => uint) pendingReturns;
    bool ended;

    event HighestBidIncreased(address bidder, uint amount);
    event AuctionEnded(address winner, uint amount);

    constructor(uint _biddingTime, address _beneficiary) {
        beneficiary = _beneficiary;
        auctionEndTime = block.timestamp + _biddingTime;
    }

    function bid() public payable {
        require(block.timestamp <= auctionEndTime, "Auction already ended.");
        require(msg.value > highestBid, "There already is a higher bid.");

        if (highestBid != 0) {
            pendingReturns[highestBidder] += highestBid;
        }
        highestBidder = msg.sender;
        highestBid = msg.value;
        emit HighestBidIncreased(msg.sender, msg.value);
    }

    function withdraw() public returns (bool) {
        uint amount = pendingReturns[msg.sender];
        if (amount > 0) {
            pendingReturns[msg.sender] = 0;
            if (!payable(msg.sender).send(amount)) {
                pendingReturns[msg.sender] = amount;
                return false;
            }
        }
        return true;
    }

    function auctionEnd() public {
        require(block.timestamp >= auctionEndTime, "Auction not yet ended.");
        require(!ended, "auctionEnd has already been called.");
        ended = true;
        emit AuctionEnded(highestBidder, highestBid);
        payable(beneficiary).transfer(highestBid);
    }
}

Key Functions:

1. bid(): Accepts Ether via msg.value. It verifies the auction hasn't ended and the bid is higher than the current highest. It securely records the previous highest bid in pendingReturns to be withdrawn later, preventing reentrancy attacks.
2. withdraw(): Implements the pull-payment pattern. Bidders who were outbid can call this to safely retrieve their funds.
3. auctionEnd(): Can only be called after the bidding time expires. It finalizes the auction and transfers the highest bid to the beneficiary.

Deployment Methods:
The contract is deployed by passing the constructor parameters (_biddingTime in seconds, and _beneficiary address).

• Remix IDE: Compile the code, navigate to the Deploy tab, input the constructor arguments, and deploy using the Injected Provider (MetaMask) or local EVM.
• Hardhat/Truffle: Use migration scripts to deploy the contract programmatically to testnets (like Sepolia) or mainnet.

Figure: Simple Open Auction — call order 1–5: bid, refund bookkeeping, withdraw, refund, auctionEnd

(a) Explain how transactions are processed in Ethereum. Briefly explain the concept of gas and how does it affect the transaction processing? (7 marks)

Mark distribution: Transaction Processing Steps (3 marks), Concept of Gas (2 marks), Effect of Gas on Transaction Processing (2 marks)

Transaction Processing in Ethereum:
Ethereum is a transaction-driven state machine. The processing of a transaction involves the following steps:

1. Creation & Signing: A user constructs a transaction (specifying to, value, data, gasLimit, and gasPrice) and signs it using their private key (ECDSA).
2. Broadcasting: The signed transaction is broadcast to the peer-to-peer network and added to the transaction pool (mempool).
3. Validation: Nodes verify the syntax, signature, and nonce. They check if the sender has sufficient balance to cover the value plus the maximum gas cost.
4. Execution: Validators select transactions from the mempool and execute them in the EVM. The state transition function deducts the gas prepayment, executes the bytecode, and updates account balances or contract storage.
5. Finalization & Receipt: If successful, the remaining gas is refunded, and the fee is paid to the validator. A transaction receipt (containing logs and status) is generated and stored on the blockchain. If it fails due to insufficient balance or gas, state changes are rolled back, but the fee is still consumed.

Figure: Ethereum transaction processing — arrow numbers 1–5 match steps 1–5 above

Concept of Gas:
Gas is the unit measuring computational work required to execute operations on Ethereum. Because the EVM is Turing-complete, gas ensures that every computation has a bounded cost, preventing infinite loops that could stall the network.
The transaction cost is calculated as:
Total cost = gasUsed * gasPrice
Users pay for transactions in Ether to compensate validators for the computational resources consumed.

Effect on Transaction Processing:

1. Priority and Inclusion: Transactions with a higher gasPrice offer greater incentives to validators, resulting in faster inclusion in the next block. Low gas prices may cause transactions to remain pending in the mempool for extended periods.
2. Execution Limits: The gasLimit caps the maximum computation a transaction can perform. If execution exceeds this limit, an Out-of-Gas exception occurs. The EVM immediately halts, all state changes are rolled back, but the validator still keeps the entire gas fee as compensation for the work performed up to that point.

(b) Describe the features of solidity language and also demonstrate the working of function and inheritance in solidity language (7 marks)

Mark distribution: Features of Solidity Language (2 marks), Working of Functions (2.5 marks), Working of Inheritance (2.5 marks)

Features of Solidity Language:
Solidity is a domain-specific, contract-oriented programming language used for writing smart contracts on the Ethereum blockchain. Its key features include:

• Statically Typed: Variable types are checked at compile time, catching bugs early in the development cycle.
• Contract-Oriented: Contracts in Solidity are similar to classes in object-oriented languages, encapsulating state variables and functions.
• Composite Data Types: Supports complex types like structs, arrays, and mappings.
• Advanced OOP Concepts: Supports inheritance, libraries, and user-defined types (enums).
• EVM Compilation: Compiles down to EVM bytecode, ensuring deterministic execution across all nodes.

Working of Functions:
Functions are pieces of code within a smart contract that define the logic and actions. They are defined using the function keyword, followed by the name, parameters, and visibility specifiers.

• Visibility: public (accessible everywhere), private (only within the contract), internal (contract and derived contracts), external (only from outside).
• State Mutability: view (reads state but doesn't modify), pure (doesn't read or modify state), payable (can receive Ether).
• Return Values: Functions can return values using the returns keyword.

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

contract PriceStore {
    uint public price;

    function setPrice(uint _price) public payable {
        price = _price;
    }
}

Working of Inheritance:
Inheritance allows a derived contract to acquire the state variables and functions of a base contract, promoting code reusability. Solidity uses the is keyword to establish inheritance.

• A base contract must mark functions as virtual if they are intended to be overridden.
• The derived contract uses the override keyword to provide a new implementation.
• Derived contracts have access to all non-private members of the parent contract.

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

contract BaseContract {
    uint public price;

    function setPrice(uint _price) public virtual {
        price = _price;
    }
}

contract DerivedContract is BaseContract {
    // Overriding the parent function
    function setPrice(uint _price) public override {
        price = _price * 2; 
    }
}

Figure: Inheritance in Solidity