Hyperledger Fabric explained: how it works, how it compares with Besu, and when to use it

Hyperledger Fabric is an open-source permissioned blockchain for networks of known organizations. This article explains what Hyperledger is, how Fabric processes a transaction, how it compares with Hyperledger Besu, and the design mistakes that cause most Fabric problems.

The companion Hyperledger development guide covers scoping, staffing and buying a project, and this article covers how the technology works.

What is Hyperledger?

Hyperledger is not a single blockchain and not a cryptocurrency. The Linux Foundation started Hyperledger in 2015 as a group of open-source ledger projects for business use. In 2024 the Hyperledger Foundation became part of LF Decentralized Trust, a new Linux Foundation organization that now hosts the projects. The two most used projects are Fabric, a permissioned ledger, and Besu, an Ethereum client.

A proposal that recommends Sawtooth or Burrow for a new project relies on outdated information.

How Hyperledger Fabric works

Fabric's design differs from most blockchains, and both its strengths and its limits come from that design. The current release line is version 3.1, and version 2.5 still receives long-term support fixes.

Execute, order, validate

Most blockchains first put transactions in order and then execute them. Fabric reverses the first two steps:

1. Execute. A client sends a transaction proposal to endorsing peers. Each endorsing peer runs the chaincode as a simulation and signs the data the chaincode read and wrote.
2. Order. The client collects enough endorsements to meet the endorsement policy and sends the transaction to the ordering service. The orderers put transactions into blocks without running them.
3. Validate. Every peer checks each transaction in the block, confirming the endorsements and checking whether any key the transaction read has changed since the simulation. If a key changed, the peer marks the transaction invalid.

This design lets peers simulate transactions in parallel and catches chaincode that gives different results on different peers before anything is committed. The drawback is that two transactions can conflict when they read and change the same busy key, which Fabric calls an MVCC conflict. Data models must therefore avoid "hot" keys, such as one global counter that every transaction updates.

Since version 2.4, client applications connect through the Fabric Gateway service, which collects endorsements and submits the transaction for the client.

Identity and membership

Every participant has an X.509 certificate from its organization's certificate authority. A Membership Service Provider (MSP) maps each certificate to an organization and a role. Fabric has no anonymous accounts, and this mapping is the core of its permissions.

Channels and private data

A channel is a separate ledger shared by a subset of organizations. A private data collection goes further: the data itself goes only to authorized peers, and only a hash of the data goes on the channel ledger. Choosing between channels and private data collections is one of the main design decisions in a Fabric project.

Chaincode

Fabric calls its smart contracts chaincode, and developers write it in Go, Java or JavaScript/TypeScript. Chaincode reads and writes a key-value world state stored in LevelDB or CouchDB, and CouchDB allows rich JSON queries. Before new chaincode runs, the organizations must approve its definition, so consortium members get a vote on code changes.

Ordering and consensus

Fabric's production ordering service has long used Raft. Raft keeps working when nodes crash, but it does not protect against nodes that act maliciously. Fabric 3.0 added an ordering service that tolerates Byzantine faults, based on the SmartBFT library. A SmartBFT ordering service keeps working while fewer than one third of its nodes misbehave. Version 3.0 also removed the system channel, so organizations now create and join channels without one.

How Hyperledger Besu differs

Besu is an Ethereum client that runs the EVM and Solidity contracts, and it can join Ethereum mainnet. For private networks, Besu offers proof-of-authority consensus, with QBFT as the recommended choice. Besu also offers node and account permissions and support for private transactions. Because Besu is Ethereum, teams can use standard tools such as Foundry, Hardhat, MetaMask-compatible wallets, ERC-20 tokens and ERC-721 tokens. A private Besu network can later settle on, or anchor data to, a public chain. Besu includes much of the enterprise feature set that GoQuorum users relied on. The Quorum development guide covers that history.

Hyperledger Fabric vs Besu

The Corda development guide adds R3's platform to the comparison, and the private blockchain guide covers permissioned networks in general.

Building on Hyperledger Fabric: the steps

1. Confirm the need for a shared ledger. If one organization controls all writes and everyone trusts it, a normal database with an audit log costs less. A blockchain is useful when several parties need a shared record that none of them controls alone.
2. Design the consortium. Decide which organizations run peers and orderers, who issues identities, how members join and leave, and who approves chaincode upgrades. Governance problems end more consortium projects than technical problems do.
3. Model the data and privacy. Map each data type to a channel, a private data collection, or off-chain storage with a hash on-chain. Personal data generally belongs off-chain.
4. Write and test chaincode. Keep the business logic deterministic, avoid hot keys, and write unit tests plus integration tests against a local network.
5. Build the integration layer. Most of the effort goes into this layer, which connects ERP, identity and other existing systems through the Gateway SDKs or middleware such as FireFly.
6. Deploy and operate. Plan Kubernetes deployment, certificate rotation, backups, monitoring and upgrades. Decide who is on call in each member organization.
7. Pilot, then add members. Start with two or three organizations and one narrow workflow.

Common Fabric design mistakes

• Hot keys. A running total or a single "latest ID" stored under one key causes MVCC conflicts as traffic grows. Use composite keys, and compute totals off-chain or from separate delta records.
• Non-deterministic chaincode. Chaincode that reads the system clock, generates random numbers, iterates over Go maps or calls outside APIs gives different results on different endorsers, so the endorsements do not match. Use the transaction timestamp, and pass outside data in as arguments.
• Too many channels. A channel for every pair of organizations multiplies the operations work. Private data collections in one channel often give the same privacy.
• Weak endorsement policies. A policy that any single organization can satisfy lets one member write whatever it wants. Match the policy to the business rule, for example by requiring both the buyer and the seller to endorse an order.
• Personal data on the ledger. Data written to a channel is copied to every member peer and is hard to remove, even in a permissioned network. Keep personal data in private data collections with purge settings, or off-chain.
• Expired certificates. Expired certificates have taken production networks offline. Automate renewal and monitor expiry dates.
• Using the ledger for reporting. Rich CouchDB queries inside chaincode are slow, and Fabric does not re-check their results at commit. Stream block events into an off-chain database for reports and analytics.

Cost and timeline drivers

Fabric has no license fees, so the cost is people and infrastructure. As a rough estimate based on typical team sizes, a focused pilot often uses three to five engineers for chaincode, integration and DevOps over three to six months. These factors change the cost most:

• the number of member organizations, and how many systems each one needs to connect;
• privacy needs, because each channel and collection adds design and operations work;
• connecting identity to existing company directories;
• rules on data residency and audit;
• whether each member runs its own nodes or one party hosts everything.

Where Fabric has worked, and where it has not

Permissioned ledgers have done best where many organizations already exchange the same records and reconciliation is costly, such as trade documents, product provenance, certificates and credentials. Several large consortium projects have also closed: IBM and Maersk shut down TradeLens in 2023 because TradeLens did not get enough of the shipping industry to join. A Fabric network with one dominant member and reluctant partners works like a shared database with more overhead. The blockchain case studies page covers TradeLens in more detail.

Healthcare and pharma projects often consider Fabric. The article on blockchain in healthcare covers that sector's limits.

Frequently asked questions