M.

Sc (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

BLOCKCHAIN TECHNOLOGY
Module 4 — Hyperledger & Blockchain Application Development
[Link] (IT) | Year II / Semester IV | SVKM's UPG College | 2024-25
Duration: 15 Lectures · Exam Weightage: ~25%

Part A — Hyperledger: Overview, Fabric Architecture, Composer, Installing Hyperledger Fabric

and Composer, Deploying and Running the Network, Error Troubleshooting
Part B — Blockchain Application Development: Decentralised Applications, Blockchain App
Development, Interacting with Bitcoin Blockchain, Interacting Programmatically with Ethereum —
Sending Transactions, Creating a Smart Contract, Executing Smart Contract Functions, Public vs
Private Blockchains, Decentralised Application Architecture

Page 1 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

PART A — HYPERLEDGER

1. Hyperledger — Overview
Hyperledger is an open-source umbrella project hosted by the Linux Foundation, launched in
December 2015. It provides a suite of frameworks, tools, and libraries for building enterprise-grade,
permissioned blockchain solutions. Unlike Bitcoin or Ethereum, Hyperledger is NOT a single
blockchain — it is a collection of enterprise blockchain projects.

1.1 Why Hyperledger?

• Enterprise requirements: Businesses need privacy (confidential transactions), known
participants (permissioned), high performance (thousands of TPS), regulatory compliance,
and auditability — none of which public blockchains provide easily.
• Hyperledger mission: Advance cross-industry blockchain technologies for business use.
Make enterprise blockchain as accessible as open-source software like Linux.
• Governance: Linux Foundation provides neutral governance. No single company controls it.
Major contributors: IBM, Intel, SAP, Huawei, Accenture, J.P. Morgan.
• NOT a cryptocurrency: Hyperledger projects do not have tokens or coins. The blockchain
stores business data, not financial transactions.

1.2 Hyperledger vs Public Blockchains

Public Blockchain (Ethereum/Bitcoin) Hyperledger (Permissioned)

Open/permissionless — anyone can join Permissioned — only authorised members
Anonymous/pseudonymous participants Known, identified participants (X.509 certs)
Public — all see all transactions Private — data shared selectively via
channels
PoW/PoS consensus — slow BFT/Raft consensus — fast (3,500+ TPS)
Cryptocurrency-based incentives No cryptocurrency — business logic only
Immutable — very hard to upgrade Upgradeable chaincode (smart contracts)
Global, single ledger Multiple channels = multiple sub-ledgers
Use: DeFi, NFTs, public payments Use: Supply chain, healthcare, trade finance

1.3 Hyperledger Frameworks (Projects)

Hyperledger Fabric (IBM): Most widely used. Modular architecture. Supports channels (private
sub-networks). Chaincode in Go, Java, JavaScript. Used by Walmart, Maersk, HSBC.
Hyperledger Besu (ConsenSys): Ethereum client for enterprise. Supports both public Ethereum
and private permissioned networks. EVM-compatible — Solidity smart contracts work.
Hyperledger Sawtooth (Intel): Uses Proof of Elapsed Time (PoET) consensus — energy efficient.
Pluggable transaction processors.
Hyperledger Indy: Purpose-built for decentralised identity management. Self-Sovereign Identity
(SSI). W3C DID standard.

Page 2 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

Hyperledger Iroha: Designed for mobile and IoT. Simple Byzantine fault-tolerant consensus (YAC
— Yet Another Consensus).
Hyperledger Cactus: Cross-chain integration toolkit. Connect different blockchains.
Hyperledger FireFly: Enterprise Web3 middleware. REST API for blockchain integration.

1.4 Hyperledger Tools

• Hyperledger Caliper: Blockchain benchmarking tool. Measure performance (TPS, latency)
across different networks.
• Hyperledger Explorer: Web-based blockchain explorer for visualising network activity,
blocks, transactions, nodes.
• Hyperledger Cello: Deployment and management of blockchain networks as a service
(BaaS — Blockchain as a Service).
• Hyperledger Aries: Toolkit for building decentralised identity (DID) agents and wallets.
💡 EXAM TIP: Hyperledger overview question: Explain purpose, 4 key frameworks (Fabric,
Besu, Sawtooth, Indy) with 1 sentence each, and why enterprise needs permissioned
blockchain (5 reasons).

2. Hyperledger Fabric — Architecture

Hyperledger Fabric is the flagship enterprise blockchain platform. Its modular, pluggable
architecture allows organisations to configure it for their specific needs. It is the most production-
deployed enterprise blockchain.

2.1 Core Design Principles

• Permissioned: All participants must have a valid identity issued by a Certificate Authority
(CA). No anonymous participation.
• Modular: Pluggable consensus, pluggable membership service, pluggable chaincode
container.
• Channels: Private sub-networks within the Fabric network. Each channel has its own
ledger. Only channel members can see transactions. Enables multiple business
relationships on one network.
• Chaincode: Smart contracts in Fabric. Can be written in Go, JavaScript ([Link]), or Java.
Run in Docker containers (sandboxed). Installed on peers and instantiated on channels.
• No cryptocurrency: No mining, no tokens. Transactions are business logic, not financial
transfers.

2.2 Fabric Network Components

1. Peers:
• The fundamental network nodes that host ledger and chaincode.
• Endorsing Peers: Execute chaincode and endorse (sign) transaction proposals. Each
channel has a defined endorsement policy specifying which peers must endorse.
• Committing Peers: All peers. Validate and commit endorsed transactions to the ledger.
• Anchor Peers: One per organisation. Used for cross-organisation peer discovery.
2. Orderer (Ordering Service):
• Receives endorsed transactions from all organisations, orders them into a block, distributes
blocks to all peers.
• Consensus happens here. Current options: Raft (CFT — Crash Fault Tolerant, default
since Fabric 2.0).
• Does NOT execute chaincode. Does NOT access ledger directly. Only orders.

Page 3 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

• Operates as a cluster for fault tolerance. Recommended: 3 or 5 orderer nodes.

3. Certificate Authority (Fabric CA):
• Issues X.509 certificates to all network participants (peers, orderers, clients, admins).
• Identity = X.509 certificate. Your certificate's attributes define your permissions.
• MSP (Membership Service Provider): Defines which CAs are trusted. Maps certificates to
roles.
• Can use external CAs (LDAP, hardware HSMs) instead of Fabric CA.
4. Ledger:
• Two components: World State (database of current key-value pairs — CouchDB or
LevelDB) and Blockchain (sequential log of all transactions forming the chain).
• World State: The current state after applying all transactions. Queried by chaincode.
Updated by commits.
• Blockchain (Transaction Log): Append-only log. Immutable. Each block references previous
block hash.
• CouchDB: Enables rich JSON queries. Better for complex business data models.
• LevelDB: Simpler key-value store. Faster for simple gets/puts. Default.
5. Channel:
• A private communication subnet within the Fabric network.
• Each channel has: its own ledger, its own set of member organisations, its own
chaincode(s), its own MSP.
• Transactions on Channel A are completely invisible to members of Channel B — even on
the same Fabric network.
• Use case: A bank network with channels: 'Bank A ↔ Bank B settlement', 'Bank A ↔ Bank
C settlement' — each pair sees only their transactions.
6. Smart Contract / Chaincode:
• Business logic encapsulated in a container (Docker) running on peers.
• Can read/write to the ledger's world state.
• Must be installed on peers and approved + committed to a channel before execution.
• Fabric v2.0: Decentralised chaincode lifecycle — all organisations must approve before
instantiation.

2.3 Fabric Transaction Flow — Step by Step

The Fabric transaction flow is unique: it separates execution (endorsement) from ordering
(consensus) from validation (commit). This 'execute-order-validate' architecture achieves high
throughput.
• Step 1 — PROPOSE: Client SDK sends a transaction proposal to endorsing peers.
Proposal includes: chaincode ID, function name, arguments, client identity.
• Step 2 — EXECUTE & ENDORSE: Each endorsing peer executes the chaincode
(simulates transaction — does NOT write to ledger yet). Returns a ReadSet (data read) and
WriteSet (data to be written) plus the peer's digital signature = endorsement.
• Step 3 — COLLECT ENDORSEMENTS: Client collects endorsements from all required
peers (per endorsement policy, e.g., 'majority of Org1 AND Org2 peers must endorse').
• Step 4 — SUBMIT TO ORDERER: Client sends the endorsed transaction to the Ordering
Service.
• Step 5 — ORDER & CREATE BLOCK: Orderer batches transactions from multiple clients,
orders them, creates a block, distributes to all peers.
• Step 6 — VALIDATE & COMMIT: Each peer independently validates: endorsement
signatures match policy, ReadSet still valid (no MVCC conflict — no other transaction
changed those keys since endorsement), then commits block to local ledger.
• Step 7 — NOTIFY: Peers emit events. Client SDK notified of transaction commit.

Page 4 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

Fabric Execute-Order-Validate Traditional Blockchain (Order-Execute)

Chaincode runs before consensus Consensus before execution (e.g., Ethereum)
Parallel execution across orgs Sequential execution on all nodes
Conflicts detected at commit Conflicts prevented by sequential ordering
Throughput: 3,500+ TPS Throughput: 15-30 TPS (Ethereum)
Determinism enforced by MVCC Determinism enforced by single order
Private data via endorsement All nodes see all execution

💡 EXAM TIP: Fabric transaction flow = guaranteed 10-mark question. Learn all 7 steps in
order: Propose → Execute+Endorse → Collect → Submit → Order+Block → Validate+Commit
→ Notify.

3. Hyperledger Composer
Hyperledger Composer was a high-level application development framework for Hyperledger
Fabric. It significantly simplified the development of business networks by providing a modelling
language, REST API generator, and tooling.
⚠️ Important Note: Hyperledger Composer was deprecated in August 2019. It is no longer
actively maintained. However, it is still exam-relevant as it illustrates key concepts of Fabric
application development.

3.1 Composer Concepts

Business Network Definition: A package describing: participants, assets, transactions, access
control rules, and queries. Defined using Composer Modelling Language (.cto files).
Participants: Individuals or organisations who interact with the network. E.g., Farmer, Retailer,
Regulator.
Assets: Items of value exchanged or tracked. E.g., Commodity, Vehicle, PatientRecord.
Transactions: Business activities that change asset state. E.g., Trade, Transfer, UpdateRecord.
Access Control Lists (ACL): Define who can do what. E.g., Farmer can update their own assets;
Regulator can read all assets.

3.2 Composer Business Network File Structure

my-business-network/
├── [Link] # npm package descriptor
├── [Link] # Access Control Rules
├── [Link] # Named Queries
└── lib/
└── [Link] # Transaction processor functions
(JavaScript)
└── models/
└── [Link] # Data model (participants, assets,
transactions)

3.3 Sample Composer Model (.cto)

namespace [Link]

Page 5 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

// Define an asset
asset Commodity identified by tradingSymbol {
o String tradingSymbol // Primary key
o String description
o Double quantity
--> Trader owner // Relationship to participant
}

// Define a participant
participant Trader identified by tradeId {
o String tradeId
o String firstName
o String lastName
}

// Define a transaction
transaction Trade {
--> Commodity commodity // Asset being traded
--> Trader newOwner // New owner
}

3.4 Composer Tools

• composer-cli: Command-line tool for deploying and managing business networks.
• composer-rest-server: Auto-generates a REST API from a deployed business network.
Swagger UI for testing.
• composer-playground: Browser-based IDE for modelling and testing business networks
([Link]).
• Yeoman generator: Scaffold new Composer projects quickly.
💡 EXAM TIP: Composer question: Explain 4 concepts (participants, assets, transactions,
ACL) with examples. Mention it is deprecated but used for conceptual understanding of Fabric
application structure.

4. Installing Hyperledger Fabric and Composer

Setting up a Hyperledger Fabric development environment requires Docker, Docker Compose,
[Link], and the Fabric binaries. This section covers the complete installation process.

4.1 Prerequisites

Prerequisite Version / Details

Operating System Ubuntu 20.04/22.04 LTS (recommended),
macOS, Windows WSL2
Docker Version 20.10+ — runs Fabric components
as containers
Docker Compose Version 1.29+ — orchestrates multi-container
Fabric network
[Link] Version 16.x LTS — for client SDK and
Composer

Page 6 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

Prerequisite Version / Details

npm Version 6.x+ — Node package manager
Go (Golang) Version 1.19+ — for writing chaincode in Go
Python 2.7 Required by some npm packages during
installation
Git For cloning Fabric samples repository
curl For downloading installation scripts

4.2 Installing Docker on Ubuntu

# Update package index
sudo apt-get update

# Install Docker
sudo apt-get install -y [Link] docker-compose

# Add user to docker group (no sudo needed)

sudo usermod -aG docker $USER
newgrp docker

# Verify Docker installation

docker --version
docker-compose --version

4.3 Installing [Link]

# Install Node Version Manager (nvm)
curl -o- [Link] |
bash
source ~/.bashrc

# Install [Link] v16

nvm install 16
nvm use 16

# Verify
node --version # Should show v16.x.x
npm --version # Should show 8.x.x

4.4 Installing Hyperledger Fabric Binaries and Docker Images

# Create working directory
mkdir -p ~/hyperledger && cd ~/hyperledger

# Download Fabric installation script

curl -sSL [Link] | bash -s -- 2.5.0 1.5.7
# This script:
# 1. Clones fabric-samples repository
# 2. Downloads Fabric binaries (peer, orderer, fabric-ca-client, etc.)
# 3. Pulls Docker images for Fabric components

# Add binaries to PATH

export PATH=$PATH:~/hyperledger/fabric-samples/bin

Page 7 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

# Verify — check peer binary

peer version

# List downloaded Docker images

docker images | grep hyperledger
# Should show: hyperledger/fabric-peer, fabric-orderer,
# fabric-ca, fabric-tools, fabric-ccenv, etc.

4.5 Installing Hyperledger Composer (Legacy)

# Install Composer CLI tools globally
npm install -g composer-cli@0.20
npm install -g composer-rest-server@0.20
npm install -g generator-hyperledger-composer@0.20
npm install -g yo

# Verify Composer installation

composer --version

💡 EXAM TIP: Installation question: List prerequisites (Docker, [Link], Go, Git, curl), explain
what the install script does (3 things: clone, download binaries, pull images), and key
environment setup (PATH).

5. Deploying and Running the Fabric Network

Hyperledger Fabric provides a test network in the fabric-samples repository for learning and
development. The test network has two organisations (Org1 and Org2), each with one peer, plus
an orderer.

5.1 Starting the Test Network

# Navigate to test-network directory
cd ~/hyperledger/fabric-samples/test-network

# Bring down any existing network

./[Link] down

# Start the network (creates channel 'mychannel' by default)

./[Link] up createChannel

# What this does:

# 1. Starts Docker containers: peer0.org1, peer0.org2, orderer
# 2. Creates crypto material (certs, keys) via cryptogen tool
# 3. Creates genesis block for the orderer
# 4. Creates channel 'mychannel'
# 5. Joins both peers to the channel

# Verify containers are running

docker ps
# Expected: peer0.org1, peer0.org2, [Link]

5.2 Deploying Chaincode

# Deploy the basic asset transfer chaincode

Page 8 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

./[Link] deployCC -ccn basic -ccp ../asset-transfer-basic/chaincode-go -

ccl go

# Parameters explained:
# -ccn basic : chaincode name
# -ccp ../asset-... : path to chaincode source
# -ccl go : language (go/java/javascript)

# Behind the scenes this runs Fabric Lifecycle:

# 1. peer lifecycle chaincode package → create .[Link] package
# 2. peer lifecycle chaincode install → install on both peers
# 3. peer lifecycle chaincode approveformyorg → Org1 approves
# 4. peer lifecycle chaincode approveformyorg → Org2 approves
# 5. peer lifecycle chaincode commit → commit to channel

5.3 Interacting with Chaincode via Peer CLI

# Set environment variables for Org1
export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID='Org1MSP'
export CORE_PEER_MSPCONFIGPATH=$PWD/organizations/peerOrganizations/\
[Link]/users/Admin@[Link]/msp
export CORE_PEER_ADDRESS=localhost:7051
export CORE_PEER_TLS_ROOTCERT_FILE=$PWD/organizations/\
peerOrganizations/[Link]/peers/\
[Link]/tls/[Link]

# Initialize ledger (invoke transaction)

peer chaincode invoke \
-o localhost:7050 \
--ordererTLSHostnameOverride [Link] \
--tls --cafile $ORDERER_CA \
-C mychannel -n basic \
--peerAddresses localhost:7051 --tlsRootCertFiles $PEER1_CA \
--peerAddresses localhost:9051 --tlsRootCertFiles $PEER2_CA \
-c '{"function":"InitLedger","Args":[]}'

# Query ledger (read — no transaction)

peer chaincode query -C mychannel -n basic \
-c '{"Args":["GetAllAssets"]}'

# Transfer asset ownership (write transaction)

peer chaincode invoke ... \
-c '{"function":"TransferAsset","Args":["asset6","Christopher"]}'

5.4 Using the Fabric SDK ([Link])

For production applications, use the Fabric Gateway SDK rather than the CLI:
const { Gateway, Wallets } = require('fabric-network');
const path = require('path');
const fs = require('fs');

async function main() {

// Load connection profile
const ccpPath = [Link](__dirname, '[Link]');
const ccp = [Link]([Link](ccpPath, 'utf8'));

Page 9 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

// Load wallet with user identity

const walletPath = [Link]([Link](), 'wallet');
const wallet = await [Link](walletPath);

// Create gateway connection

const gateway = new Gateway();
await [Link](ccp, {
wallet,
identity: 'appUser',
discovery: { enabled: true, asLocalhost: true }
});

// Get network and contract

const network = await [Link]('mychannel');
const contract = [Link]('basic');

// Submit transaction (write)

await [Link]('CreateAsset',
'asset13', 'yellow', '5', 'Tom', '1300');

// Evaluate transaction (read — no network consensus needed)

const result = await [Link]('ReadAsset', 'asset13');
[Link]([Link]([Link]()));

await [Link]();
}
main().catch([Link]);

6. Error Troubleshooting in Hyperledger Fabric

Fabric development involves many moving parts — Docker containers, TLS certificates,
chaincode, and network configuration. Common errors and their solutions:

6.1 Common Errors and Solutions

Error / Symptom Cause & Solution

Cannot connect to Docker daemon Docker not running. Run: sudo systemctl start
docker. Add user to docker group.
Error: no such container Network not running. Run: ./[Link] up
createChannel first.
MVCC_READ_CONFLICT Concurrent transactions modified same key.
Retry logic needed in application. Review
endorsement policy.
Error: endorsement failure Not enough peers endorsed. Check
endorsement policy matches available peers.
Verify TLS certificates.
Container exits immediately Check logs: docker logs <container_name>.
Usually config file error or missing
environment variable.

Page 10 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

Error / Symptom Cause & Solution

Chaincode install failed Wrong Go version, missing dependencies.
Run: go mod tidy in chaincode directory.
TLS handshake failed Certificate mismatch. Regenerate crypto
material: ./[Link] down && ./[Link]
up.
Ledger not found error Channel not joined. Check peer joined
channel: peer channel list.
Error: chaincode not found Chaincode not installed/committed. Re-run
deployCC. Check: peer lifecycle chaincode
querycommitted.
Timeout waiting for block Orderer not reachable. Check orderer
container running. Verify orderer TLS cert
path.

6.2 Useful Diagnostic Commands

# Check all running Fabric containers
docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

# View logs of a specific container

docker logs [Link] 2>&1 | tail -50
docker logs [Link] 2>&1 | tail -20

# Check installed chaincode on peer

peer lifecycle chaincode queryinstalled

# Check committed chaincode on channel

peer lifecycle chaincode querycommitted -C mychannel

# Check which channels a peer has joined

peer channel list

# Get info about a channel

peer channel getinfo -c mychannel

# Clean up everything (reset)

./[Link] down
docker system prune -f # Remove unused containers/images
docker volume prune -f # Remove unused volumes (chain data)

💡 EXAM TIP: Troubleshooting question: List 5 common Fabric errors with cause and
solution. Always include: MVCC_READ_CONFLICT (retry logic), TLS errors (regen crypto),
endorsement failures (check policy).

Page 11 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

PART B — BLOCKCHAIN APPLICATION

DEVELOPMENT

7. Decentralised Applications (DApps)

📌 DApp (Decentralised Application): An application that runs on a decentralised peer-to-peer
network, with its back-end logic defined by smart contracts on a blockchain, rather than on
centralised servers.

7.1 Characteristics of DApps

• Open Source: Code (especially smart contracts) is publicly readable and auditable.
• Decentralised: Back-end runs on blockchain — no single point of control or failure.
• Token-based (optional): Often use crypto tokens for incentives, governance, or utility.
• Protocol-governed: Changes require consensus (token votes, governance proposals) not
executive decisions.
• Censorship resistant: No server to take down. As long as the blockchain runs, the DApp
works.
• Permissionless: Anyone with a wallet can interact — no sign-up, no KYC (for public
DApps).

7.2 DApp Categories

Category Examples
DeFi (Decentralised Finance) Uniswap (DEX), Aave (lending), Compound,
MakerDAO, Curve
NFT Platforms OpenSea, Blur, Foundation, Art Blocks,
SuperRare
Gaming Axie Infinity, Gods Unchained, Decentraland,
The Sandbox
DAOs MakerDAO, Uniswap DAO, Nouns DAO,
Constitution DAO
Social Lens Protocol, Mirror (publishing), Farcaster
Identity ENS (Ethereum Name Service), Worldcoin,
Polygon ID
Insurance Nexus Mutual, Etherisc
Prediction Markets Polymarket, Augur

7.3 DApp vs Traditional App — Full Comparison

Traditional Application DApp

Back end on centralised server Back end is smart contract on blockchain

Page 12 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

Traditional Application DApp

Database: SQL/NoSQL server Database: Blockchain state / IPFS
Auth: Username + Password / OAuth Auth: Wallet + private key signature
Upgrades: Developer deploys new code Upgrades: Governance vote or proxy pattern
Trust: Users trust the company Trust: Users trust auditable code
Data: Company owns all user data Data: Users own their assets (wallets)
Revenue: Subscription, ads Revenue: Protocol fees (often to token
holders)
Availability: Subject to server uptime Availability: 24/7 as long as blockchain runs

💡 EXAM TIP: DApp question: Define DApp (6 characteristics), give 4 examples with
categories, and compare with traditional app (6 differences). Define clearly: open source,
decentralised, token-based, protocol-governed.

8. Blockchain Application Development

Building a blockchain application requires understanding both the on-chain (smart contract) and
off-chain (front-end + backend) components. Modern blockchain development follows a structured
workflow.

8.1 Development Stack Overview

Smart Contract Layer (On-Chain):
• Language: Solidity (Ethereum), Go/JavaScript (Fabric chaincode), Rust (Solana).
• Development frameworks: Hardhat, Foundry, Truffle (deprecated).
• Testing: Hardhat tests (JavaScript/TypeScript), Foundry tests (Solidity).
• Deployment: Hardhat scripts, Foundry scripts.
Front-End Layer (Off-Chain):
• Framework: [Link], [Link], [Link].
• Blockchain library: [Link] (recommended) or [Link].
• Wallet connection: RainbowKit, WalletConnect, Web3Modal.
• State management: React Query / SWR for blockchain data fetching.
Backend/Infrastructure (Optional):
• Indexing: The Graph Protocol — index blockchain events into a queryable GraphQL API.
Far more efficient than querying the chain directly.
• Node providers: Alchemy, Infura, QuickNode — managed Ethereum nodes (no need to run
your own).
• IPFS / Arweave: Decentralised file storage for metadata, images (NFT media).
• Oracles: Chainlink — bring real-world data (prices, weather, sports) onto the chain.

8.2 Development Workflow

• Step 1 — Design: Define smart contract interfaces. What functions? What events? What
state variables? Draw architecture diagram.
• Step 2 — Write: Implement smart contracts in Solidity. Use OpenZeppelin for standard
base contracts.

Page 13 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

• Step 3 — Test: Write unit tests covering all functions, edge cases, and attack scenarios.
Target 100% line coverage.
• Step 4 — Audit: Security audit by professional auditors (Certik, Trail of Bits, OpenZeppelin).
Critical for DeFi.
• Step 5 — Deploy: Deploy to testnet first. Run integration tests. Then deploy to mainnet.
• Step 6 — Verify: Submit source code to Etherscan for public verification.
• Step 7 — Frontend: Build UI connecting to deployed contracts via [Link].
• Step 8 — Monitor: Set up alerts for critical events (large withdrawals, unusual activity,
oracle failures).

8.3 Hardhat Development Environment Setup

# Create new Hardhat project
mkdir my-dapp && cd my-dapp
npm init -y
npm install --save-dev hardhat
npx hardhat init
# Choose: 'Create a JavaScript project'

# Project structure created:

# contracts/ - Solidity smart contracts
# scripts/ - Deploy and interaction scripts
# test/ - Test files (JavaScript/TypeScript)
# [Link] - Network configs, plugin settings

# Install OpenZeppelin contracts

npm install @openzeppelin/contracts

# Compile contracts
npx hardhat compile

# Run tests
npx hardhat test

# Start local Hardhat node

npx hardhat node
# 20 accounts pre-funded with 10,000 ETH each

# Deploy to local network

npx hardhat run scripts/[Link] --network localhost

# Deploy to Sepolia testnet

npx hardhat run scripts/[Link] --network sepolia

9. Interacting with the Bitcoin Blockchain

Interacting with the Bitcoin blockchain programmatically uses Bitcoin's JSON-RPC API exposed by
a running Bitcoin Core node, or through third-party APIs like BlockCypher, [Link] API.

9.1 Bitcoin Core JSON-RPC

Bitcoin Core exposes a JSON-RPC API when started with -server flag. Default port: 8332
(mainnet), 18332 (testnet).

Page 14 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

# Start Bitcoin Core with RPC enabled

bitcoind -server -rpcuser=admin -rpcpassword=password123 -testnet

# Or add to [Link]
server=1
rpcuser=admin
rpcpassword=password123
rpcallowip=[Link]

9.2 Key Bitcoin RPC Commands

RPC Command Description

getblockchaininfo General blockchain info: height, chain,
difficulty
getblockcount Current block height
getblockhash <height> Get block hash at given height
getblock <hash> Get full block data by hash
getrawtransaction <txid> Get raw transaction hex by txid
decoderawtransaction <hex> Decode raw transaction to JSON
getnewaddress Generate new Bitcoin address
getbalance Wallet balance in BTC
sendtoaddress <addr> <amount> Send BTC to address
createrawtransaction Create raw unsigned transaction
signrawtransactionwithwallet Sign raw transaction with wallet key
sendrawtransaction <hex> Broadcast signed transaction to network
listunspent List UTXOs for wallet addresses
estimatesmartfee <blocks> Estimate fee to confirm within N blocks

9.3 Programmatic Bitcoin Interaction ([Link])

const Client = require('bitcoin-core');

// Connect to Bitcoin Core node

const client = new Client({
network: 'testnet',
username: 'admin',
password: 'password123',
host: 'localhost',
port: 18332
});

async function bitcoinDemo() {

// Get blockchain info
const info = await [Link]();
[Link]('Block height:', [Link]);
[Link]('Difficulty:', [Link]);

Page 15 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

// Generate new address

const address = await [Link]();
[Link]('New address:', address);

// Get balance
const balance = await [Link]();
[Link]('Balance:', balance, 'BTC');

// Send transaction
const txid = await [Link](
'tb1qRecipientAddress...',
0.001 // BTC amount
);
[Link]('Transaction ID:', txid);
}
bitcoinDemo();

9.4 Using Block Explorer APIs (No Node Required)

// Using [Link] API (free, no authentication)
const axios = require('axios');

// Get transaction details

const tx = await [Link](
'[Link]
);

// Get address UTXOs

const utxos = await [Link](
'[Link]
);

// Get current fee estimates

const fees = await [Link](
'[Link]
);
[Link]('Fast fee:', [Link], 'sat/vbyte');

💡 EXAM TIP: Bitcoin interaction question: List 6 key RPC commands with purpose. Explain
the workflow to send a Bitcoin transaction programmatically: createrawtransaction →
signrawtransaction → sendrawtransaction.

10. Interacting Programmatically with Ethereum

Ethereum interaction uses the JSON-RPC API via [Link] (recommended) or [Link]. You can
connect to a local Geth node or a managed node provider like Alchemy or Infura.

10.1 Setting Up [Link]

# Install [Link]
npm install ethers

// Import [Link]

Page 16 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

const { ethers } = require('ethers');

// Connect to Ethereum network

// Option 1: Local Geth node
const provider = new [Link]('[Link]

// Option 2: Alchemy (production recommended)

const provider = new [Link](
'[Link]
);

// Option 3: Browser wallet (MetaMask)

const provider = new [Link]([Link]);
const signer = await [Link]();

10.2 Reading Blockchain Data

async function readBlockchainData(provider) {
// Get current block number
const blockNumber = await [Link]();
[Link]('Block number:', blockNumber);

// Get ETH balance

const balance = await [Link]('0xAddress...');
[Link]('Balance:', [Link](balance), 'ETH');

// Get block data

const block = await [Link](blockNumber);
[Link]('Block hash:', [Link]);
[Link]('Transactions:', [Link]);

// Get transaction details

const tx = await [Link]('0xTxHash...');
[Link]('From:', [Link], 'To:', [Link]);
[Link]('Value:', [Link]([Link]), 'ETH');

// Get transaction receipt (after mining)

const receipt = await [Link]('0xTxHash...');
[Link]('Gas used:', [Link]());
[Link]('Status:', [Link] === 1 ? 'Success' : 'Failed');
}

11. Sending Transactions Programmatically

11.1 Sending ETH
async function sendETH(signer) {
// Create and send ETH transfer
const tx = await [Link]({
to: '0xRecipientAddress...',
value: [Link]('0.1'), // 0.1 ETH in Wei
gasLimit: 21000,
// EIP-1559 fee params (optional — [Link] estimates automatically)
maxFeePerGas: [Link]('30', 'gwei'),

Page 17 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

maxPriorityFeePerGas: [Link]('2', 'gwei'),

});

[Link]('Transaction hash:', [Link]);

[Link]('Waiting for confirmation...');

// Wait for 1 confirmation

const receipt = await [Link](1);
[Link]('Confirmed in block:', [Link]);
[Link]('Gas used:', [Link]());
}

11.2 Transaction Lifecycle in Code

• 1. Construct: Define to, value, data, gasLimit.
• 2. Estimate gas: [Link](tx) — get accurate gas limit.
• 3. Get fee data: [Link]() — get current baseFee, maxFeePerGas.
• 4. Sign: [Link](tx) — private key signs.
• 5. Send: [Link](signedTx) — broadcast to network.
• 6. Wait: [Link](n) — wait for n confirmations.
• 7. Handle result: Check [Link] (1 = success, 0 = reverted).

12. Creating a Smart Contract — Full Example

A complete example of a simple ERC-20 token smart contract with minting, burning, and pausing
functionality:

12.1 Complete Token Contract (Solidity)

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

import "@openzeppelin/contracts/token/ERC20/[Link]";
import "@openzeppelin/contracts/token/ERC20/extensions/[Link]";
import "@openzeppelin/contracts/security/[Link]";
import "@openzeppelin/contracts/access/[Link]";

contract CollegeToken is ERC20, ERC20Burnable, Pausable, Ownable {

// Custom event beyond ERC-20 standard

event TokensMinted(address indexed to, uint256 amount);

// Constructor — called once at deployment

constructor(address initialOwner)
ERC20('CollegeToken', 'CLG')
Ownable(initialOwner)
{
// Mint 1 million tokens to deployer
_mint(initialOwner, 1_000_000 * 10 ** decimals());
}

// Pause all transfers — emergency stop

function pause() public onlyOwner { _pause(); }

Page 18 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

function unpause() public onlyOwner { _unpause(); }

// Mint new tokens — only owner

function mint(address to, uint256 amount) public onlyOwner {
_mint(to, amount);
emit TokensMinted(to, amount);
}

// Override to add pause check

function _update(address from, address to, uint256 value)
internal
override
whenNotPaused // Reverts if paused
{
super._update(from, to, value);
}
}

12.2 Hardhat Deploy Script

// scripts/[Link]
const { ethers } = require('hardhat');

async function main() {

const [deployer] = await [Link]();
[Link]('Deploying with:', [Link]);
[Link]('Balance:', [Link](
await [Link]([Link])
), 'ETH');

// Deploy the contract

const CollegeToken = await [Link]('CollegeToken');
const token = await [Link]([Link]);
await [Link]();

const tokenAddress = await [Link]();

[Link]('CollegeToken deployed to:', tokenAddress);
}

main().catch((error) => { [Link](error); [Link](1); });

13. Executing Smart Contract Functions

13.1 Read vs Write Functions

Read Function (view/pure) Write Function (state-changing)

Does NOT change blockchain state Changes blockchain state (storage, balances)
No transaction — just a call Requires a signed transaction
Free — no gas needed Costs gas (paid in ETH)
Instant response Must wait for mining/confirmation

Page 19 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

Read Function (view/pure) Write Function (state-changing)

Examples: balanceOf(), totalSupply() Examples: transfer(), mint(), approve()
[Link]: [Link]() [Link]: [Link]()

13.2 Executing Functions with [Link]

const { ethers } = require('ethers');

// Load contract
const provider = new [Link]('[Link]
const signer = new [Link](PRIVATE_KEY, provider);

const tokenABI = [/* ABI from compilation */];

const tokenAddress = '0xDeployedTokenAddress...';
const token = new [Link](tokenAddress, tokenABI, signer);

async function interactWithToken() {

// ─── READ FUNCTIONS (free, instant) ───────────────────
const name = await [Link]();
const symbol = await [Link]();
const totalSupply = await [Link]();
const myBalance = await [Link]([Link]);

[Link](`${name} (${symbol})`);
[Link]('Total supply:', [Link](totalSupply));
[Link]('My balance:', [Link](myBalance));

// ─── WRITE FUNCTIONS (transaction + gas) ────────────────

// Transfer tokens
const recipient = '0xRecipientAddress...';
const amount = [Link]('100'); // 100 tokens
const transferTx = await [Link](recipient, amount);
[Link]('Transfer tx hash:', [Link]);
const transferReceipt = await [Link]();
[Link]('Confirmed! Gas used:', [Link]());

// Mint new tokens (onlyOwner)

const mintTx = await [Link](recipient, [Link]('500'));
await [Link]();
[Link]('Minted 500 CLG tokens');

// ─── LISTEN FOR EVENTS ──────────────────────────────────

// Listen for Transfer events
[Link]('Transfer', (from, to, value, event) => {
[Link](`Transfer: ${from} → ${to}: ${[Link](value)}
CLG`);
});

// Query historical events

const filter = [Link]([Link]);
const events = await [Link](filter, -1000); // Last 1000 blocks
[Link]('My transfers:', [Link]);
}

Page 20 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

💡 EXAM TIP: Smart contract interaction: Know difference between read (call, free, instant)
and write (transaction, gas, confirmation). Memorise the 5-step pattern: connect provider →
create signer → load contract → call function → wait receipt.

14. Public vs Private Blockchains

The choice between public and private blockchain is one of the most important architectural
decisions in blockchain application development. Each has fundamentally different trust models,
governance structures, and use cases.

14.1 Full Comparison

Dimension Public Blockchain Private Blockchain

Access Open to anyone worldwide Only invited/authorised
participants
Examples Bitcoin, Ethereum, Solana Hyperledger Fabric, R3
Corda, Quorum
Consensus PoW, PoS (unknown BFT, Raft (known validators)
validators)
Throughput 7-30 TPS on-chain 3,500-20,000 TPS
Transaction time Seconds to minutes Milliseconds to seconds
Transaction cost Gas fees (variable, $0.01- Negligible or zero
$100+)
Transparency All transactions public Only visible to members
Privacy Pseudonymous only Full confidentiality via
channels
Immutability Extremely high (PoW Lower — admin can override
security)
Governance Decentralised community Central admin or consortium
Trust model Trustless — code enforces Trusted participants (legal
rules contracts)
Regulatory compliance Difficult (no KYC by default) Easy (known participants,
KYC built-in)
Energy consumption High (PoW) or low (PoS) Very low (no mining)
Best for Public payments, DeFi, NFTs Enterprise: supply chain,
healthcare, finance

14.2 Consortium Blockchain — The Middle Ground

📌 Consortium Blockchain: A semi-private blockchain governed by a group of pre-selected
organisations rather than a single entity or the general public. Also called federated blockchain.
• Access: Restricted to consortium members. Outsiders cannot participate.
• Governance: Multi-party. Decisions require majority of consortium members.

Page 21 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

• Trust: Members trust each other partially — legal agreements + blockchain enforces rules.
• Examples: R3 Corda (bank consortium — HSBC, Barclays), TradeLens (Maersk + IBM,
shipping), Quorum (JPMorgan-led bank consortium), [Link] (trade finance).
• Hyperledger Fabric is the most common platform for consortium blockchains.

14.3 Decision Framework — When to Use Which

Use Case Recommended Type

Cryptocurrency / digital cash Public (Bitcoin, Ethereum)
DeFi / automated market making Public (Ethereum, L2s)
NFTs / digital ownership Public (Ethereum, Solana)
Supply chain between competing companies Consortium (Hyperledger Fabric)
Internal company data/workflow Private (Hyperledger Fabric, Besu)
Interbank settlement Consortium (R3 Corda, Quorum)
Healthcare records across hospitals Consortium (Hyperledger Fabric)
Government land registry Public or Consortium (depends on
transparency needs)
CBDC (Central Bank Digital Currency) Private/Permissioned (Hyperledger Besu,
Fabric)

💡 EXAM TIP: Public vs private question = guaranteed 5-10 marks. Use the 14-row comparison
table. Know: consortium as middle ground with examples (R3 Corda, TradeLens). Explain
decision framework.

15. Decentralised Application Architecture

A well-designed DApp separates concerns across layers, combining on-chain trustlessness with
off-chain performance and usability. Modern DApp architecture has evolved significantly from early
designs.

15.1 DApp Architecture Layers

Layer 1 — Smart Contract Layer (On-Chain Core):
• Location: Deployed on Ethereum mainnet, L2 (Arbitrum, Optimism, Polygon), or other
chains.
• Content: Business logic, state variables, access control, events, token standards.
• Language: Solidity (Ethereum), Rust (Solana), Go (Fabric).
• Key principle: Only put essential logic on-chain. On-chain storage is expensive (20,000
gas/32 bytes = ~$0.50-$5 per storage slot). Off-chain everything possible.
Layer 2 — Indexing & Query Layer (Off-Chain, Near Real-Time):
• The Graph Protocol: Decentralised indexing service. Define a 'subgraph' specifying which
events to index. Query with GraphQL. Real-time updates via subscriptions.
• Problem it solves: Direct blockchain queries are slow (must scan blocks), limited (no
complex filters), and expensive if done frequently. The Graph pre-indexes events into a
queryable database.

Page 22 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

• Example: Uniswap's subgraph indexes all swap events → instant price/volume queries.
Layer 3 — Decentralised Storage (Off-Chain Data):
• IPFS (InterPlanetary File System): Content-addressed storage. Files addressed by content
hash (CID). Decentralised — no single server. Used for NFT metadata and images.
• Arweave: Permanent, pay-once storage. Files stored forever. Used for NFT media that
must be permanent.
• Filecoin: Incentivised IPFS storage — pay for guaranteed persistence.
• Pattern: Store file on IPFS/Arweave → put CID/URL in smart contract storage. Contract
stores reference, not data itself.
Layer 4 — Oracle Layer (External Data Bridge):
• Chainlink: Decentralised oracle network. Brings external data on-chain: price feeds
(ETH/USD), random numbers (VRF), weather, sports scores, API responses.
• Why needed: EVM is deterministic and isolated — cannot access the internet. Oracles are
the bridge.
• Price feeds: Used by every DeFi protocol. Aave uses Chainlink ETH/USD price to
determine collateral ratio.
Layer 5 — Front-End (User Interface):
• Technology: [Link], [Link], [Link]. Static files hosted on IPFS/Arweave or traditional
CDN.
• Wallet connection: MetaMask (browser extension), WalletConnect (mobile QR), Coinbase
Wallet, Rabby.
• Libraries: [Link] for contract interaction, RainbowKit/Web3Modal for wallet UI, wagmi for
React hooks.
• Progressive enhancement: Show read-only data without wallet. Wallet required only for
transactions.

15.2 Complete DApp Architecture Diagram Description

A modern DApp architecture from user to blockchain:
• User → Web Browser (React DApp) → MetaMask wallet → signs transaction
• React DApp ← The Graph GraphQL API ← indexed blockchain events
• React DApp → [Link] → Alchemy/Infura node → Ethereum mainnet
• Smart Contract → reads Chainlink oracle for price data
• Smart Contract → emits events → The Graph indexes → DApp queries
• NFT metadata → IPFS (content-addressed) → DApp fetches and displays

15.3 DApp Architecture Patterns

Minimal On-Chain Pattern:
• Put only ownership records and critical logic on-chain. Everything else off-chain.
• Example: NFT contract stores only tokenId → owner mapping + tokenURI (link to IPFS
metadata). Image and attributes stored on IPFS.
Event-Driven Pattern:
• Smart contracts emit events for all state changes. Off-chain services (The Graph, custom
indexers) listen and build queryable databases.
• UI subscribes to events for real-time updates: [Link]('Transfer', updateBalance).
Proxy/Upgradeable Pattern:
• Separate contract into Proxy (holds storage + address) and Logic (holds code).
• To upgrade: deploy new logic contract, update proxy to point to it. Storage preserved.
• OpenZeppelin Transparent Proxy and UUPS (Universal Upgradeable Proxy Standard) are
the standard implementations.
Multi-Chain Pattern:

Page 23 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

•Deploy same contract on multiple chains (Ethereum mainnet + Arbitrum + Polygon).

•Bridge contract locks tokens on chain A, mints wrapped tokens on chain B.
•Cross-chain messaging: LayerZero, Wormhole, Axelar — send arbitrary messages
between chains.
Account Abstraction (EIP-4337):
• Replace EOAs with smart contract wallets. Enable: gasless transactions (sponsor pays),
social recovery (guardians recover access), multi-sig by default, batched transactions.
• User operation → Bundler → EntryPoint contract → UserWallet contract → Target contract.
• Enables Web2-like UX (email login, no seed phrase) with Web3 security.

15.4 DApp Security Considerations

• Never trust front-end inputs: All validation must be in smart contracts. Front-end can be
compromised.
• Reentrancy guard: Use OpenZeppelin ReentrancyGuard on all functions that transfer ETH
or call external contracts.
• Access control: Every privileged function must check [Link] role. Use OpenZeppelin
Ownable or AccessControl.
• Integer overflow: Use Solidity 0.8+ (built-in overflow checks) or SafeMath.
• Oracle manipulation: Use Chainlink TWAP (time-weighted average price), not spot prices.
• Front-running: Add slippage protection (max deviation from expected price), commit-reveal
for sensitive operations.
• Audit: Get professional security audit before mainnet launch. Use automated tools: Slither,
MythX, Echidna.
💡 EXAM TIP: DApp architecture question: Draw/describe the 5 layers with examples. Know
The Graph (indexing), IPFS (storage), Chainlink (oracle), and the proxy/upgradeable pattern.
Security: list 5 vulnerabilities + mitigations.

MODULE 4 — COMPLETE QUICK REVISION SUMMARY

HYPERLEDGER — Key Points:
• Hyperledger = Linux Foundation umbrella. Enterprise blockchain. Not a cryptocurrency.
• Fabric components: Peers (endorse + commit), Orderer (consensus, ordering), CA (X.509
identity), Channel (private subnet), Chaincode (smart contract in Go/JS/Java).
• Fabric transaction flow: Propose → Execute+Endorse → Collect endorsements → Submit
to Orderer → Order+Block → Validate+Commit → Notify (7 steps).
• Fabric vs Public chain: Permissioned, known participants, BFT consensus, 3500+ TPS, no
cryptocurrency, channels for privacy.
• Composer: Participants + Assets + Transactions + ACL. .cto model file. REST server auto-
generated. DEPRECATED 2019.
• Install: Docker + Docker Compose + [Link] + Go + Git + curl → curl install script → adds
binaries + Docker images.
• Key commands: ./[Link] up createChannel, ./[Link] deployCC, peer chaincode
invoke, peer chaincode query.
• Troubleshooting: MVCC_READ_CONFLICT (retry), TLS handshake (regen crypto),
endorsement failure (check policy).
BLOCKCHAIN APP DEVELOPMENT — Key Points:
• DApp = 6 characteristics: open source, decentralised, token-based, protocol-governed,
censorship-resistant, permissionless.

Page 24 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

• DApp stack: Solidity contracts + Hardhat + [Link] + React + The Graph + IPFS +
Chainlink.
• Bitcoin interaction: JSON-RPC API. Key commands: getblockchaininfo, sendtoaddress,
listunspent, estimatesmartfee.
• Ethereum interaction: [Link]. Connect provider → create signer → load contract → call
functions.
• Read functions = free (call). Write functions = transaction (gas + wait for receipt).
• Public vs Private: Public = open, slow, costly, trustless. Private = permissioned, fast, cheap,
trusted.
• Consortium = middle ground. Examples: R3 Corda (banks), TradeLens (shipping), Quorum
(JPMorgan).
• DApp architecture layers: Smart Contract → Indexing (The Graph) → Storage (IPFS) →
Oracle (Chainlink) → Frontend (React+[Link]).
• Proxy pattern: Separate logic from storage for upgradeable contracts.
• Security: Reentrancy guard, access control, no spot price oracles, slippage protection,
professional audit.

Topic Likely Exam Question Key Answer Points

Hyperledger Overview 5 marks — What is Linux Foundation, 7 projects,
Hyperledger? Why needed? enterprise needs (5 reasons),
vs public blockchain
Fabric Architecture 10 marks — Explain Fabric 5 components: Peer, Orderer,
components CA, Channel, Chaincode with
roles
Fabric Tx Flow 10 marks — Explain All 7 steps with
transaction lifecycle in Fabric Propose→Endorse→Order→C
ommit
Installing Fabric 5 marks — Steps to install Prerequisites, install script,
Fabric PATH setup, verify
Composer 5 marks — Explain Composer Participants, Assets,
concepts Transactions, ACL + note
deprecation
Error Troubleshooting 5 marks — Common Fabric MVCC_READ_CONFLICT,
errors TLS errors, endorsement
failure, chaincode not found
DApp Definition 5 marks — Define DApp with 6 characteristics + 4 examples
characteristics with categories
Public vs Private 5 marks — Compare public and 14 dimensions comparison,
private blockchain consortium as middle ground
Bitcoin Interaction 5 marks — Interact with Bitcoin JSON-RPC, 6 key commands,
programmatically send workflow
Ethereum Interaction 5 marks — [Link] interaction provider, signer, contract, read
code vs write, event listening
DApp Architecture 10 marks — Explain DApp 5 layers: contracts, indexing,
architecture layers storage, oracle, frontend +
security
Smart Contract Creation 5 marks — Write and deploy a OpenZeppelin ERC20,
token contract constructor, mint, deploy script

Page 25 | SVKM's UPG College | Exam Notes 2024-25

[Link] (IT) Sem IV | Blockchain | Module 4: Hyperledger & Blockchain Application Development

— END OF MODULE 4 NOTES — ALL 4 MODULES COMPLETE —

15 Lectures covered · 15 Major Topics · All Exam Topics Included
Good luck with your [Link] IT Semester IV Blockchain Examination! 🎓

Page 26 | SVKM's UPG College | Exam Notes 2024-25