Module 2: Core Components of Hyperledger Fabric

2.2 Core Components

Hyperledger Fabric is comprised of several modular components that work together to form a complete blockchain platform. Understanding these components is essential for designing, deploying, and maintaining Fabric networks.

Peers and Their Roles

Peers are a fundamental element of the Fabric network. They host ledgers and smart contracts (chaincode) and serve as the entry point for applications to interact with the blockchain.

Types of Peers

  1. Endorsing Peers
  2. Execute proposed transactions
  3. Verify transaction validity
  4. Produce endorsement signatures

  5. Must have the relevant chaincode installed

  6. Committing Peers

  7. Validate transaction results
  8. Maintain a copy of the ledger
  9. Commit valid transactions to the ledger

  10. All peers in the network are committing peers

  11. Anchor Peers

  12. Enable cross-organization communication
  13. Advertised to other organizations
  14. Allow peers from different organizations to discover each other
  15. At least one anchor peer per organization is recommended

Peer Functions

Peers perform several critical functions:

  • Ledger Hosting: Maintain a copy of the blockchain ledger
  • Chaincode Execution: Run smart contracts to execute transactions
  • Endorsement: Simulate and endorse transaction proposals
  • Validation: Verify transactions before committing to the ledger
  • Event Emission: Generate events for client applications
  • Discovery Service: Provide information about network resources

Peer Architecture

Each peer consists of several components:

  • Endorser: Simulates transaction execution
  • Committer: Validates and commits transactions
  • Ledger Provider: Manages access to the ledger
  • Gossip Component: Disseminates data across the network
  • Chaincode Support: Manages chaincode lifecycle and execution

Ordering Service

The ordering service is a key component that provides a shared communication channel to clients and peers, offering a broadcast service for messages containing transactions.

Functions of the Ordering Service

  • Consensus on Transaction Order: Establishes agreement on the order of transactions
  • Block Creation: Batches transactions into blocks
  • Block Distribution: Delivers blocks to peers
  • Channel Management: Maintains configuration for different channels

Ordering Service Implementations

  1. Solo
  2. Single ordering node
  3. Used for development and testing
  4. No fault tolerance

  5. Not suitable for production

  6. Raft

  7. Crash Fault Tolerant (CFT) implementation
  8. Leader-based consensus
  9. Multiple ordering nodes
  10. Production-ready with fault tolerance

  11. Default since Fabric v2.0

  12. Kafka

  13. Uses Apache Kafka and ZooKeeper
  14. Crash Fault Tolerant (CFT)
  15. Being phased out in favor of Raft

Ordering Service Nodes (OSNs)

Ordering Service Nodes are the individual nodes that collectively form the ordering service. They:

  • Receive endorsed transactions from clients
  • Agree on the order of transactions
  • Create blocks of transactions
  • Broadcast blocks to peers
  • Maintain channel configurations

Certificate Authority (CA)

The Certificate Authority is responsible for issuing and managing the certificates used to identify components and users in the Hyperledger Fabric network.

Hyperledger Fabric CA

Fabric provides a built-in CA server that can be used to generate certificates and keys for components and users. Key features include:

  • Identity Registration: Register identities with the CA
  • Certificate Issuance: Issue X.509 certificates
  • Certificate Renewal and Revocation: Manage the certificate lifecycle
  • User Attribute Management: Include attributes in certificates
  • Affiliation Management: Group users by affiliation

CA Hierarchy

A typical CA hierarchy in Fabric includes:

  • Root CA: The top-level CA that issues certificates to intermediate CAs
  • Intermediate CAs: Issue certificates to components and users
  • Organization CAs: Managed by individual organizations
  • TLS CAs: Issue certificates specifically for TLS communication

Certificate Types

Fabric uses different types of certificates:

  • Enrollment Certificates: Identify components and users
  • Transaction Certificates: Used for transaction authentication
  • TLS Certificates: Secure communication between components

Membership Service Provider (MSP)

The Membership Service Provider (MSP) is a component that defines the rules that govern valid identities for an organization. It translates cryptographic identities into roles and permissions within the Fabric network.

MSP Functions

  • Identity Validation: Verify that identities are valid
  • Role Assignment: Assign roles to identities (admin, member, client, peer)
  • Signature Verification: Validate signatures on transactions and blocks
  • Certificate Path Validation: Ensure certificates are issued by trusted CAs

MSP Types

  1. Local MSP
  2. Defined for a specific node (peer, orderer)
  3. Defines the permissions for that node

  4. Stored in the filesystem of the node

  5. Channel MSP

  6. Defined at the channel level
  7. Shared by all members of the channel
  8. Stored in the channel configuration

MSP Structure

An MSP configuration typically includes:

  • Root CAs: Certificates of trusted root CAs
  • Intermediate CAs: Certificates of trusted intermediate CAs
  • Organizational Units (OUs): Subdivisions within an organization
  • Administrators: Identities that can administer the MSP
  • Revocation List: Certificates that have been revoked
  • Node Identity: The identity of the node (for local MSP)
  • TLS Root CAs: CAs trusted for TLS communication

Channels

Channels are private "subnets" of communication between specific network members. Each channel has its own independent ledger, accessible only to channel members.

Channel Features

  • Data Isolation: Transactions on one channel are invisible to other channels
  • Governance: Each channel can have its own governance and policies
  • Membership: Organizations can participate in multiple channels
  • Configuration: Channel configuration is stored on the ledger itself

Channel Creation and Management

  1. Channel Creation
  2. Generate channel configuration transaction
  3. Submit to ordering service

  4. First members join the channel

  5. Channel Joining

  6. Peers receive the genesis block
  7. Peers initialize the channel ledger

  8. Peers join the channel gossip network

  9. Channel Configuration Updates

  10. Propose configuration changes
  11. Collect required signatures
  12. Submit update to ordering service

Channel Policies

Channels use policies to control various aspects of operation:

  • Admins Policy: Who can modify the channel configuration
  • Writers Policy: Who can write to the ledger
  • Readers Policy: Who can read from the ledger
  • Endorsement Policies: Requirements for transaction endorsement
  • Lifecycle Endorsement Policy: Requirements for chaincode lifecycle operations

Ledger

The ledger is the record of all transactions for a channel. Each peer maintains a copy of the ledger for each channel it belongs to.

Ledger Components

  1. World State
  2. Current state of the ledger
  3. Key-value store
  4. Implemented as a database (LevelDB or CouchDB)

  5. Provides efficient read access to current values

  6. Transaction Log

  7. Complete history of all transactions
  8. Immutable record of all state changes
  9. Implemented as a file-based append-only log
  10. Allows for historical queries and audit

Ledger Features

  • Immutability: Once recorded, transactions cannot be altered
  • Tamper-Evident: Any attempt to modify the ledger is detectable
  • Queryable: Both current state and historical data can be queried
  • Shared: All channel members have the same view of the ledger

State Database Options

  1. LevelDB
  2. Default state database
  3. Embedded in the peer process
  4. Key-value storage
  5. Simple queries based on keys

  6. Efficient and lightweight

  7. CouchDB

  8. Optional alternative state database
  9. Document-oriented database
  10. JSON document storage
  11. Rich queries using CouchDB query language
  12. Indexes for improved query performance

Smart Contracts and Chaincode

Smart contracts in Hyperledger Fabric are implemented as chaincode, which is software that defines assets and the transaction instructions for modifying those assets.

Chaincode Characteristics

  • Deterministic Execution: Same input always produces same output
  • Isolated Execution: Runs in a secure container environment
  • Multiple Language Support: Go, Node.js, Java
  • Access Control: Governed by endorsement policies
  • State Management: Interacts with the ledger state

Chaincode Lifecycle

  1. Package: Create a chaincode package
  2. Install: Install on peers
  3. Approve: Organizations approve the chaincode definition
  4. Commit: Commit the chaincode definition to the channel
  5. Invoke: Execute transactions using the chaincode

System Chaincode

Fabric includes several system chaincodes that provide core functionality:

  • Lifecycle System Chaincode (LSCC): Manages chaincode lifecycle
  • Configuration System Chaincode (CSCC): Manages channel configuration
  • Query System Chaincode (QSCC): Provides ledger query functions
  • Endorsement System Chaincode (ESCC): Handles transaction endorsement
  • Validation System Chaincode (VSCC): Validates transaction endorsements

Understanding these core components and their interactions is essential for designing, implementing, and maintaining Hyperledger Fabric networks. Each component plays a specific role in the overall architecture, contributing to the platform's flexibility, security, and performance.

Back to Course Home