BLOCKCHAIN TECHNOLOGY

Comprehensive Study Notes

Module 3 — Permissionless Blockchain (Ethereum)

Module 4 — Permissioned Blockchain (Hyperledger Fabric)

Module 5 — Crypto Assets & Cryptocurrencies

Module 6 — Blockchain Applications & Case Studies

★ Important Points Highlighted ★

Blockchain Technology Study Notes Page 1

 MODULE 3: PERMISSIONLESS
BLOCKCHAIN (ETHEREUM)

■ 1. Ethereum Architecture: EVM & Turing Completeness

Ethereum Virtual Machine (EVM)

• The EVM is a sandboxed, isolated runtime environment inside every Ethereum node — it
executes smart contract bytecode.
• It is stack-based, with a word size of 256-bit to facilitate native cryptographic operations.
• Every node on the network runs the EVM independently, ensuring deterministic execution across
the entire network.
• The EVM abstracts the underlying hardware so contracts run identically on any machine — known
as 'Write Once, Run Anywhere'.

■ EVM is the engine that gives Ethereum its programmability — without it, Ethereum
would just be a ledger like Bitcoin.

Turing Completeness
• A system is Turing Complete if it can simulate any computation that a Turing machine can perform.
• Ethereum/EVM is Turing Complete — it supports loops, conditionals, and arbitrary computation.
• Bitcoin Script is NOT Turing Complete — intentionally limited to prevent infinite loops.

■ Turing Completeness in EVM means smart contracts can implement ANY computable logic,
enabling DeFi, DAOs, NFTs, etc.

■ The GAS mechanism prevents the 'Halting Problem' by limiting computation — every opcode
costs gas, so infinite loops simply run out of gas and revert.

Concept Detail

EVM Role Decentralised world computer executing smart contracts

Execution Model Stack-based, 256-bit word size

Turing Complete? YES — supports loops, conditionals, recursion

Language Solidity / Vyper → compiled to EVM bytecode

Isolation Sandboxed — cannot access host file system / network

Gas Unit of computation; prevents abuse & infinite loops

■ 2. Ethereum 1.0 (PoW) vs Ethereum 2.0 (PoS)

Ethereum 1.0 — Proof of Work (PoW)

• Used Ethash hashing algorithm (ASIC-resistant, memory-hard).
• Miners competed to solve cryptographic puzzles — winner added block and earned block reward +
transaction fees.
• High energy consumption — environmentally criticised.

Blockchain Technology Study Notes Page 2

 • ~15 transactions per second (TPS) — scalability bottleneck.

Ethereum 2.0 — Proof of Stake (PoS) — 'The Merge' (Sep 2022)

• Validators stake 32 ETH as collateral to propose/attest blocks.
• Validator chosen pseudo-randomly — no energy-intensive mining.
• Introduces Beacon Chain (coordination layer) + Shard Chains.
• Energy reduction: ~99.95% less energy than PoW.
• Slashing: validators lose staked ETH for malicious behaviour.

■ 'The Merge' = Ethereum mainnet merged with Beacon Chain PoS system. This did NOT
increase TPS immediately — that comes with sharding.

Aspect ETH 1.0 (PoW) vs ETH 2.0 (PoS)

Consensus PoW (Ethash) → PoS (Casper)

Participation Miners (hardware) → Validators (32 ETH stake)

Energy Very High → ~99.95% lower

TPS ~15 → Up to 100,000 (with sharding)

Security 51% hash-rate attack → 33% stake attack

Finality Probabilistic → Deterministic (Casper)

■ Key ETH 2.0 components: Beacon Chain (PoS coordination), Shard Chains (parallel
processing), eWASM (new VM).

■ 3. Contract Transactions: Structure, Nonce & GAS

Transaction Structure
• Nonce — Sequential counter for sender; prevents replay attacks.
• Gas Price — Amount of Wei sender pays per unit of gas (Gwei).
• Gas Limit — Max gas the sender is willing to consume.
• To — Recipient address (EOA or contract). Empty for contract creation.
• Value — ETH amount to transfer (in Wei).
• Data — Encoded function call + parameters for contract interaction.
• v, r, s — ECDSA signature components proving sender authenticity.

■ Transaction Nonce ≠ PoW Nonce! Tx Nonce = sequential account counter. PoW Nonce
= random number to solve hash puzzle.

Transaction Nonce
• Every account has a nonce starting at 0, incrementing with each tx.
• Ensures transactions are ordered and non-repeatable.
• A tx with nonce=5 will not be processed until nonce=4 is mined.
• Prevents double-spend / replay attacks.

Transaction GAS
• Gas = unit measuring computational effort of an operation.

Blockchain Technology Study Notes Page 3

 • Gas Price = price per gas unit (in Gwei; 1 ETH = 109 Gwei).
• Transaction Fee = Gas Used × Gas Price.
• Gas Limit = max gas authorised; unused gas is refunded.
• If gas runs out mid-execution → tx reverts, gas is NOT refunded.
• EIP-1559: introduced base fee (burned) + priority tip (to validator).

■ Formula: Max Fee = Gas Limit × Max Fee Per Gas. Actual Fee = Gas Used × (Base Fee +
Priority Fee).

■ Simple ETH transfer: 21,000 gas. Smart contract calls: variable (depends on opcodes
executed).

■ 4. Smart Contract Development

What is a Smart Contract?

• Self-executing code stored on the blockchain — runs when predefined conditions are met, without
intermediaries.
• Written in Solidity (most popular), Vyper, or Yul.
• Once deployed, code is immutable (cannot be changed).
• Has its own Ethereum address, balance, and storage.

Solidity Key Concepts

• pragma solidity — specifies compiler version.
• contract — like a class in OOP.
• state variables — stored permanently on blockchain.
• functions — executable units; can be view/pure/payable.
• events — logs emitted during execution, queryable off-chain.
• modifiers — reusable condition checks (e.g., onlyOwner).
• mappings — key-value storage (mapping(address => uint)).

■ Key visibility modifiers: public, private, internal, external. State mutability: view
(read-only), pure (no state), payable (accepts ETH).

Smart Contract Lifecycle

• 1. Write — Code in Solidity/Vyper
• 2. Compile — Convert to EVM bytecode + ABI
• 3. Test — Unit tests using Hardhat/Truffle/Foundry
• 4. Deploy — Send creation tx to network (costs gas)
• 5. Interact — Call functions via ABI

■ ABI (Application Binary Interface) = JSON specification of contract functions and events —
required to interact with deployed contracts.

■ 5. MetaMask & Remix IDE

MetaMask
• Browser extension / mobile wallet for Ethereum and EVM-compatible chains.

Blockchain Technology Study Notes Page 4

 • Manages private keys locally; signs transactions.
• Acts as an Ethereum provider for dApps via injected web3/[Link].
• Supports multiple networks: Mainnet, Testnets (Sepolia, Goerli), custom RPC networks.
• Seed Phrase (12/24 words) — master key; NEVER share it.

Remix IDE ([Link])

• Browser-based Integrated Development Environment for Solidity.
• Modules: File Explorer, Solidity Compiler, Deploy & Run, Plugin Manager.
• Supports compilation of .sol files with selectable compiler versions.
• Deploy to: JavaScript VM (local in-browser), Injected Provider (MetaMask), Web3 Provider
(custom node).
• ABI and Bytecode visible after successful compilation.

■ Deployment workflow: Write .sol → Compile (check warnings/errors) → Select

Environment → Deploy → Copy Contract Address → Interact via Remix UI.

■ Use 'Injected Provider - MetaMask' in Remix to deploy to real testnets. Get free testnet
ETH from faucets (e.g., [Link]).

Blockchain Technology Study Notes Page 5

 MODULE 4: PERMISSIONED BLOCKCHAIN
(HYPERLEDGER FABRIC)

■ 1. Hyperledger Fabric Architecture

Overview
• Hyperledger Fabric is an enterprise-grade, permissioned DLT framework hosted by the Linux
Foundation.
• Unlike public chains, participants are known and authenticated via MSP (Membership Service
Provider).
• Supports pluggable consensus, private data (channels), and chaincode (smart contracts).

Core Components
• Peers — Nodes that maintain the ledger and execute chaincode. Types: Endorsing Peer,
Committing Peer, Anchor Peer, Leader Peer.
• Orderer (Ordering Service) — Orders transactions into blocks and distributes to peers. Does NOT
execute chaincode.
• CA (Certificate Authority) — Issues X.509 certificates; implements MSP.
• Chaincode — Smart contracts in Fabric (Go, [Link], Java).
• Ledger — Composed of World State (current KV store, CouchDB/LevelDB) + Blockchain
(transaction log).
• Channel — Private sub-network for confidential transactions between specific members.
• MSP (Membership Service Provider) — Manages identities; defines who can participate.

■ Fabric separates Execution (peers), Ordering (orderers), and Validation — this is called
'Execute-Order-Validate' architecture.

Transaction Flow (Execute-Order-Validate)

• 1. Client proposes transaction to endorsing peers.
• 2. Endorsing peers simulate chaincode, return read/write sets + signature.
• 3. Client collects sufficient endorsements (per endorsement policy).
• 4. Client submits endorsed transaction to Ordering Service.
• 5. Orderer orders transactions into blocks, broadcasts to peers.
• 6. Committing peers validate endorsements + MVCC check, commit to ledger.

■ Key difference from Ethereum: In Fabric, chaincode is executed BEFORE ordering (simulate
first). In Ethereum, execution happens AFTER ordering.

■ 2. Consensus: Solo, Kafka, RAFT

Consensus in Hyperledger Fabric

• Fabric consensus = full-cycle process: endorsement policy + ordering + validation. Here we focus on
Ordering Service consensus.

Blockchain Technology Study Notes Page 6

 Mechanism Description

Solo Single orderer node. Used for DEVELOPMENT/TESTING only. No fault

tolerance — single point of failure. NOT for production.

Kafka Uses Apache Kafka + ZooKeeper cluster. Crash fault tolerant (CFT).
Handles high throughput. Deprecated in Fabric v2.x (complex ops).

RAFT Etcd Raft-based CFT ordering. Leader-follower model. Leader elected;

followers replicate. RECOMMENDED for production in Fabric v2+. Simpler
than Kafka; supports multiple ordering orgs.

■ RAFT is the current recommended ordering mechanism for Hyperledger Fabric

production deployments (since Fabric v2.0). Solo is ONLY for dev/testing.

RAFT Details
• Leader Election: If leader fails, followers elect a new leader.
• Log Replication: Leader receives entries, replicates to followers.
• Majority Quorum: Needs (N/2)+1 nodes to agree.
• CFT (Crash Fault Tolerant) — NOT Byzantine Fault Tolerant.

■ Fabric currently does NOT support BFT consensus natively (all mechanisms are CFT).
BFT support is being researched.

■ 3. Network Components

Component Role / Description

Organizations Independent entities (companies/institutions) in the network. Each has its

own CA and MSP.

Peers Nodes that host ledger copies and run chaincode. Endorsing peers simulate
transactions; committing peers validate and commit.

Orderers Form the ordering service. Receive endorsed transactions, order them,
create blocks, distribute to peers.

Clients Applications (SDK-based) that create and submit proposals. Use Fabric
SDK ([Link] / Go / Java).

CA / TLS CA Issues enrollment certificates (ECerts) and TLS certificates. Each org has its
own CA. Fabric CA is a default implementation.

Anchor Peer Gateway peer for cross-org gossip communication. At least one per org per
channel.

Gossip Protocol Peer-to-peer data dissemination for block distribution and peer discovery
within a channel.

World State Current key-value snapshot of ledger. Stored in LevelDB (simple) or

CouchDB (complex JSON queries).

■ MSP (Membership Service Provider) is central to Fabric — it maps certificates to org roles
(Admin, Member, Peer, Orderer).

■ 4. Implementation of Channels

Blockchain Technology Study Notes Page 7

 What is a Channel?
• A channel is a private communication subnet between specific network members.
• Each channel has its own ledger, chaincode, and policies.
• Transactions on one channel are invisible to members of other channels.
• The system channel (managed by orderers) bootstraps the network.

Channel Creation Steps

• 1. Define channel configuration in [Link].
• 2. Generate channel genesis block using configtxgen tool.
• 3. Submit channel creation transaction to ordering service.
• 4. Peers join the channel using the genesis block.
• 5. Install and instantiate chaincode on the channel.

■ One network can have MULTIPLE channels. Each channel = separate blockchain. Peers
can belong to multiple channels simultaneously.

Channel Policies
• Endorsement Policy: which orgs must endorse a transaction.
• Lifecycle Policy: controls chaincode deployment approvals.
• Access Control Lists (ACLs): fine-grained resource access.

■ Private Data Collections (PDC) provide even finer privacy than channels — share
hashed data on-chain but actual data only to authorised peers.

Blockchain Technology Study Notes Page 8

 MODULE 5: CRYPTO ASSETS &
CRYPTOCURRENCIES

■ 1. ERC-20 (Fungible) & ERC-721 (Non-Fungible) Tokens

ERC-20 — Fungible Token Standard

• ERC = Ethereum Request for Comment. ERC-20 is the standard interface for fungible tokens.
• Fungible: every token is identical and interchangeable (like currency — 1 ETH = 1 ETH).
• Mandatory functions: totalSupply(), balanceOf(), transfer(), transferFrom(), approve(),
allowance().
• Mandatory events: Transfer, Approval.
• Used for: stablecoins (USDT, USDC), utility tokens, governance tokens.

■ ERC-20 approve() + transferFrom() pattern enables DEXs and DeFi protocols to move tokens
on behalf of users (delegated transfers).

ERC-721 — Non-Fungible Token Standard

• Non-Fungible: each token has a unique tokenId and is NOT interchangeable.
• Functions: ownerOf(tokenId), safeTransferFrom(), tokenURI().
• tokenURI: returns metadata URL (JSON with name, image, attributes).
• Used for: digital art, collectibles, gaming items, real estate deeds.

Aspect ERC-20 vs ERC-721

Fungibility ERC-20: Fungible (identical) | ERC-721: Non-Fungible (unique)

Token ID ERC-20: Not applicable | ERC-721: Each token has unique ID

Interface ERC-20: IERC20 | ERC-721: IERC721

Use Case ERC-20: Currencies, voting tokens | ERC-721: NFTs, digital art, deeds

Transfer ERC-20: transfer(to, amount) | ERC-721: safeTransferFrom(from, to,

tokenId)

Metadata ERC-20: None (inherent) | ERC-721: tokenURI(tokenId) returns JSON

■ ERC-1155 is a MULTI-TOKEN standard supporting both fungible and non-fungible

tokens in a single contract — used heavily in gaming.

■ 2. NFTs (Non-Fungible Tokens)

What is an NFT?
• A unique, indivisible digital asset whose ownership is recorded on a blockchain.
• The NFT itself = token on chain. Actual content (image/video) typically stored on IPFS or Arweave;
tokenURI points to it.
• NFTs prove provenance, authenticity, and ownership without centralised authority.

NFT Lifecycle

Blockchain Technology Study Notes Page 9

 • 1. Mint: Create NFT (deploy ERC-721 contract, assign tokenId to creator).
• 2. List: Put on marketplace (OpenSea, Rarible, Blur).
• 3. Buy/Sell: Transfer ownership on-chain.
• 4. Royalties: Original creator earns % on secondary sales (ERC-2981).

■ NFT Metadata Standard: {name, description, image, attributes[]}. Best practice: store
metadata on IPFS for decentralisation, not centralised servers.

Use Cases
• Digital Art (CryptoPunks, Bored Apes), Gaming (Axie Infinity), Music rights, Domain names (ENS),
Event tickets, Identity documents.

■ 3. ICO — Initial Coin Offering

• An ICO is a fundraising method where a project issues new tokens to investors in exchange for
established cryptocurrencies (BTC/ETH).
• Analogy to IPO (Initial Public Offering) but for crypto tokens.
• Process: Whitepaper → Token Sale → Distribution → Listing on exchange.
• Tokens sold may be utility tokens (access to platform) or investment tokens.

■ ICOs are largely UNREGULATED — high risk of scams and 'rug pulls'. Many
jurisdictions (US SEC) classify ICO tokens as securities, requiring compliance.

Term Meaning

Whitepaper Technical document outlining project vision, tokenomics, roadmap

Token Sale Phases Pre-sale (private, discounted) → Public Sale → Post-sale

Soft Cap Minimum fundraising target; refund if not met

Hard Cap Maximum fundraising limit

Vesting Token lock-up period for founders/team to prevent immediate dump

KYC/AML Know Your Customer / Anti-Money Laundering checks for investors

■ 4. STO — Security Token Offering

• An STO offers security tokens — blockchain-based representations of real-world financial

securities (equity, debt, real estate).
• STOs are fully regulated — must comply with securities laws (e.g., SEC Reg D, Reg A+, Reg S in
the US).
• Provides investors with legal ownership rights: dividends, profit sharing, voting rights.

Aspect ICO vs STO

Regulation ICO: Unregulated / grey area | STO: Fully regulated (securities law)

Token Type ICO: Utility token | STO: Security token (equity/debt/asset)

Investor Rights ICO: Limited | STO: Legal ownership, dividends, voting

KYC/AML ICO: Optional | STO: Mandatory

Risk ICO: High (scam risk) | STO: Lower (legal framework)

Blockchain Technology Study Notes Page 10

 Aspect ICO vs STO

Liquidity ICO: High (exchange listed) | STO: Lower (limited exchanges)

■ STOs combine blockchain efficiency with regulatory compliance — seen as the 'next evolution'
of ICOs for institutional adoption.

■ 5. Comparison of Different Cryptocurrencies

Cryptocurrency Key Characteristics

Bitcoin (BTC) First crypto; store of value ('digital gold'). PoW (SHA-256). 21M supply cap.
~7 TPS. 10-min blocks. Script (not Turing complete).

Ethereum (ETH) Smart contract platform. PoS (post-Merge). No hard cap. ~15-30 TPS (L1).
EVM, Turing complete. Solidity.

Binance Coin (BNB) Native token of BNB Chain. PoSA (Proof of Staked Authority). ~160 TPS.
EVM compatible. Used for fees, staking, BNB ecosystem.

Solana (SOL) High-performance chain. PoH + PoS consensus. ~65,000 TPS. Low fees.
Rust/C smart contracts. Known for speed but had outages.

Ripple (XRP) Designed for cross-border payments. RPCA (Ripple Protocol Consensus).
~1,500 TPS. 3-5 sec finality. Centralisation concerns.

Litecoin (LTC) Bitcoin fork. PoW (Scrypt). Faster blocks (2.5 min). 84M supply cap. Often
called 'silver to Bitcoin's gold'.

Cardano (ADA) Research-driven PoS (Ouroboros). Smart contracts via Plutus.

Peer-reviewed academic approach. Slower development pace.

Polkadot (DOT) Multi-chain interoperability. Relay chain + parachains. Nominated PoS.

Cross-chain message passing (XCM).

■ For exams: Know BTC (PoW, 21M cap, 7 TPS), ETH (PoS post-merge, smart contracts,
EVM), and at least 2 others with their consensus mechanisms.

Blockchain Technology Study Notes Page 11

 MODULE 6: BLOCKCHAIN APPLICATIONS
& CASE STUDIES

■ 1. Blockchain in IoT

Challenges in Traditional IoT

• Centralised architecture — single point of failure.
• Security vulnerabilities in device communication.
• Data integrity issues — tampered sensor readings.
• Scalability — billions of devices, massive data volume.

How Blockchain Solves IoT Problems

• Decentralisation: No central server; P2P device communication.
• Immutable Audit Trail: Every sensor reading recorded on-chain.
• Smart Contracts: Automate actions based on IoT triggers (e.g., auto-pay when shipment arrives).
• Identity Management: Each device has a blockchain identity.
• Data Marketplace: Devices monetise data via micropayments (IOTA).

■ IOTA Tangle — DAG-based (not blockchain) DLT designed specifically for IoT. Feeless
micropayments. Used in smart city projects.

Use Cases
• Supply chain tracking (temperature sensors + blockchain = cold chain integrity).
• Smart energy grids — P2P energy trading.
• Connected vehicles — secure V2V and V2I communication.
• Smart home automation with verifiable device logs.

■ 2. Blockchain in Cybersecurity

How Blockchain Enhances Security

• Decentralised PKI: Replace centralised CAs — store public keys on blockchain, resistant to CA
compromise.
• Data Integrity: Hash of data stored on-chain — any tampering is immediately detectable.
• DDoS Mitigation: Decentralised DNS (e.g., Handshake, ENS) eliminates single DNS attack target.
• Identity & Access Management (IAM): Self-Sovereign Identity (SSI) — users control their
credentials.
• Audit Trails: Immutable logs of system events — forensic value.
• Secure Messaging: Encrypted, verifiable communication channels.

■ Blockchain does NOT prevent all attacks. Private key theft, smart contract bugs
(reentrancy, overflow), and 51% attacks remain significant threats.

Known Blockchain Security Attacks

• 51% Attack: Attacker controls majority of network hash rate/stake.
• Sybil Attack: Creating many fake identities to gain influence.

Blockchain Technology Study Notes Page 12

 • Reentrancy Attack: Exploit smart contract (The DAO hack, $60M).
• Eclipse Attack: Isolate a node by controlling its peer connections.

■ Mitigation: Use audited smart contract libraries (OpenZeppelin), formal verification,

multi-sig wallets, and regular security audits.

■ 3. Blockchain in Healthcare

Problems in Traditional Healthcare Data Management

• Fragmented patient records across hospitals.
• Lack of interoperability between EHR systems.
• Data breaches — healthcare is the #1 targeted sector.
• Drug counterfeiting in pharmaceutical supply chains.

Blockchain Solutions in Healthcare

• EHR (Electronic Health Records): Patient-controlled, portable, interoperable health records.
Patient grants access via private key.
• Drug Supply Chain: Track pharmaceuticals from manufacturer to patient (e.g., MediLedger
network). Prevents counterfeiting.
• Clinical Trials: Immutable protocol registration prevents result manipulation / data fraud.
• Medical Credential Verification: Verify doctor licenses and qualifications on-chain.
• Insurance Claims: Smart contracts automate claim verification and payment.

■ MedRec (MIT) — blockchain-based EHR system. Patients own their data; providers get
access tokens. Built on Ethereum.

■ HIPAA (US) compliance is critical — blockchain data is immutable, so sensitive data should be
stored off-chain with only hashes on-chain.

■ 4. Blockchain in Education

Current Challenges
• Credential fraud — fake degrees and certificates.
• Manual, slow verification processes for employers.
• Data silos — student records not portable across institutions.

Blockchain Solutions in Education

• Digital Certificates/Diplomas: Issue tamper-proof credentials on blockchain (MIT — Blockcerts
standard).
• Instant Verification: Employers verify credentials in seconds by querying the blockchain.
• Lifelong Learning Passport: Portable, cumulative record of all courses, skills, and certifications.
• Micro-credentials: Granular skill badges (similar to NFTs) for individual competencies.
• Academic Research: Timestamp and notarise research publications to establish priority.
• Student Payments: Automate scholarships via smart contracts (release funds when milestones
met).

■ Blockcerts (MIT + Learning Machine) — open standard for issuing, displaying, and verifying
blockchain-based educational credentials.

Blockchain Technology Study Notes Page 13

 ■ Use Case Example: University issues degree as ERC-721 NFT. Graduate owns it in
wallet. Employer scans QR code to verify on-chain. No registrar needed.

■ 5. Other Applications of Blockchain

Sector Blockchain Application & Examples

Supply Chain End-to-end traceability of goods. IBM Food Trust (Walmart, Nestle).
Reduces food fraud, recalls targeted precisely.

Finance & DeFi Decentralised Finance: lending (Aave), DEX (Uniswap), stablecoins.
Cross-border remittance (Ripple, Stellar). Trade finance.

Voting Tamper-proof e-voting. Voatz (US pilot). Voter anonymity via

zero-knowledge proofs. Auditability without revealing identity.

Real Estate Tokenised property ownership. Smart contract-based escrow. Faster title
transfer. Fractional ownership of properties.

Government Land registry (Georgia, Sweden pilots). Identity management. Transparent

public spending. e-Governance.

Legal Smart legal contracts. IP rights management. Notarisation of documents.

Automated royalty distribution.

Energy P2P energy trading (Power Ledger). Carbon credit tracking. Renewable
energy certificates on blockchain.

Insurance Parametric insurance via smart contracts (auto-payout on trigger event).

Fraud reduction. Faster claims processing.

■ For exam: be ready to explain at least 3 sectors in detail with real-world examples and
explain HOW blockchain specifically solves the problem (not just 'blockchain makes it
better').

Blockchain Technology Study Notes Page 14

 QUICK REVISION CHEAT SHEET
Key Term One-Line Explanation

EVM Ethereum's sandboxed runtime; executes smart contract bytecode

Turing Complete Can compute anything; EVM uses GAS to prevent infinite loops

The Merge Sep 2022 — ETH switched from PoW to PoS; 99.95% energy reduction

Gas Computation unit; Fee = Gas Used × (Base Fee + Priority Tip)

Nonce (Tx) Sequential tx counter; prevents replay attacks

Smart Contract Self-executing code on blockchain; immutable once deployed

Remix + MetaMask Browser IDE + wallet for writing/deploying Solidity contracts

Hyperledger Fabric Enterprise permissioned blockchain; Execute-Order-Validate

RAFT Recommended production ordering in Fabric v2+; CFT, leader-based

Channel Private subnet in Fabric with own ledger; members have privacy

ERC-20 Fungible token standard; identical tokens (currency use case)

ERC-721 NFT standard; unique tokenId per token

ICO vs STO ICO = unregulated utility token; STO = regulated security token

NFT Unique digital asset; ownership on-chain; content on IPFS

Blockchain+IoT Immutable sensor logs, smart contract automation, device identity

Blockchain+Health EHR portability, drug supply chain, clinical trial integrity

Blockchain+Edu Tamper-proof credentials, instant verification (Blockcerts)

Blockchain+Cyber Decentralised PKI, immutable audit logs, SSI identity

■ EXAM TIP: Always explain the PROBLEM blockchain solves, the MECHANISM it uses
(consensus, smart contracts, immutability, etc.), and a REAL-WORLD EXAMPLE or
project for full marks.

■ All the best for your exams! Remember: Understand concepts deeply — don't just
memorise.

Blockchain Technology Study Notes Page 15