BLOCKCHAIN III IA QUESTION BANK

1. Explain Ethereum keys and addresses.

2. Write a short note on i) Execution environment ii) Machine
state iii) Native contracts
3. Write short note on Ethereum Virtual Machine.
4. Illustrate the state storage in the Ethereum blockchain with a neat
diagram.
5. Define hyperledger? With neat diagram explain categorization of
hyperledger projects
6. Explain different types of libraries with respect to hyperledger.
7. With neat diagram explain hyperledger reference architecture
8. Define hyperledger fabric?Explain different types of services of
hyperledger fabric.
9. Explain transaction lifecycle in hyperledger fabric
10.Explain sawtooth transaction life cycle.
11.Define Corda? Explain the network architecture of corda with neat
diagram.
12.Explain different types of Cordapps
13.with neat diagram explain different components of Corda.
1.ANS

Keys and addresses Keys and addresses are used in the Ethereum blockchain
to represent ownership and transfer ether. The keys used are made up of pairs
of private and public parts. The private key is generated randomly and is
kept secret, whereas a public key is derived from the private key. Addresses
are derived from public keys and are 20-byte codes used to identify
accounts.

The process of key generation and address derivation is as follows:

1. First, a private key is randomly chosen (a 256-bit positive integer) under

the rules defined by the elliptic curve secp256k1 specification (in the range
[1, secp256k1n − 1]).

2. The public key is then derived from this private key using the Elliptic
Curve Digital Signature Algorithm (ECDSA) recovery function.

3. An address is derived from the public key, specifically, from the rightmost
160 bits of the Keccak hash of the public key.

An example of how keys and addresses look in Ethereum is shown as

follows:

• A private key:
b51928c22782e97cca95c490eb958b06fab7a70b9512c38c36974f47b954ffc4
• A public key:
3aa5b8eefd12bdc2d26f1ae348e5f383480877bda6f9e1a47f6a4afb35cf998ab
847 f1e3948b1173622dafc6b4ac198c97b18fe1d79f90c9093ab2ff9ad99260

• An address: 0x77b4b5699827c5c49f73bd16fd5ce3d828c36f32
2. Ans(i)

Explanation of Each Element in the Execution Environment Tuple:

1. Address of Code Owner

• This is the address of the contract whose code is running.

• It sets the environment or context in which the code runs.

2. Sender Address

• This is the address of the person (or contract) who started the transaction or call.

• In Solidity, you can get it using msg.sender.

3. Gas Price

• It's how much the sender is willing to pay per unit of gas.

• Higher gas price can make your transaction get picked up faster by miners.

4. Input Data

• This is the data sent to the contract, like function name and parameters.

• It tells the contract what to do or which function to run.

 5. Initiator Address

• The original address that started the transaction, even if it went through several
contracts.

• It helps to know who actually began the process.

6. Value

• The amount of Ether (in wei) sent with the transaction.

• You can use msg.value in Solidity to access this amount.

7. Bytecode

• This is the compiled version of the smart contract code.

• It runs on the Ethereum Virtual Machine (EVM) and lives on the blockchain.

8. Block Header

• Information about the block, like time, number, and difficulty.

• Useful when contracts need data from the blockchain itself.

9. Message Call Depth

• It shows how deep the current call is in a chain of contract calls.

• This prevents errors like going too deep or calling endlessly.

10. Permission

• These are rules or settings that define what actions the contract can take.

• Helps in controlling access and protecting contract functions.

(ii)

Explanation of Each Element in the Machine State Tuple:

1. Available Gas

o Indicates how much gas is left for the execution.

o Execution halts if gas runs out.

o Ensures computational limits are not exceeded.

2. Program Counter (PC)

o A pointer to the current instruction being executed in the bytecode.

o Increments as the code executes, controlling the flow of instructions.

3. Memory Contents

o Represents the temporary memory used during execution.

o It is volatile and cleared after execution.

o Used for storing data needed only during execution (not persistent).

4. Number of Words

o Memory in EVM is divided into 32-byte words.

o This indicates how many such words are in use.

 o Affects the cost of memory usage (gas cost increases with more words).

5. Stack Contents

o The EVM uses a stack-based architecture.

o Stack is used for operand storage and intermediate calculations.

o Has a maximum depth of 1024 elements.

(iii)

Native Contracts in Ethereum (Istanbul Release)

In Ethereum, native contracts (also called precompiled contracts) are special contracts that
are hardcoded into the Ethereum Virtual Machine (EVM). They are optimized for
performance and perform complex cryptographic functions with reduced gas costs.

The Istanbul release of Ethereum includes 9 native contracts at fixed addresses (0x01 to
0x09). These are:

List and Explanation of Native Contracts:

1. ECREC (ECDSARECOVER) – Address: 0x01

o Recovers public key from ECDSA signature.

o Input: Hash H, signature values V, R, S.

o Gas: 3000.

o Output: 64-byte public key.

2. SHA256 – Address: 0x02

o Computes SHA-256 hash of input data.

o Output: 32 bytes.

o Gas depends on input size.

3. RIPEMD160 – Address: 0x03

o Computes RIPEMD-160 hash.

o Output: 20 bytes.

o Gas depends on input size.

4. Identity Function (ID) – Address: 0x04

 o Outputs the same value as input (data copy).

o Gas: 15 + 3 * (input size / 32).

5. Big Mod Exponentiation – Address: 0x05

o Performs modular exponentiation for cryptography (e.g., RSA).

6. Elliptic Curve Point Addition – Address: 0x06

o Adds two points on an elliptic curve.

7. Elliptic Curve Scalar Multiplication – Address: 0x07

o Multiplies an elliptic curve point by a scalar.

8. Elliptic Curve Pairing (BN256 pairing) – Address: 0x08

o Used in zk-SNARKS for zero-knowledge proofs.

9. BLAKE2 Compression Function (F) – Address: 0x09

o Enables BLAKE2b hashing (used in Zcash/Equihash).

3 ANS

Ethereum Virtual Machine (EVM) – Operation and Storage

The Ethereum Virtual Machine (EVM) is a 256-bit stack-based virtual machine used to
execute smart contracts in Ethereum. It transforms the system state by executing bytecode
instructions.
 EVM Operation

Refer to the diagram (Figure 11.11):

1. Program Code:
Stored in Virtual ROM, this is the smart contract bytecode.

2. CODECOPY Instruction:
Copies program code from ROM to Main Memory for execution.

3. Main Memory:
A temporary, word-addressable memory (like RAM), where instructions (like PUSH,
ADD, STOP) are stored as 256-bit words.

4. Program Counter:
Keeps track of the next instruction to be executed.

5. EVM Stack:
A LIFO stack with a maximum depth of 1024, used to perform all computations. It
stores 32-byte (256-bit) values. Instructions operate by pushing/popping values
on/from the stack.

6. Execution:

o Bytecode is executed step-by-step.

o Each instruction uses stack elements and updates memory/state.

o Execution is limited by gas, preventing infinite loops or DoS attacks.

7. Exception Handling:
If gas runs out or an invalid instruction is encountered, the EVM halts execution and
reverts changes.

Types of EVM Storage

Storage
Description Volatile Access
Type

Temporary, word-addressable byte array (like Read: 256-bit, Write:

Memory Yes
RAM). Cleared after execution. 8 or 256-bit

Permanent key-value store (each 256-bit). Only accessible by the

Storage No
Persists on blockchain. contract
Storage
Description Volatile Access
Type

256-bit LIFO stack with max 1024 elements.

Stack Yes Limited but fast
Used for computation.

4.ANS

State Storage in Ethereum

Ethereum is a state machine – every transaction changes the state of the system. That state
must be securely stored and verifiable, which is done using data structures like tries (prefix
trees) and hashes.

What is the World State?

• The World State is a big map (or dictionary) from:

Ethereum Address ➝ Account State

• It’s stored using a Merkle Patricia Trie (MPT) for efficient verification, updating,
and security.

• This trie is hashed into a State Root, stored in the block header (proof of the whole
blockchain state at that block).

Account State (4 Fields)

Each account has the following 4 key fields:

Field Description

Number of transactions sent from the account (used to prevent replay attacks).
Nonce
For contracts, it’s the number of contracts created.

Balance Amount of Ether (in wei) in the account.

Storage
Root hash of the Account Storage Trie (MPT) that stores smart contract data.
Root

Code Keccak-256 hash of the smart contract code. For externally owned accounts
Hash (EOAs), it's the hash of an empty string.

Diagram Explanation

Let’s break the diagram step by step:

1. Account State

• Stores nonce, balance, storage root, and code hash.

2. Account Storage Trie

• Contains actual smart contract storage (like key-value data).

• It’s a mapping from hashed keys ➝ encoded values.

• The root hash of this trie is the storage root field in the account.

3. World State Trie

• Maps Ethereum addresses ➝ Account States.

• The root hash of this trie is known as the State Root.

• This root is stored in the block header, so any node can verify the full Ethereum state
using this hash.

How it all connects:

Smart contract storage ⟶ Account Storage Trie

⬑ gives Storage Root ⬅ Account State (4 fields)

 ⬑ stored in ⬅ World State Trie

⬑ root hash is ⬅ State Root in Block Header

5.ANS

What is Hyperledger?

• Hyperledger is NOT a blockchain itself.

• It’s an open, shared project started by the Linux Foundation in 2015.

• Its goal is to help create tools and frameworks so companies can build strong
and secure blockchain applications.

• Many companies (more than 300) work together on it.

• It focuses on making blockchains that can be used across different industries,

are fast, private, and easy to scale.

Types of Hyperledger Projects

Hyperledger organizes its projects into 4 main groups:

1. Distributed Ledgers
These are actual blockchain platforms that you can use to build and run blockchain
networks.

• Fabric: A flexible and secure blockchain for businesses where only approved
members can join.

• Sawtooth: Can be used both with open or permissioned networks.

• Iroha: Simple and works well on mobile devices.

• Indy: Specially made for managing digital identities.

• Besu: Works with Ethereum networks, both public and private.

• Burrow: Focuses on smart contracts and supports Ethereum’s virtual machine.

2. Libraries

These are sets of tools that developers can reuse when building blockchain
applications.

• Aries: Helps with secure identity communication between users.

• Transact: Manages how transactions are executed on blockchains.

• Quilt: Helps move money or assets across different blockchains.

• Ursa: A shared security toolkit for cryptography.

3. Tools

Helpful software for managing and working with blockchains.

• Avalon: Keeps computing confidential and secure.

• Cello: Makes it easy to create and manage blockchain networks like a service.

• Caliper: Tests how well a blockchain performs.

• Explorer: Lets you see what’s happening on a blockchain through a user-

friendly webpage.
4. Domain-Specific

Projects focused on certain industries or new ideas.

• Grid: Tools for building supply chain blockchain apps.

• Labs: A place to try out new or experimental blockchain ideas.

6.ANS

Types of libraries in Hyperledger

1. Hyperledger Aries

• What it is: A toolkit for handling digital identities and secure communication
between people or systems.

• Why it’s useful: It helps build systems where users control their own digital identity
and can share verified information safely.

• Example: Imagine a digital ID card that you own and can share with others without
needing a middleman.

2. Hyperledger Transact

• What it is: A tool that helps run and manage the rules for transactions (like contracts
or agreements) on different blockchains.

• Why it’s useful: It allows developers to write transaction logic once and use it on
different blockchain platforms.

• Example: You write a set of rules for buying and selling something, and you can run
those rules on different blockchains like Sawtooth or Fabric.

3. Hyperledger Quilt

• What it is: A tool that helps different blockchains talk to each other and move money
or assets between them.

• Why it’s useful: It lets you transfer value across different blockchain networks
smoothly.

• Example: Sending money from an Ethereum blockchain to a Hyperledger Fabric

blockchain without trouble.
4. Hyperledger Ursa

• What it is: A shared toolkit for cryptography (which is like secret codes and security
math).

• Why it’s useful: It helps all projects use strong, tested security methods without each
project having to build their own from scratch.

• Example: When a project needs to securely sign data or prove something without
revealing too much info, it uses Ursa to do it safely.

7.ANS
 What is this diagram?

This diagram shows how Hyperledger, an enterprise blockchain platform, is built from
different parts — like building blocks that work together to run a secure and trusted
blockchain network.

Main Parts of the Diagram:

There are 5 major parts (colored boxes) that represent different jobs in the system:

1. IDENTITY (Who are you?)

• Purpose: To recognize and identify people or systems in the network.

• Includes:

o Ledger Identities: Identifies who is allowed to use the blockchain.

o Resource Identities: Identifies parts of the network like computers or

services.
 Like a student ID card in a college. It shows who you are and what access you
have.

2. POLICY (What can you do?)

• Purpose: To set the rules for who can do what.

• Includes:

o Configuration: Settings of the system.

o Access Control: Who can read/write data.

o Privacy: Keeps data safe and private.

Like college rules – who can enter which building, who can see exam results, etc.

3. BLOCKCHAIN (Where is the data?)

• Purpose: To handle the main blockchain functions.

• Includes:

o Consensus Manager: Makes sure all participants agree on the data.

o Distributed Ledger: The actual data shared with everyone.

o P2P Protocol: How computers in the network talk to each other.

o Ledger Storage: Where data is saved.

Like a shared online notebook that everyone can see but can’t change without
permission.

4. TRANSACTIONS (What is happening?)

• Purpose: To manage all transactions — like sending or updating data.

• It sits above the blockchain, meaning it works with the blockchain to process
activities like:

o Submitting data
 o Checking if it’s valid

o Recording it

Like the main office that handles all form submissions in a college.

5. SMART CONTRACTS (What are the rules?)

• Purpose: To define automated logic or business rules in code.

• Includes:

o Secure Container: A safe place to run the code.

o Registry: Stores all smart contracts.

o Life Cycle: Manages how contracts are created, updated, or deleted.

Like a vending machine — you press a button (trigger a contract), and it gives
you something automatically based on rules.

Event Stream (Communication System)

• Allows all parts to send messages and updates to each other.

• Like a notice board or WhatsApp group where everyone gets updates in real-
time.

8.ANS

Definition: What is Hyperledger Fabric?

Hyperledger Fabric is a permissioned blockchain platform developed by IBM and

Digital Asset under the Hyperledger project.

Hyperledger Fabric is a private and secure blockchain system where only authorized
members can join, share data, and run business logic using smart contracts (called
chaincode here). It's modular, flexible, and supports smart contracts in different
languages like Go, Java, and Node.js.

Types of Services in Hyperledger Fabric (Explained Simply):

1. Membership Services

• Manages who can join the blockchain network.

• Verifies user identity using a Certificate Authority (CA).

• Issues:

o E-Certs (Enrollment Certificates) for long-term identity

o T-Certs (Transaction Certificates) for temporary/one-time use

Think of it like a college ID system where only registered students/staff are allowed
in.

2. Blockchain Services

This includes all the core blockchain functionalities:

a. Consensus Services

• Decides which transactions are valid and in what order.

• Handled by a special peer called the Orderer.

• Consensus methods supported:

o SOLO (for testing)

o Kafka (crash-tolerant)

o Raft (leader-based)

o PBFT (Byzantine fault-tolerant)

Like a teacher arranging all answer sheets in the right order.

b. Distributed Ledger

• Made up of:

o Blockchain = List of blocks with transactions.

o World State = Current state stored as a key-value database using

LevelDB or CouchDB.

Like your notebook (blockchain) + marks list (world state) that keeps getting
updated.
c. Peer-to-Peer (P2P) Protocol

• Used by peers (nodes) to communicate.

• Types of messages:

o Discovery, Transaction, Sync, Consensus

Like students sharing info using WhatsApp – who’s online, what’s new, etc.

d. Ledger Storage

• Data is stored on each peer’s local database (LevelDB or CouchDB).

• CouchDB allows for advanced search (rich queries).

3. Smart Contract Services

• These are rules and logic written in code, called Chaincode in Fabric.

• Run in secure Docker containers.

• Supports languages like Go, Java, Node.js.

Components:

• Secure Container – Safe place to run the code.

• Secure Registry – Stores all deployed contracts.

• Events – Used to notify apps when something happens.

Like an automatic vending machine that gives items when rules are met.

9.ANS
 Transaction Lifecycle in Hyperledger Fabric (Figure 17.8 Explained)

Purpose:

This diagram shows how a transaction flows from a client to the ledger, passing through
various components like endorsers, orderers, and committers.

Step-by-Step Explanation:

1. Transaction Proposal (Client → Endorser)

• The Application or Client prepares a transaction proposal (e.g., "transfer ₹500").

• It sends this to Endorsing Peers via the Fabric SDK.

• Only registered users (via Membership Service Provider) can do this.

2. Simulation by Endorser

• Endorsers simulate the transaction using the chaincode (smart contract).

• It does not update the actual ledger.

 • Instead, it generates a Read-Write Set (RW Set) – a list of what data would
be read/changed.

3. Return Endorsed Transaction

• The endorsed RW Set is signed and sent back to the Fabric SDK.

• If multiple endorsers are required, their responses must match (endorsement

policy).

4. Submitting Transaction (SDK → Orderer)

• The Fabric SDK sends the endorsed transaction to the Orderer.

• The orderer does not verify the logic – it just takes the transaction and queues it.

5. Sorting & Packaging (by Orderer)

• The Orderer collects transactions from many clients.

• It sorts and groups them into a block (like a batch).

• Each block is organized by channel (private network segment).

6. Broadcast to Committing Peers

• The new block is broadcast to all Committing Peers.

7. Validation by Committers

• Each committer checks:

o If the transaction meets the endorsement policy

o If the RW Set still matches the current world state

• Invalid transactions are marked and not committed.

8. Committing to the Ledger

• Valid transactions are written to the ledger.

 • The ledger has:

o The blockchain (history)

o The world state (current data)

9. Notification to Client

• The committing peers send a notification (success/failure) back to the application

via the Fabric SDK.

10.ANS

Sawtooth Transaction Lifecycle (Explained Simply)

What is this about?

This diagram shows how a transaction (e.g., "transfer coins" or "update product
status") flows through the Hyperledger Sawtooth network — from a client all the way
to being saved in the blockchain.

Step-by-Step Flow:

1. Client Sends Transaction

• A client creates and sends a transaction using a REST API to a validator node.
 • This is like submitting a form to the blockchain.

• Default API Port: 8008

2. Validator Propagates Transaction

• The validator node shares the transaction with other validators in the network.

• This ensures that everyone is aware of the new transaction.

3. Leader Creates Candidate Block

• One of the validators is chosen as the leader (by the consensus engine).

• This leader puts the transaction(s) into a candidate block — a proposed new
block for the chain.

4. Block Propagation

• The candidate block is now sent to all validators in the network.

• Think of this as sharing the proposed update with the whole class before
finalizing it.

5. Validation of Block

• Other validators check:

o Is the block valid?

o Are the transactions inside valid?

• This step uses a transaction processor (smart contract logic) to check and
execute each transaction inside the block.

6. Block is Committed

• Once the block passes all checks:

o It is written to the blockchain (block).

 o The current state of the blockchain is updated (state).

o All validators do this locally (in their own copy of the ledger).

11.ANS

Definition of Corda (Simple Words):

Corda is a distributed ledger platform, not a traditional blockchain because it doesn’t

use blocks to store transactions. Instead, it allows direct transactions between parties in
a secure and private way.

• Originally designed for the financial industry, but now used in healthcare,
insurance, supply chain, and government.

• Solves the problem of different organizations keeping their own copies of data,
reducing errors, cost, and complexity.

• It comes in two versions:

o Corda Open Source – free and community-based

o Corda Enterprise – for businesses with extra features like firewall, high
availability, and better security

Corda Network Architecture (Explained with Diagram):

Below is a simplified explanation of the architecture:

Main Components:

1. Corda Node:

o The main component that runs the Corda software.

o Communicates with other nodes directly (P2P).

2. Network Map Service:

o Keeps a directory of all nodes (like a phonebook).

o Helps nodes find each other.

3. Doorman (Permissioning):

o Issues identity certificates.

o Ensures only trusted nodes join the network.

4. Notary Service:

o Provides consensus (prevents double-spending).

o Confirms if a transaction is valid.

5. Vault:

o Stores the current states (data) locally.

o Connected using JDBC (Java Database Connectivity).

6. Client Applications:

o External apps that interact with Corda nodes.

o Use secure communication (RPC over TLS).

7. Administrator:

o Manages the node using SSH.

8. AMPQ / TLS:

o Communication protocol used between nodes.

o Ensures data is private and secure.

13.ANS

Corda Components Explained with Diagram

Diagram Overview: Simplified Corda Node Architecture

Main Components of Corda

1. Node

• A Node is like a computer running Corda software.

• It belongs to a company and has a unique identity.

• It talks to other nodes and handles apps and services.

Inside a Node (from the diagram):

a. Persistence Layer

• Stores data locally in a relational (SQL) database.

• Keeps track of transactions and vault data.

b. Network Interface

• Helps the node talk to other nodes securely.

• Uses AMQP (a messaging protocol) with TLS for safety.

c. RPC Interface

• RPC means Remote Procedure Call.

 • Lets the node owner (or external systems) interact with the node using a web
interface or program.

d. Service Hub

• Offers helpful tools and services (e.g., access to vaults, storage) that CorDapps
and flows can use.

e. Other Node Services

• Utility services such as notaries, oracles, etc., to support app logic.

f. CorDapp Interface

• Allows the node to run CorDapps (Corda Decentralized Apps).

• CorDapps are smart contracts and workflows built for business use.

Other Important Network Components

2. CorDapps

• Apps that run on the node.

• Help automate business logic like contracts, approvals, and transactions.

3. Other Nodes

• Nodes from other organizations that your node talks to.

• Transactions happen between nodes directly.

4. Node’s Owner

• The organization or person who owns the node.

• Communicates with the node via RPC client and Web server.

Supporting Network Services

5. Permissioning Service (Doorman)

• Verifies the identity of each node.

• Performs KYC (Know Your Customer).

• Issues TLS certificates to join the network securely.

6. Network Map Service

 • Like a phonebook for all the nodes in the network.

• Keeps info like IP addresses, services, certificates.

7. Notary Service

• Ensures transaction uniqueness (no double-spending).

• Signs and timestamps transactions.

• Can use different algorithms like BFT or Raft.

8. Oracle Service

• Feeds real-world data into the Corda network (like exchange rates, weather,
etc.).

• Can verify facts or sign transactions based on facts.

Transactions in Corda

• Only shared between involved parties, not the whole network.

• Include: inputs, outputs, commands, signatures, timestamps, etc.

Vaults

• Like wallets in Bitcoin.

• Store transaction data relevant to the node.

• Use SQL databases and can hold both on-ledger and off-ledger data.