2.1 Hyperledger Fabric Architecture

Modular Architecture Overview

Hyperledger Fabric has been specifically architected to have a modular architecture. Whether it is consensus, identity management protocols, key management protocols, or cryptographic libraries, the platform has been designed at its core to be configured to meet the diversity of enterprise use case requirements.

The modular architecture of Hyperledger Fabric separates the transaction processing workflow into three distinct phases:

1. Proposal and Endorsement: Clients propose transactions to endorsing peers who simulate and endorse them
2. Ordering: Endorsed transactions are ordered and packaged into blocks
3. Validation and Commitment: Peers validate transactions and commit them to the ledger

This separation allows for greater flexibility, scalability, and performance compared to traditional blockchain architectures.

Key benefits of Fabric's modular architecture include:

• Flexibility: Components can be swapped in and out based on specific requirements
• Scalability: Different components can be scaled independently
• Maintainability: Components can be updated or replaced without affecting the entire system
• Customization: Organizations can tailor the blockchain to their specific needs
• Innovation: New components can be developed and integrated as technology evolves

Execute-Order-Validate Paradigm

Hyperledger Fabric introduces a new architecture for transactions that we call execute-order-validate. It addresses the resiliency, flexibility, scalability, performance, and confidentiality challenges faced by the order-execute model used in other blockchain platforms.

Traditional Order-Execute Model

In traditional blockchain platforms like Bitcoin and Ethereum:

1. Order: Transactions are first ordered (through mining or other consensus mechanisms)
2. Execute: Then all transactions are executed sequentially on all nodes

This model has several limitations: - Sequential execution limits performance - All transactions must be deterministic - All smart contracts must be written in domain-specific languages - The executed code is visible to all participants, limiting confidentiality

Fabric's Execute-Order-Validate Model

Hyperledger Fabric's execute-order-validate architecture separates the transaction flow into three steps:

1. Execute: A transaction is executed and its correctness is verified by endorsing peers
2. Simulation of transaction against current state
3. No actual updates to the ledger at this stage

4. Generation of read-write sets

5. Order: Transactions are ordered via a (pluggable) consensus protocol

6. Ordering service batches endorsed transactions into blocks
7. No execution of transactions, just ordering

8. Delivery of ordered blocks to peers

9. Validate: Transactions are validated against an application-specific endorsement policy before being committed to the ledger

10. Verification of endorsement policy satisfaction
11. Check for conflicting transactions (read-write set validation)
12. Ledger update with valid transactions

This design departs radically from the order-execute paradigm in that Fabric executes transactions before reaching final agreement on their order.

Benefits of the execute-order-validate approach: - Parallel execution: Transactions can be executed in parallel, improving performance - Non-deterministic execution: Transactions can include non-deterministic code - Endorsement policies: Flexible policies for transaction validation - Privacy and confidentiality: Execution limited to endorsing peers - Elimination of non-determinism issues: Consensus is reached on transaction results, not just transaction data

Privacy and Confidentiality Features

Privacy and confidentiality are critical requirements for many enterprise blockchain applications. Hyperledger Fabric provides several mechanisms to address these needs:

Channels

Channels are private "subnets" of communication between two or more specific network members. A channel is essentially a separate ledger of transactions visible only to a specific group of participants.

Key aspects of channels: - Each channel has a separate ledger - A peer can participate in multiple channels - Channel membership is managed through policies - Transactions on one channel are completely isolated from other channels - Organizations can maintain privacy while still benefiting from the same network infrastructure

Use cases for channels: - Bilateral trading relationships - Multi-lateral business networks - Regulatory compliance separation - Competing business interests on the same network

Private Data Collections

Private Data Collections provide a way to keep certain data confidential between a subset of organizations on a channel, while still maintaining the integrity of the overall ledger.

How Private Data Collections work: 1. Private data is sent peer-to-peer only to organizations authorized to see it 2. Private data is stored in a private database on the peers of authorized organizations 3. A hash of the private data is endorsed, ordered, and written to the ledgers of all channel peers 4. The hash serves as evidence of the transaction and can be used for audit purposes

Components of a Private Data Collection: - Collection Definition: Defines which organizations can persist the data - PDC Policy: Defines which peers can disseminate the data - Block-to-Live Configuration: Specifies when data should be purged from private databases

Use cases for Private Data Collections: - Price negotiations between specific parties - Personal identity information - Confidential business agreements - Sensitive supply chain data

Zero-Knowledge Proofs

Hyperledger Fabric also supports zero-knowledge proofs, which are cryptographic methods that can prove possession of certain information without revealing the information itself.

Applications of zero-knowledge proofs in Fabric: - Proving minimum account balance without revealing the actual balance - Verifying identity attributes without exposing the attributes - Demonstrating compliance without revealing confidential data - Validating transaction conditions without exposing business logic

Pluggable Consensus Mechanisms

One of the most important of Hyperledger Fabric's differentiators is its support for pluggable consensus protocols that enable the platform to be more effectively customized to fit particular use cases and trust models.

Consensus in Blockchain

Consensus in blockchain is the process of reaching agreement on the next set of transactions to be added to the ledger. Different consensus mechanisms make different tradeoffs in terms of performance, finality, fault tolerance, and trust model.

Fabric's Approach to Consensus

In Hyperledger Fabric, consensus is not just about transaction ordering but encompasses the entire transaction flow from proposal and endorsement to ordering, validation, and commitment.

The ordering service is the pluggable component that implements the consensus mechanism. It does two things: 1. Establishes the order of transactions 2. Broadcasts blocks to peers

Supported Consensus Mechanisms

Hyperledger Fabric supports several consensus mechanisms:

Raft (Crash Fault Tolerant) - Based on the Raft protocol (implementation of CFT) - Leader-follower model where a leader is elected and replicates log entries to followers - Can tolerate crash faults (non-malicious failures) up to (n-1)/2 nodes - Provides finality (no forks) - Highly performant and easy to understand - Default consensus mechanism since Fabric v2.0

Kafka (Crash Fault Tolerant) - Uses Apache Kafka and ZooKeeper - Provides a crash fault-tolerant ordering service - Centralized design with good performance - Being phased out in favor of Raft

Byzantine Fault Tolerant (BFT) Implementations - Can tolerate malicious behavior from nodes - Suitable for environments with lower trust - Various implementations are being developed for Fabric - Higher overhead compared to CFT solutions

Choosing a Consensus Mechanism

Factors to consider when selecting a consensus mechanism: - Trust Model: Level of trust between participants - Performance Requirements: Throughput and latency needs - Fault Tolerance: Types of faults that need to be tolerated - Finality: Need for immediate or eventual transaction finality - Operational Complexity: Resources and expertise available

The ability to choose a consensus mechanism based on specific requirements is a powerful feature of Hyperledger Fabric, allowing networks to optimize for their particular use case and trust model.