Hyperledger Fabric:

Architecture,
Components, and Working
Mechanism
Presenter: Gaurav R. Birajdar
Motivation &
Objectives
Why permissioned blockchains?
Secure, private networks for trusted participants

Enterprise use-cases
Supply chain, finance, healthcare applications
What is Hyperledger Fabric?

Permissioned blockchain Modular architecture Enterprise focus

Open-source, no public Pluggable consensus, membership, Used in supply chain, finance,

cryptocurrency ledger healthcare
Trusted participants only
High privacy and scalability IBM origin, Linux Foundation
project
Key Features & Design Principles

Modular design Permissioned identities Channel privacy

Configurable consensus and X.509 certificates for network Isolated sub-ledgers for data
components access confidentiality

Chaincode smart contracts Unique transaction flow

Written in Go, JavaScript, or Java Execute–order–commit model
Fabric vs Ethereum vs Corda
Ethereum Hyperledger Fabric R3 Corda
• Public, permissionless • Private, permissioned • Permissioned, finance focus
• Native cryptocurrency (Ether) • No built-in token • No global blockchain
• Smart contracts via Solidity • Channels for privacy • Smart contracts on JVM
Evolution and Versions of Fabric
1 2015–2017
OpenBlockchain code, Fabric 1.0 release

2 2019
Fabric v1.4 LTS for production

3 2020 (v2.0)
Chaincode governance and privacy features

4 2020–2024
Incremental improvements, stable 2.5.x line

5 2024
Moved to Linux Foundation Decentralized Trust
Modular Architecture Overview

Highly modular Distinct roles Customizable

Components are pluggable Consensus, membership, Tailored to specific enterprise
and interchangeable ledger, chaincode layers use-cases
Network Components
Peers Ordering Service Membership Clients & SDKs
Service Provider
Endorsing and Sequences transactions Submit proposals, gather
committing nodes into blocks Manages digital endorsements
certificates
Execute chaincode, Supports Raft, Kafka, Ensures identity and Supports Go, Node, Java
maintain ledger SmartBFT access control
Channels & Privacy
Channels Private Data
Private sub-networks
Collections
isolating transactions Off-chain sharing with on-
chain hashes

Policy Control
Per-channel endorsement and access policies
Consensus Layers in
Hyperledger Fabric
Crash-Fault-Tolerant (CFT): Solo, Kafka/ZooKeeper, Raft

Byzantine-Fault-Tolerant (BFT): SmartBFT (v3.0+)

Pluggable ordering service interface enables modular consensus.

SmartBFT Consensus Deep
Dive
Fault Tolerance Channel Capability
Handles up to F faulty BFT and Ed25519 support
nodes; requires 3F+1 in MSP from v3.0
total nodes

Use Cases
Designed for high-security, multi-party environments
Identity & Security with
MSP
MSP Components X.509 Certificates
• cacerts, admincerts, Bind identities to
signcerts, keystore organizations securely

Role-Based Policies
For endorsement, lifecycle, read/write ACLs
Deployment Topologies Overview
Single-Org Network Multi-Org Consortium Hybrid Cloud & On-Prem

Simple test or demo environment Multiple MSPs share ordering Flexible deployment across
service governance environments
Operational
Considerations

Scaling Monitoring Backup &

Horizontal & vertical Use Prometheus,
Restore
options for Grafana, ELK stack Channel artifacts
orderers/peers and state snapshots
MSP Overview
Core Identity X.509 Identities
Abstraction Certificates map users and
Membership Service peers to organizations
Provider in Fabric

Key MSP Directories

• cacerts, signcerts, keystore, admincerts
Identity Lifecycle in Fabric
Registration
Admin registers identity in CA with roles

Enrollment
Request and receive CA-signed certificate

Revocation
Update MSP CRL to expire or revoke certs
Fabric CA Structure & High Availability
Fabric CA Server HA Clusters LDAP Integration

Private root CA issuing X.509 Multiple CA servers, common Optional external user registry
certificates database for reliability support
Access Control & Policy
Framework
Endorsement Lifecycle Policies
Policies Govern chaincode
Specify required MSP installation and approval
signatures, e.g., majority

ACLs
Restrict resource access in configtx.yaml
Advanced IAM: OAuth 2.0 Integration
Hybrid Model Use Case Benefits

Fabric CA combined with OAuth 2.0 Healthcare data sharing with RBAC, • Scalable token-based access
authorization HIPAA compliance control
• Immutable audit trail of token
issuance
Understanding Chaincode
in Hyperledger Fabric
Chaincode: business logic or smart contracts in Fabric networks

Written in Go, JavaScript, or Java using Fabric Contract API

Runs in isolated containers for security against peer process

Manages ledger state by reading/writing key-value pairs

Chaincode Lifecycle
1 Package 2 Install 3 Approve
Bundle chaincode source Distribute package to peers in Each org endorses chaincode
into .tar.gz package target orgs definition

4 Commit 5 Invoke
Consensus finalizes chaincode on the channel Applications submit transactions via installed
chaincode
Chaincode as a Service
(CCaaS)
External Builder & Benefits
Launcher • Decoupled deployment
Run chaincode outside peer via Kubernetes
process (Fabric v2.0+) • Faster startup times
• Independent scaling

Configuration
Set externalBuilders in core.yaml configuration file
Chaincode Development Environments
Go Node.js Java SDK Support

Fast compilation, Large JavaScript Enterprise toolchains Available in Go, Node.js,

minimal dependencies ecosystem, npm using Maven/Gradle and Java for client
modules integration
Sample Chaincode: CreateAsset Function
func (s *SmartContract) CreateAsset(ctx contractapi.TransactionContextInterface, id string,
color string, size int, owner string) error {
asset := Asset{Color: color, Size: size, Owner: owner}
assetJSON, _ := json.Marshal(asset)
return ctx.GetStub().PutState(id, assetJSON)
}
Cross-Channel Invocation & Private Data
Cross-Channel Query Private Data Collections Use Cases

Chaincode reads but cannot write • Defined in JSON configuration Secure sharing like KYC without
across different channels • PutPrivateData and creating new channels
GetPrivateData APIs
Execute–Order–Validate Overview

Validation & Commitment

Ordering Peers verify policies and commit
Endorsement Ordering service batches and orders valid transactions
Clients propose transactions to transactions
endorsing peers
Transaction Endorsement
Phase
1 Proposal Submission 2 Simulation
Peers execute chaincode
Client sends signed simulating state changes
proposal to endorsing
peers

3 Signature
Peers sign RW sets and send endorsements
Ordering Service Phase

Collection Batching
Clients submit endorsed RW Transactions grouped into
sets to ordering service blocks by policies

Consensus
• Raft/Kafka for crash-fault tolerance
• SmartBFT for Byzantine fault tolerance (v3.0+)
Validation & Commitment
Phase
Block Delivery
Peers receive ordered blocks via gossip protocol

Endorsement Check
Verification of endorsement policies

MVCC Conflict Check

Ensuring consistency with read versions

Commit or Invalidate
Update ledger and world state accordingly
Detailed RW Set & Conflict
Handling
Read Set: Keys and versions read during simulation

Write Set: Proposed updates to apply on commit

MVCC Check: Read version must match current world state

version
Conflict Outcome: Version mismatches invalidate but log
transactions
End-to-End Transaction Flow Example
Client Peers (Endorsers) Orderer Peers (Committers)

Submits transaction Simulate and return Batches, orders, Validate then commit or
(e.g., CreateAsset 'A1') signed RW sets broadcasts blocks invalidate transactions
Error Handling & Retry
Strategies
Endorsement Errors
Retry alternate peers or update chaincode

Ordering Timeouts
Client retries or secondary orderer failover

Validation Conflicts
Refresh world state and resubmit proposals

Best Practices
Exponential backoff, idempotent ops, error logging
Network Setup & Tools
Fabric Binaries & Docker & Docker- Fabric-Samples SDKs & CLI
Samples Compose Repos
Go, Node.js, Java SDKs
Download curl -sSL Containerize peers, BYFN and Test-Network and peer CLI
https://bit.ly/2ysbOFE | orderers, CAs for prototyping
bash
Configuration Files
configtx.yaml core.yaml / peer CLI
Defines channel profiles, orgs, policies
ENV
Peer settings like MSP paths, chaincode builder

orderer.yaml Crypto Material

Orderer node parameters such as Kafka, batch MSP folders: cacerts, signcerts, keystore
sizes
Lifecycle Management
Channel Creation
Generate artifacts and create channel

Channel Join
Peers join channel

Chaincode Lifecycle
Package, install, approve, commit, invoke

Channel Updates
Modify policies or add orgs
Performance Modeling
Transaction Pool
Limits HLF 2.5 Analytics
Backlog impact on Validating models against
throughput deployments
Queuing Models Key Metrics
Ordering & endorsement Throughput, latency, block
delay characterization size trade-offs

2 3

1 4
Monitoring & Logging
Prometheus Metrics
Enable peer and orderer exporters

Grafana Dashboards
Use community dashboards (e.g., 10716)

Alerting Rules
Notify on failures and high latency

Log Aggregation
Forward logs to ELK or Splunk via Filebeat
Upgrading Fabric Versions
Upgrade Orderers

Update Channel Config

Upgrade Peers

Upgrade Chaincode

Maintain channel capabilities; use migration tools if needed

Security Best Practices
TLS Everywhere Key Management
Enable for all gRPC endpoints Strong, unique keys per role

NIST-Aligned Controls Threat Mitigation

Follow CSA checklist for Fabric 2.0 Monitor for DoS and consensus attacks; consider
BFT
Future Directions of
Hyperledger Fabric
Private Data &
Privacy
Collection policies and secure gossip protocol

Interoperability
Fabric gateways and cross-chain connectors

Upcoming Features
Version 3.1 and SDK improvements

Research Frontiers
Zero-knowledge proofs, verifiable random functions