🏗️ Architecture of Hyperledger Fabric

🔹 Introduction
Hyperledger Fabric is an open-source, permissioned blockchain framework developed
under the Linux Foundation’s Hyperledger Project. Unlike public blockchains (like Bitcoin), it
is designed for enterprise use, offering modular architecture, high scalability, and privacy.

It supports plug-and-play components such as consensus algorithms and

membership services, making it highly adaptable for business needs.

🔹 Key Features of Hyperledger Fabric

●​ Modular and extensible​

●​ Permissioned network​

●​ Private transactions​

●​ Pluggable consensus​

●​ Rich querying capabilities​

●​ Smart contracts (called chaincode)​

🔹 Hyperledger Fabric Architecture Components

1. 🧱 Peers
Peers are nodes that host ledgers and smart contracts (chaincode). There are 3 main types:

●​ Endorsing Peers: Simulate and endorse transactions.​

●​ Committing Peers: Validate and commit blocks to the ledger.​

 ●​ Anchor Peers: Used for inter-organization communication.​

2. 📦 Chaincode (Smart Contracts)

●​ Business logic is written as chaincode.​

●​ Runs in Docker containers.​

●​ Written in Go, JavaScript, or Java.​

●​ Executed during transaction simulation and endorsement.​

3. 📜 Ledger
●​ Hyperledger Fabric uses a dual ledger system:​

1.​ World State: Current value of the ledger (database, often CouchDB).​

2.​ Transaction Log: All changes and historical transactions (immutable).​

4. 🏢 Ordering Service
●​ Also called the Orderer, it provides the consensus mechanism.​

●​ It:​

○​ Collects endorsed transactions​

○​ Orders them​

○​ Packs them into blocks​

○​ Distributes blocks to peers​

Consensus protocols supported:

 ●​ Solo (development only)​

●​ Kafka/Zookeeper (crash fault-tolerant)​

●​ Raft (recommended)​

●​ BFT (in development)​

5. 🧑‍💼 Membership Service Provider (MSP)

●​ Responsible for identity management and access control.​

●​ It issues and validates X.509 certificates using a Certificate Authority (CA).​

●​ Ensures only authorized entities can access the network.​

6. 🧰 Channels
●​ Provide data isolation and confidentiality.​

●​ Each channel acts like a separate blockchain ledger.​

●​ Only members of a channel can access the data and transact on it.​

Example: Company A and B can transact privately without Company C seeing the details.

7. 📤 Transaction Flow
The flow of a transaction in Fabric includes:

1.​ Client sends a proposal to endorsing peers.​

2.​ Peers simulate the proposal and generate endorsements.​

3.​ Endorsements are sent back to the client.​

 4.​ Client sends endorsed transactions to the Ordering Service.​

5.​ Ordered blocks are sent to all committing peers.​

6.​ Peers validate, commit to the ledger, and update the world state.​

🔹 Diagram: Hyperledger Fabric Architecture

🔹 Benefits of Hyperledger Fabric Architecture

Feature Benefit

Modular Design Customizable for different business needs

Permissioned Secure and auditable

Access
 Channel Support Private, confidential transactions

Pluggable Flexibility in choosing suitable consensus

Consensus mechanism

Smart Contracts Enable automation and rule enforcement

✅ Conclusion
Hyperledger Fabric’s architecture is enterprise-grade, offering high performance, privacy,
and security. With components like peers, ordering service, chaincode, and channels, it
provides a robust framework for building next-generation decentralized applications in
finance, healthcare, supply chain, and more.
⚙️ Ethereum Virtual Machine (EVM)
🔹 Introduction
The Ethereum Virtual Machine (EVM) is the decentralized computation engine at the core of
the Ethereum blockchain. It is responsible for executing smart contracts, maintaining the
network's state, and enforcing the rules of the Ethereum protocol across all nodes in the
network.

The EVM is Turing-complete, isolated, and deterministic, allowing decentralized

applications (DApps) to run exactly the same on every node.

🔹 Key Characteristics
●​ Turing-complete: Can compute anything, given enough resources.​

●​ Isolated Environment: Smart contracts cannot directly access system files or the
internet.​

●​ Deterministic: Every node gets the same result when executing the same input.​

●​ Gas Metering: Prevents infinite loops and network abuse.​

🔹 Architecture of the EVM

1. Stack

●​ Temporary data structure (LIFO) with a depth of 1024.​

●​ Stores operands and intermediate results during instruction execution.​

2. Memory

●​ Temporary byte-array memory that is cleared after execution ends.​

 ●​ Used for computations during contract execution.​

3. Storage

●​ Persistent key-value store associated with a smart contract.​

●​ Stored on the blockchain and retains values across transactions.​

4. Program Counter (PC)

●​ Tracks the current position in the EVM bytecode being executed.​

5. Gas Tracker

●​ Tracks how much gas is consumed per operation.​

●​ Execution halts if gas is exhausted.​

🔹 Types of Storage in EVM

Storage Type Description Persistence Accessibility

Stack Temporary execution space ❌ Only during instruction

for operations Temporary execution

Memory Volatile memory for contract ❌ Within one function

execution Temporary execution

Storage Persistent key-value storage ✅ Accessible by all functions

on blockchain Permanent in a contract

Logs/Event Event outputs of contracts ✅ Accessible externally via

Logs (not part of state) Permanent off-chain tools

🔹 Working of the EVM

🧠 Step-by-Step Execution Process:
1.​ Smart Contract Deployment​

○​ Written in Solidity or Vyper​

○​ Compiled into EVM bytecode​

○​ Deployed to Ethereum blockchain with an address​

2.​ Transaction Initiation​

○​ A user or another contract initiates a transaction to interact with the smart

contract.​

3.​ Execution Begins​

○​ The transaction is sent to a node.​

○​ The EVM loads the contract’s bytecode and begins executing it instruction by
instruction.​

4.​ Gas Consumption​

○​ Each opcode (EVM instruction) consumes Gas.​

○​ If gas runs out, execution fails and changes are reverted.​

5.​ State Changes​

○​ Valid transactions that complete execution will modify the state (i.e., contract
storage or balance).​

○​ Invalid ones are discarded.​

6.​ Transaction Finalization​

○​ Valid transactions are included in a block.​

○​ All nodes update their local state accordingly.​

🔹 Gas and Opcode Execution
●​ The EVM uses opcodes like ADD, MUL, PUSH1, etc.​

●​ Each opcode has a gas cost.​

●​ Gas ensures resource optimization and limits abuse (e.g., infinite loops).​

Example Opcod Gas

e Cost

Addition ADD 3

Storage SSTORE ~20,000

Write

SHA3 Hash SHA3 30

🔹 Benefits of the EVM

Benefit Description

Security Sandboxed execution ensures safety

Consensus Deterministic output enables agreement across

nodes

Interoperability Supports many EVM-compatible blockchains

Extensibility Developers can write custom logic using Solidity

🔹 EVM-Compatible Chains
Other blockchains have adopted EVM for smart contract compatibility:

●​ BNB Smart Chain​

●​ Polygon​

●​ Avalanche (C-Chain)​
 ●​ Fantom​

●​ Arbitrum/Optimism (Layer-2)​

These allow Solidity smart contracts to be reused across chains.

🔹 EVM vs Traditional Virtual Machines

Feature Ethereum Virtual Machine (EVM) Java Virtual Machine (JVM)

Platform Ethereum blockchain Desktop/server

Language Solidity, Vyper Java, Kotlin

Persistence Blockchain-based File system

Security Isolated, Gas-limited OS-level control

Determinism Required Not required

✅ Conclusion
The Ethereum Virtual Machine is the engine that powers the Ethereum ecosystem. It
ensures that smart contracts are executed securely and consistently across all nodes, using a
stack-based architecture, gas metering, and various types of memory/storage.

Its design allows Ethereum to be programmable, decentralized, and scalable, forming the
foundation for DeFi, NFTs, and other Web3 innovations.

Solidity book la