Hyperledger development explained: how Fabric, Besu and the rest of the stack fit together

"Hyperledger development" today usually means building a permissioned network on Hyperledger Fabric or an Ethereum-compatible network on Hyperledger Besu. Both are open-source projects now hosted by LF Decentralized Trust, the Linux Foundation organization that absorbed the Hyperledger Foundation in 2024.

Hyperledger is not a single blockchain and not a cryptocurrency. It began in 2015 as an umbrella of enterprise-oriented ledger projects, and the umbrella has been reshaped several times since. Understanding which projects are alive, and what each is good at, is the first step to a sensible architecture. For a buyer's view of scoping and staffing a project, see the companion Hyperledger development guide; this article focuses on how the technology works.

The project landscape in 2026

If an older proposal recommends Sawtooth or Burrow, treat that as a red flag about how current the advice is.

How Hyperledger Fabric works

Fabric's design is unusual, and its strengths and weaknesses both come from it.

Execute, order, validate

Most blockchains order transactions first and then execute them. Fabric reverses this. A client sends a transaction proposal to endorsing peers, which simulate the chaincode and sign the read and write sets they produced. The client collects enough endorsements to satisfy the endorsement policy, then sends the transaction to the ordering service. Orderers put transactions into blocks without executing them. Finally, every peer validates each transaction: are the endorsements valid, and have the keys it read changed since simulation? If so, the transaction is marked invalid.

The benefit is parallel execution and non-deterministic chaincode being caught before commit. The cost is that heavily contended keys produce MVCC read conflicts, so data models must avoid "hot" keys such as a single global counter.

Identity and membership

Every participant has an X.509 certificate issued by its organization's certificate authority. A Membership Service Provider (MSP) maps certificates to organizations and roles. This is the core of Fabric's permissioning: there are no anonymous accounts.

Channels and private data

A channel is a separate ledger shared by a subset of organizations. Private data collections go further: the actual data is shared only among authorized peers, and only its hash goes on the channel ledger. Choosing between channels and collections is one of the main design decisions in any Fabric project.

Chaincode

Smart contracts in Fabric are called chaincode and are written in Go, Java or JavaScript/TypeScript. They read and write a key-value world state, stored in LevelDB or CouchDB (the latter allows rich JSON queries). Chaincode lifecycle requires organizations to approve a definition before it's committed, which gives consortium members a vote on code changes.

Ordering and consensus

Fabric's production ordering service has used Raft, which tolerates crashed nodes but not malicious ones. Fabric 3.x added a Byzantine-fault-tolerant ordering option for consortia that don't fully trust each other's orderers.

How Hyperledger Besu differs

Besu is an Ethereum client, so it runs the EVM and Solidity contracts, and it can join Ethereum mainnet. For private networks it offers proof-of-authority consensus (QBFT is the recommended choice), node and account permissioning, and integration with privacy managers for private transactions. Because it's Ethereum, you get standard tools (Foundry, Hardhat, MetaMask-compatible wallets, ERC-20 and ERC-721 tokens) and a path to settle or anchor on public networks later. Besu also incorporates much of the enterprise feature set that GoQuorum users relied on; see the Quorum development guide for that lineage.

Fabric vs Besu: choosing

For a wider comparison that includes R3's platform, see the Corda development guide and the overview of private blockchain development.

What a Hyperledger project involves

1. Prove you need a shared ledger. If one organization controls all writes and everyone trusts it, a conventional database with an audit log is cheaper and simpler. Blockchain earns its place when several parties need a shared record 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 sink more consortium projects than technical ones.
3. Model data and privacy. Map each data type to a channel, a private collection, or off-chain storage with an on-chain hash. Personal data generally belongs off-chain.
4. Write and test chaincode. Keep business logic deterministic, avoid hot keys, and write unit tests plus integration tests against a local network.
5. Build the integration layer. Most effort goes here: connecting ERP, identity and existing systems through gateway SDKs or middleware such as FireFly.
6. Deploy and operate. Kubernetes deployment, certificate rotation, backups, monitoring, upgrade procedures. Plan who is on call in each member organization.
7. Pilot, then scale membership. Start with two or three organizations and a narrow workflow.

Common Fabric design mistakes

• Hot keys. Storing a running total or a single "latest ID" under one key causes MVCC conflicts as soon as traffic grows. Use composite keys and compute aggregates off-chain or with delta records.
• Non-deterministic chaincode. Reading the system clock, generating random numbers, iterating Go maps or calling external APIs inside chaincode produces different results on different endorsers and causes endorsement mismatches. Use the transaction timestamp and pass external data in as arguments.
• Too many channels. Creating a channel for every pair of organizations multiplies operational work. Private data collections often achieve the same privacy within one channel.
• Weak endorsement policies. A policy satisfied by any single organization lets one member write whatever it likes. Match the policy to the business rule, for example requiring both buyer and seller to endorse an order.
• Personal data on the ledger. Even in a permissioned network, data written to a channel is replicated to every member peer and is hard to remove. Keep personal data in private collections with purge settings, or off-chain.
• Ignoring certificate lifecycles. Expired certificates have taken down production networks. Automate renewal and monitor expiry dates.
• Treating the ledger as the query engine. Rich CouchDB queries in chaincode are slow and not re-validated at commit. Stream block events into an off-chain database for reporting and analytics.

Realistic cost and timeline drivers

There are no license fees for the software itself; the cost is people and infrastructure. As a rough, assumption-based estimate, a focused pilot with a team of three to five engineers (chaincode, integration, DevOps) running for three to six months is common. What moves the number most:

• the number of member organizations and how many systems each needs to integrate;
• privacy requirements (each channel and collection adds design and operations work);
• identity integration with existing enterprise directories;
• regulatory needs such as data residency and audit;
• whether members run their own nodes or one party hosts everything.

Where Hyperledger has worked, and where it hasn't

Permissioned ledgers have done best where many organizations already exchange the same records and reconciliation is painful: trade documentation, provenance, certificates and credentials. Several high-profile consortium projects have also shut down, including IBM and Maersk's TradeLens, which closed in 2023 after failing to reach the industry-wide adoption it needed. The lesson is that the network effect, not the ledger, is the hard part. A technically sound Fabric network with one dominant member and reluctant partners is a database with extra steps.

Healthcare and pharma are frequent candidates; the article on blockchain in healthcare covers that sector's specific constraints.

Frequently asked questions