Enterprise Blockchain Ecosystem
The enterprise blockchain space is crowded: Hyperledger Besu, Fabric, Indy, R3 Corda, Quorum. Each for different purposes. This module surveys the landscape so you can pick the right tool for your project.
Recap: From Why to What
In Module 15 you learned why enterprises reach for permissioned blockchains: privacy, compliance, performance, cost predictability, known identity, and formal governance. You also learned when not to use a blockchain at all. Now it is time to answer the natural follow-up: which one?
A Crowded Landscape
The enterprise blockchain space is surprisingly crowded. You will hear about the Hyperledger umbrella (Linux Foundation), R3 Corda, JPMorgan's Quorum, the Enterprise Ethereum Alliance, ConsenSys products, and a long tail of niche platforms. They all claim to be the right answer for the enterprise. They are not all the same — in fact, some of them are radically different from each other.
The Goal of This Module
This module is a guided tour of the landscape. By the end you should be able to name the main platforms, explain in one sentence what each is good at, and know which one you would reach for in a given scenario. The next two modules (17 and 18) then dive deep into Besu and Fabric, the two platforms we will actually build on.
Key Idea
There is no single “enterprise blockchain.” There is a family of platforms, each designed for a different combination of privacy, identity, programmability, and industry focus. Choosing the right one is an architectural decision as important as choosing a database.
The Hyperledger Umbrella
Hyperledger is not a single blockchain — it is an umbrella project hosted by the Linux Foundation since 2015. Under that umbrella lives a family of independent, open-source enterprise blockchain platforms, each with its own architecture, consensus, and programming model.
One Umbrella, Many Projects
Think of Hyperledger less like “Ethereum” and more like “Apache.” The Apache Software Foundation hosts Kafka, Cassandra, Spark, and many more — all very different beasts, all sharing an open-source philosophy. Hyperledger works the same way: it is a governance and community structure, not a single codebase.
Hyperledger Besu
An EVM-compatible Ethereum client written in Java. Can run on public Ethereum mainnet or as the engine of a private consortium network. Supports IBFT 2.0 and QBFT consensus. Your Solidity contracts, Hardhat scripts, and viem tooling all work unchanged.
Hyperledger Fabric
A modular, channel-based permissioned platform originally from IBM. No native currency. Supports fine-grained privacy through channels and private data collections. Smart contracts (“chaincode”) are written in Go, JavaScript, or Java. The most widely deployed enterprise chain.
Hyperledger Indy
A platform purpose-built for decentralised identity and verifiable credentials. Powers self-sovereign identity systems where users hold their own credentials instead of relying on a central identity provider.
Hyperledger Iroha
A simpler, mobile-friendly permissioned chain with a built-in command set (create asset, transfer asset, add signatory). Often used in payments and asset-management scenarios where you want batteries included.
Hyperledger Sawtooth
A modular platform notable for its PoET (Proof of Elapsed Time) consensus, originally designed to run on Intel SGX hardware. Pluggable consensus, parallel transaction execution, and support for multiple smart contract languages.
And More
The umbrella also hosts tooling projects like Hyperledger Cacti (cross-chain interop), Firefly (supernode and API), Aries (identity toolkit), and Caliper (benchmarking). You rarely use all of these at once — you pick the parts you need.
Takeaway
When someone says “we're using Hyperledger,” always ask which Hyperledger project. Besu and Fabric have almost nothing in common except the logo.
Hyperledger Besu
Besu is the enterprise-friendly Ethereum client you already (almost) know. It is an open-source, Java-based implementation of the Ethereum protocol, donated to Hyperledger by ConsenSys in 2019. For a Solidity developer, Besu feels like home.
Fully EVM-Compatible
Besu speaks the same EVM bytecode, the same JSON-RPC API, and the same account model as Geth, Erigon, or Nethermind. Everything you learned in Part 2 — Solidity, Hardhat, Foundry, viem, MetaMask — works on Besu without changes. You can even sync Besu to public Ethereum mainnet.
Private Consortium Networks
The real value of Besu for the enterprise is running it as a private network. You pick a set of validators, configure a genesis file, and spin up a chain where only approved nodes can join. You keep all the Ethereum developer experience, but on a chain where you control membership, block times, and gas costs.
IBFT 2.0 and QBFT
Instead of Proof of Work or Proof of Stake, Besu supports two Byzantine Fault Tolerant consensus algorithms designed for known validator sets: IBFT 2.0 and QBFT. Both offer deterministic finality, no reorgs, sub-second block times, and safety as long as fewer than a third of validators misbehave. Validators can be added or removed through on-chain voting.
Permissioning and Private Transactions
Besu ships with node permissioning (who can join the network) and account permissioning (who can send transactions). Combined with the companion Tessera privacy manager, it also supports private transactions visible only to a subset of participants — crucial for consortium use cases.
Familiar Tooling
Hardhat, Foundry, viem, Ethers, Remix, MetaMask, Truffle — all of them connect to Besu the same way they connect to Anvil or a fork of mainnet. The learning curve from “public Ethereum dev” to “Besu enterprise dev” is measured in hours, not months.
Coming in Module 17
In the next module you will spin up a local IBFT 2.0 Besu network on your machine, configure validators, deploy a Solidity contract to it, and interact with it from Hardhat and viem — exactly like in Part 2, but on your own chain.
Hyperledger Fabric
Fabric is a completely different beast from Besu. If Besu is “Ethereum for the enterprise,” Fabric is “a permissioned distributed ledger, designed from scratch for B2B.” It is the most widely deployed enterprise blockchain in production today.
A Radically Different Architecture
Fabric has no native currency, no EVM, and no gas. It does not use Solidity. Its transaction lifecycle does not look like Ethereum's at all. Instead of a single ordered log replicated everywhere, Fabric splits roles across endorsers, orderers, and committers, and uses channels to isolate subgroups of members.
Endorse → Order → Validate
A Fabric transaction flows through three phases: (1) the client sends a proposal to endorsing peers, who simulate it and sign the result; (2) the endorsed transaction is sent to an ordering service, which sequences it into blocks; (3) every peer validates the block against endorsement policies and commits it to its ledger. This separation gives Fabric high throughput and fine-grained privacy.
Channels: Sub-networks Inside a Network
A channel is essentially a private sub-blockchain inside a Fabric network. Only members of a channel see its ledger. A consortium can run one channel for “all members,” another channel for “pairwise deals between Bank A and Bank B,” and yet another for “regulatory reporting.” Data is cryptographically isolated between channels.
Chaincode (Smart Contracts)
Fabric's smart contracts are called chaincode. They are written in Go, JavaScript/TypeScript, or Java — general-purpose languages, not a DSL. Chaincode interacts with a key-value world state (LevelDB or CouchDB) and is installed per-organisation, then instantiated on a channel.
MSPs and PKI
Identity is first-class in Fabric. Every organisation runs a Membership Service Provider (MSP) backed by an X.509 certificate authority. Every transaction is signed by an identified organisation, and endorsement policies are expressed in terms of these organisations — e.g. “requires signatures from any 2 of Bank A, Bank B, Bank C.”
Where Fabric Shines
Fabric is the platform of choice when you need fine-grained privacy, multiple independent sub-networks, or when you want to write business logic in a mainstream language. It powers IBM Food Trust (still live) and many bank, insurance and identity consortia. The shipping network TradeLens and the banking network we.trade also ran on Fabric, but have been discontinued (TradeLens in Q1 2023, we.trade in June 2022) — see Module 19 for the autopsy.
Coming in Module 18
Module 18 walks you through setting up a Fabric test network, writing chaincode in Go or JavaScript, defining endorsement policies, and querying the ledger from a Node.js client application.
R3 Corda
Corda, built by the consortium R3, is arguably the most unusual platform in this landscape — some people argue it is not even a blockchain in the strict sense. It was designed from the ground up for financial institutions, and its architecture reflects that.
Point-to-Point, Not Global Broadcast
In a classic blockchain, every node sees every transaction. In Corda, only the parties involved in a deal see its data. Transactions are sent directly between the relevant nodes, not broadcast to a global network. There is no single chain where everyone's activity is pooled together.
Notaries Instead of Miners
Instead of miners or validators, Corda uses notaries — trusted services whose job is to prevent double-spending by signing off on transaction uniqueness. Different deals can use different notaries, and a notary can itself be a BFT cluster for fault tolerance.
States, Contracts, and Flows
A Corda transaction consumes input states and produces output states, governed by contracts (Kotlin/Java code that validates transactions) and choreographed by flows (the business protocol between parties). The model is closer to Bitcoin's UTXO than to Ethereum's account model.
CorDapps
A Corda application — a CorDapp — is a JVM package containing states, contracts, and flows. It is written in Kotlin or Java and deployed to the nodes of the parties who want to participate in that specific workflow. Different CorDapps can coexist on the same node without interfering.
Designed for Finance
Corda's privacy model, point-to-point messaging, legal-prose contracts, and notary design all reflect its origin: interbank settlement, syndicated lending, trade finance. Deployments on Corda include HQLAx (live, securities lending), several central bank pilots, and a number of live bank networks. Two of the highest-profile trade-finance consortia — Marco Polo and Contour — also ran on Corda but both shut down (Marco Polo in January 2023, Contour in November 2023); see Module 19 for the post-mortem.
Blockchain or Not?
Corda has no global chain of blocks. Purists argue it is a distributed ledger rather than a blockchain. The pragmatic answer: it solves the same class of problems — multi-party, tamper-evident, identity-aware state — with a different set of trade-offs. For deep financial privacy, it is hard to beat.
Other Platforms You Will Hear About
Besu, Fabric, and Corda are the three platforms you will encounter most often. But the enterprise space has more entries, each with its own niche and history. A quick tour.
Quorum (ConsenSys Quorum / GoQuorum)
Originally a fork of Go-Ethereum built by JPMorgan, Quorum added permissioning, private transactions (via Tessera), and BFT consensus to Geth. JPMorgan later spun it off to ConsenSys, which maintained it as GoQuorum. Besu is effectively its spiritual successor for new deployments — many Quorum networks are migrating to Besu.
Enterprise Ethereum Alliance (EEA)
The EEA is not a platform but a standards body. It publishes specifications for enterprise features on top of Ethereum (privacy, permissioning, client APIs) so that Besu, Quorum, and other clients can be broadly interoperable. If you see “EEA-compliant,” that's what it means.
Hyperledger Sawtooth
A modular Hyperledger project from Intel, originally showcased for PoET consensus using Intel SGX hardware. It supports multiple smart contract languages and parallel transaction execution. Less widely deployed than Besu or Fabric, but still in use for specific scenarios.
Hyperledger Iroha
A simpler Hyperledger project with a fixed command set (create asset, transfer, add peer, etc.), making it easy to embed in mobile and IoT applications. Popular in Asian markets and in projects where a full smart-contract platform would be overkill.
Chainlink and Oracles
Chainlink is not a blockchain, but it is an essential enterprise building block: a decentralised oracle network that brings off-chain data (prices, FX rates, weather, IoT feeds) and computation onto a blockchain. Most enterprise use cases that touch the real world rely on an oracle layer, and Chainlink is the de facto leader.
Others Worth Knowing
You may also run into Kaleido (a BaaS platform built on Besu/Fabric), Hyperledger Firefly (a supernode and REST API layer), Digital Asset's DAML (a smart contract language that targets multiple ledgers), and Cosmos SDK (used for some permissioned app-chains). This is a non-exhaustive list — the field is still evolving.
Choosing a Platform
So — your team has decided that a permissioned blockchain is the right tool. Which one do you pick? There is no universal answer, but there is a useful decision matrix you can apply in five minutes.
1. Do You Need EVM / Solidity?
If your team already knows Solidity, if you plan to reuse OpenZeppelin contracts, if you want an easy migration path from a public Ethereum proof-of-concept, or if you need composability with existing EVM tooling — choose Besu. You keep the entire Ethereum stack and add enterprise features on top.
2. Do You Need Channel-Level Privacy?
If your consortium needs multiple isolated sub-networks, fine-grained privacy between subsets of members, or you want to write chaincode in Go/Java/JavaScript rather than Solidity — choose Fabric. Its channel model and endorsement policies are hard to beat for complex multi-party privacy.
3. Is It Point-to-Point Finance?
If your use case is essentially bilateral or small-group financial deals — settlement, syndicated loans, trade finance — where only the direct counterparties should see the data, and if your team is comfortable on the JVM, choose Corda. Its privacy model was built for exactly this.
4. Is It Identity and Credentials?
If your core problem is self-sovereign identity, verifiable credentials, or decentralised identifiers (DIDs), reach for Hyperledger Indy and the Aries toolkit. Indy is not a general-purpose chain — it is purpose-built for identity and does it very well.
5. When in Doubt
For most teams coming out of Part 2 of this course, the honest default is start with Besu. You already know the tooling, you can prototype in hours, and you can migrate to Fabric or Corda later if a specific requirement forces you to. Reuse is a superpower; don't throw away the Solidity knowledge you just built unless you have a strong reason.
Quick Decision Matrix
EVM needed? → Besu. Channels and fine-grained privacy? → Fabric. Point-to-point finance? → Corda. Identity and credentials? → Indy. None of the above, or unsure? → Besu (safest default for an Ethereum-trained team).
Exercise & Self-Check
Let's make this landscape concrete. These exercises are short research and decision tasks — no code yet. The goal is to be able to hold a serious conversation about enterprise platforms with an architect or a CTO.
Exercises
- 1. One-sentence pitches. Write a single sentence for each platform: Besu, Fabric, Corda, Indy, Quorum. Each sentence must contain (a) the type of problem it solves and (b) one distinguishing feature.
- 2. Map the Hyperledger projects. Draw a diagram: “Hyperledger” in the middle, each project as a branch, and annotate each branch with its language, consensus model, and one real-world user if you can find one.
- 3. Choose a platform. For each scenario, pick Besu / Fabric / Corda / Indy and justify in two lines: (a) five banks running bilateral FX settlement, (b) a pharma consortium tracking cold-chain shipments, (c) a government issuing digital diplomas, (d) a DAO-like consortium wanting EVM DeFi primitives on a private network, (e) a retailer wanting to port an existing Ethereum loyalty contract to a private chain.
- 4. Compare endorsement models. Read one page each on Fabric endorsement policies and Corda flows. Write 150 words explaining, in your own words, the difference between “endorsement” (Fabric) and “notarisation” (Corda).
- 5. Ecosystem scavenger hunt. Find and cite the official project pages for Besu, Fabric, Corda, Indy, and Chainlink. Note for each: license, main language, GitHub stars, and whether the project is still actively maintained.
Self-Check
- Can you explain, in one sentence each, what Besu, Fabric, and Corda are and what makes them different?
- Do you know at least five projects under the Hyperledger umbrella and roughly what each one is for?
- Can you articulate why Besu is the natural next step after Part 2 of this course?
- Can you explain to a non-technical stakeholder when you would choose Fabric over Besu — and vice versa?
- Do you know what an oracle is, and why Chainlink matters even for enterprise blockchains?