Source-linked AI summary
Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains
Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko Vukolić, Sharon Weed Cocco, Jason Yellick
TL;DR
Existing blockchain designs must support concurrent, dynamically deployed, potentially untrusted applications while accommodating flexible trust assumptions. Fabric introduces a modular architecture separating transaction execution from consensus, and reports over 3560 transactions per second of average end-to-end spend throughput in a 32-vCPU configuration.
Problem
Blockchains require new designs because many concurrent applications may be dynamically deployed by anyone and may contain untrusted or malicious code.
Method
Fabric uses a modular architecture that separates transaction execution from consensus and combines policy-based endorsement with validation for permissioned blockchains.
Results
Over 3560 transactions per second of average end-to-end spend throughput was measured at a 32-vCPU peer.
Takeaways & Limitations
Fabric’s hybrid replication and execute-order-validate design supports scalable permissioned blockchains with flexible trust assumptions.
Takeaways & Limitations
The reported performance is preliminary because Fabric was not yet performance-tuned and depends on many deployment parameters.
Abstract
from arXiv · showhide
Fabric is a modular and extensible open-source system for deploying and operating permissioned blockchains and one of the Hyperledger projects hosted by the Linux Foundation (www.hyperledger.org). Fabric is the first truly extensible blockchain system for running distributed applications. It supports modular consensus protocols, which allows the system to be tailored to particular use cases and trust models. Fabric is also the first blockchain system that runs distributed applications written in standard, general-purpose programming languages, without systemic dependency on a native cryptocurrency. This stands in sharp contrast to existing blockchain platforms that require "smart-contracts" to be written in domain-specific languages or rely on a cryptocurrency. Fabric realizes the permissioned model using a portable notion of membership, which may be integrated with industry-standard identity management. To support such flexibility, Fabric introduces an entirely novel blockchain design and revamps the way blockchains cope with non-determinism, resource exhaustion, and performance attacks. This paper describes Fabric, its architecture, the rationale behind various design decisions, its most prominent implementation aspects, as well as its distributed application programming model. We further evaluate Fabric by implementing and benchmarking a Bitcoin-inspired digital currency. We show that Fabric achieves end-to-end throughput of more than 3500 transactions per second in certain popular deployment configurations, with sub-second latency, scaling well to over 100 peers.
1 INTRODUCTION
Hyperledger Fabric is a modular, extensible permissioned blockchain designed to overcome limitations of prior systems, including rigid consensus, fixed smart-contract languages, and order-execute processing. Its central innovation is a hybrid execute-order-validate architecture that combines passive and active replication to support scalable execution and flexible trust assumptions.
- Limitations: Existing order-execute blockchains require every peer to execute every transaction sequentially and require transactions to be deterministic.This architecture creates limitations for non-deterministic or resource-intensive applications.
- Fabric: Fabric is a modular, extensible general-purpose permissioned blockchain supporting distributed applications written in standard programming languages.The platform was used in more than 400 prototypes, proofs-of-concept, and production distributed-ledger systems across industries and use cases.
- Architecture: Fabric separates transaction processing into execution and endorsement, consensus-based ordering, and deterministic validation.These steps may run on different entities, and ordering is performed irrespective of transaction semantics.
- Architecture: Each transaction is endorsed only by a subset of peers, enabling parallel execution, addressing potential non-determinism, and supporting flexible endorsement policies.This design uses passive or primary-backup replication adapted to untrusted environments with Byzantine faults.
- Innovation: Fabric combines passive and active replication in the Byzantine model to resolve prior limitations and support scalable permissioned blockchains with flexible trust assumptions.Its active-replication component writes transaction effects only after consensus establishes a total order, while validation is deterministic and performed by each peer.
- Implementation: Fabric uses modular building blocks including ordering, membership, gossip, and containerized smart-contract services.The membership service associates peers with cryptographic identities, while containers isolate smart contracts.
2 BACKGROUND
Permissioned blockchains traditionally use an order-execute architecture, but sequential execution, nondeterminism, confidentiality requirements, fixed trust assumptions, and hard-coded consensus limit general-purpose deployments. These limitations motivate architectures that separate execution from ordering and support more flexible trust and consensus models.
- Traditional architecture: Previous blockchain systems generally order transactions through consensus and then execute them sequentially in the same order on every peer.This order-execute model is conceptually simple and widely used.
- Architecture drawbacks: Sequential execution on all peers limits effective throughput because throughput is inversely proportional to execution latency.The resulting bottleneck is especially problematic for general-purpose smart contracts.
- Architecture drawbacks: Order-execute systems require deterministic post-consensus execution, making general-purpose languages difficult to use safely because hidden implementation details can cause divergent ledger states.Domain-specific languages such as Ethereum Solidity address this by restricting execution, but require additional learning and are difficult to design.
- Architecture drawbacks: Running every smart contract on every peer conflicts with permissioned-blockchain use cases that require confidentiality for contract logic, transaction data, or ledger state.Propagating the same state instead of running identical code everywhere permits execution by a trusted subset of peers.
- Trust and consensus: Most permissioned blockchains assume n > 3f peers can tolerate up to f Byzantine faults, often using the same peers for consensus and application execution.This fixed trust model constrains how trust can be assigned across system functions.
- Trust and consensus: Fabric introduced pluggable consensus because consensus protocols vary across deployment conditions, and protocols optimized for homogeneous LANs can degrade badly on heterogeneous wide-area networks.Changing load, network parameters, faults, and attacks make reconfigurable or dynamically adaptive BFT consensus desirable.
3 ARCHITECTURE
Fabric’s architecture separates transaction execution, ordering, and validation in a permissioned, modular system for general-purpose applications without a built-in cryptocurrency. This separation supports configurable trust, consensus, and application policies while containing nondeterminism and certain denial-of-service risks.
- Architecture: Fabric introduces an execute-order-validate architecture for distributed applications written in general-purpose languages without a built-in cryptocurrency.Applications comprise chaincode implementing application logic and an endorsement policy evaluated during validation.
- Transaction flow: Clients obtain endorsements from designated peers, after which a pluggable ordering service totally orders endorsed transactions into blocks per channel.Peers execute proposals and validate transactions, while orderers establish transaction order without maintaining blockchain state or executing transactions.
- Design choices: Executing before ordering confines nondeterministic chaincode effects to liveness of the affected operations, while endorsers may abort suspected denial-of-service executions without harming consistency.Under contention, unsynchronized endorsers can produce different outputs, preventing clients from satisfying policies requiring matching endorsements.
- Transaction flow: Validation checks endorsement-policy satisfaction and read-write conflicts, marking unsatisfied transactions invalid and disregarding their effects.The validation system chaincode evaluates endorsements against the configured policy before conflict checking.
- Trust model: Fabric decouples application trust assumptions, expressed through endorsement policies, from consensus trust assumptions implemented by the ordering service.This separation allows applications and consensus to use independent trust models.
4 FABRIC COMPONENTS
Fabric’s components provide modular identity management, transaction ordering, peer communication, ledger storage, and channel configuration for permissioned blockchain networks. The architecture separates key processing responsibilities while supporting configurable ordering and organization-wide identity federation.
- Membership Service Provider: The membership service provider maintains node identities and issues credentials for authentication and authorization through digital signatures.Its abstraction supports standard PKI, commercial certification authorities, Fabric-CA, and envisioned anonymous-credential implementations.
- Membership Service Provider: Identity federation lets multiple organizations issue identities to their own members while peers recognize members across all participating organizations.This can be implemented with multiple MSP instantiations mapped to organizations.
- Ordering Service: The ordering service provides per-channel atomic broadcast, channel reconfiguration, and optional access control for broadcasting transactions and receiving blocks.Production deployments use OSNs as proxies to Kafka, while Solo and BFT-SMaRt provide alternative ordering implementations, demonstrating consensus modularity.
- Ordering Service: OSNs deterministically batch atomically delivered transactions into blocks when a transaction-count limit, byte-size limit, or elapsed-time condition is reached.The resulting block lists are identical across nodes, and OSNs persist recently delivered blocks for peer retrieval.
- Peer Components: The ledger component persists blocks and versioned state while enabling simulation, validation, and ledger updates; gossip disseminates information through mutually authenticated gRPC/TLS push and pull.The block store uses append-only files, and the peer transaction manager stores each key’s latest value with a unique, monotonically increasing version.
5 EVALUATION
The evaluation uses Fabcoin, a Bitcoin-inspired authority-minted cryptocurrency, to provide preliminary Fabric performance measurements despite the system not yet being performance-tuned. Results show high throughput and sub-second latency, while validation, ordering, storage, and WAN network connections constrain performance and motivate pipelining, parallelization, and gossip.
- 5.1 Fabcoin implementation: Fabcoin, a Bitcoin-inspired authority-minted cryptocurrency, serves as Fabric’s benchmark application because no standard blockchain benchmark exists.Its UTXO-based data model also demonstrates customization of validation and endorsement policies.
- 5.1 Fabcoin implementation: UTXO transfers consume input states, create output states for new owners, and preserve value by requiring equal input and output sums.Ownership is represented through the owner’s public key in each state.
- 5.2 Benchmark and results: 3560 tps average spend throughput and 3420 tps average mint throughput were measured at the 32-vCPU peer, with mint throughput within 10% of spend throughput.Validation effort limits end-to-end throughput, while Fabcoin’s endorsement-policy verification scales quasi-linearly with CPU.
- 5.2 Benchmark and results: 550ms average latency and sub-second tail latency were achieved, although ordering dominated overall latency and the first blocks were slowest during load buildup.The orderer’s time-to-cut parameter can reduce latency under lower load.
- 5.2 Benchmark and results: 3870 SPEND tps was sustained with RAM-disk stable storage at a 32-vCPU peer, roughly a 9% improvement over SSD.The benefit was limited because tmpfs helped only the ledger phase of peer validation.
- 5.2 Benchmark and results: 2544/2753 tps mint/spend peak throughput was achieved with gossip across 90 peers, compared with 1910 tps mint and 2190 tps spend when ordering-service connections saturated.The evaluation identifies sequential validation, stable-storage access, read-write dependency checks, and WAN connection saturation as scalability constraints.
6 APPLICATIONS AND USE CASES
Fabric is offered by major cloud operators and powers more than 400 distributed-ledger prototypes and proofs of concept, as well as several production systems across industries. Applications include foreign-exchange netting, enterprise asset management, and cross-currency payments.
- Applications and deployments: Fabric powers more than 400 distributed-ledger prototypes and proofs of concept, plus several production systems across industries and use cases.Major cloud operators offering or announcing Fabric-based blockchain-as-a-service include Oracle, IBM, and Microsoft.
- Foreign exchange (FX) netting: FX-netting systems use a separate Fabric channel for each client-institution pair, while a settler belongs to every channel and runs ordering.The blockchain resolves unsettled trades, maintains ledger information, and provides clients real-time access to the data.
- Enterprise asset management (EAM): Enterprise asset management records hardware assets from manufacturing through deployment and disposal, alongside associated software licenses and lifecycle evidence.The ledger provides a transparent shared system of record for participants and improves data quality relative to traditional solutions.
- Global cross-currency payments: IBM’s cross-currency payment solution records participant-endorsed financial payments and agreed conditions, giving appropriate parties insight into clearing and settlement.The solution has operated since October 2017 for partners in the APFII organization in the Pacific region.
- Global cross-currency payments: Settlement can vary by participant configuration, including Lumens or methods determined by the traded financial instrument.The solution supports all payment types and values and lets financial institutions choose the settlement network.
7 RELATED WORK
Fabric extends middleware-replicated database designs from crash-failure settings to distributed trust and Byzantine fault tolerance through its execute-order-validate architecture. It also relates to BFT database replication and permissioned ledgers while differing from existing platforms’ order-execute design.
- Middleware-replicated databases: Fabric generalizes middleware-replicated database designs from crash failures to Byzantine fault tolerance for distributed ledgers.Prior replicated-database work addressed crash failures rather than distributed trust, including asymmetric update processing that relied on one node to execute each transaction.
- BFT database replication: Byzantium and HRDB are predecessors of Fabric from the perspective of BFT database replication.Byzantium supports parallel transactions and active replication but totally orders transaction boundaries through BFT middleware; its optimistic mode coordinates operations through a single master replica.
- BFT state-machine replication: Eve shares Fabric’s independent transaction execution but lacks Fabric’s other features.Eve executes transactions concurrently, verifies matching output states through consensus, and rolls back to sequential execution when states diverge.
- Permissioned distributed ledgers: All surveyed permissioned distributed-ledger platforms follow an order-execute architecture, unlike Fabric’s execute-order-validate approach.The comparison includes Tendermint, Quorum, Chain Core, Multichain, Hyperledger Sawtooth, and the Volt proposal, among others.
8 CONCLUSION
Fabric concludes as a modular, extensible distributed operating system for permissioned blockchains, with an architecture separating transaction execution from consensus and supporting policy-based endorsement. Its modularity motivates future work on performance, scalability, consistency, resilience, privacy, and confidentiality.
- Conclusion: Fabric is a modular and extensible distributed operating system for running permissioned blockchains.The conclusion characterizes Fabric’s overall role and design scope.
- Conclusion: Its novel architecture separates transaction execution from consensus and enables policy-based endorsement.The architecture is described as reminiscent of middleware-replicated databases.
- Conclusion: Fabric’s modularity supports further improvements and investigations across performance, scalability, consistency, resilience, privacy, and confidentiality.Future work includes benchmarks and optimizations, large deployments, more general data models, alternative consensus protocols, and cryptographic techniques for transactions and ledger data.