Hyperledger Fabric: A Conceptual Deep Dive
Fabric is the most deployed enterprise blockchain — but its architecture is radically different from Ethereum. No currency, no miners, execute-order-validate flow, channels for privacy, chaincode in Go. Understand the philosophy.
Recap: Leaving the Ethereum Comfort Zone
In Module 17 you got your hands dirty on Besu — which, for all its enterprise features, is still just Ethereum. Same EVM, same Solidity, same Hardhat, same mental model. This module is a different kind of exercise: we are going to look at Hyperledger Fabric, the other dominant enterprise blockchain, and it is built on completely different principles.
Why Fabric Matters
If you count total production deployments, Fabric is arguably the most-deployed enterprise blockchain in the world. IBM Food Trust (still live), TradeLens (shipping — shut down Q1 2023), we.trade (banking — liquidated June 2022), Honeywell's aerospace parts marketplace, and dozens of consortia in insurance, pharmaceuticals and identity all ran — or still run — on Fabric. The fact that several flagship networks went under doesn't change the skill expectation: if you are interviewing for an enterprise blockchain role, you will be asked about Fabric. Module 19 dissects why these projects closed and which patterns still work.
A Radically Different Architecture
Fabric has no native cryptocurrency, no miners, no gas, no EVM, and no Solidity. Transactions are not executed after being ordered — they are executed first, then ordered, then validated. Privacy does not come from encryption on top of a public ledger: it comes from splitting the ledger itself into channels. Identity is not a public key, it is an X.509 certificate. Every assumption from Part 2 gets re-examined.
Module Goal
By the end of this module you should be able to: (1) draw Fabric's three node types and explain what each one does, (2) walk a transaction through the execute-order-validate flow, (3) explain how channels and private data collections enforce confidentiality, (4) describe what chaincode is and how endorsement policies work, (5) compare Fabric and Besu on six concrete axes, and (6) argue when you would pick one over the other.
No Code This Time
This is deliberately a conceptual module. Fabric's stack (Go or JavaScript chaincode packaged as Docker containers, configtx channel genesis blocks, MSP folders, Raft orderers, Fabric CA servers) is large enough to fill an entire course on its own. Our goal here is not to make you a Fabric engineer — it is to make you architecturally literate in Fabric, so you can evaluate it against Besu, pass interviews, and read Fabric documentation when you need to.
Architecture Overview: Peers, Orderers, Clients
Where Ethereum has exactly one kind of node (a full node that does everything — gossip, execute, validate, store), Fabric splits responsibilities across three distinct node types. This separation is the single most important architectural idea in Fabric — it is what makes execute-order-validate, pluggable consensus, and channel privacy possible.
Clients (Applications)
A client is an application using the Fabric SDK (Node.js, Java, Go). Clients do not store the ledger. Their job is to propose transactions: build a transaction proposal, send it to the required endorsing peers, collect endorsements, and forward the bundle to the ordering service. Think of them as the frontend of the whole Fabric dance.
Peers
Peers are the workhorses. They host the ledger, host chaincode, and execute and endorse transactions. Every organisation in the consortium typically runs two or more peers. A peer can be an endorsing peer (simulates transactions and signs the result), a committing peer (validates blocks and writes them to its ledger), or both at the same time. Peers are the closest analogue to an Ethereum full node — but they never order blocks.
Orderers (Ordering Service)
Orderers form the ordering service. Their only job is to receive endorsed transactions from clients, put them in a total order, batch them into blocks, and broadcast those blocks to the peers. They do not execute chaincode and do not know the ledger state. This is the only place where “consensus” happens — and because orderers are isolated, consensus is pluggable (today: Raft; historically: Kafka, Solo; soon: SmartBFT).
Membership Service Provider (MSP)
Every node and every client has an identity. The MSP is the component that says “this X.509 certificate belongs to this organisation and has this role.” Each organisation has its own MSP, backed by a Certificate Authority (CA). Fabric does not use public keys as identities — it uses signed certificates issued by a CA you trust.
No Miners, No Currency
There is no miner, no staking, and no native token. Orderers are paid operationally by the organisation that runs them — not by on-chain fees. This is a huge shift: Fabric is a tool for recording agreements, not a marketplace for computation. That is why you will never see “gas” mentioned anywhere in Fabric.
Organisation-Centric
Fabric's unit of governance is the organisation, not the individual wallet. A typical Fabric network has 3–10 organisations, each running peers and controlling a set of users. Membership, endorsement policies, and channel access are all expressed in terms of organisations, not addresses. This maps very naturally to consortia, which is exactly why enterprise architects love it.
The Big Picture
A minimal realistic Fabric network looks like this: 3 organisations, each with 2 peers (one endorser, one committer), sharing a 1 ordering service made of 3–5 Raft orderers, and a Fabric CA per organisation issuing the X.509 certificates that the MSPs recognise. That is roughly a dozen containers before you have deployed a single line of chaincode. Complexity is the price you pay for modularity.
The Execute-Order-Validate Flow
This is the defining idea of Fabric. Ethereum (and Bitcoin, and almost every other blockchain before Fabric) uses order-execute: transactions are ordered first, then every node re-executes them in the same order to reach the same state. Fabric flips this completely. Transactions are simulated first on a subset of peers, then ordered, then validated against the order. This single change unlocks privacy, performance, and non-determinism tolerance.
Why Flip the Order?
Three big wins. (1) Confidentiality: only endorsing peers ever see the chaincode and inputs of a given transaction — orderers see encrypted blobs. (2) Parallelism: different transactions can be simulated in parallel on different peers before being ordered. (3) Language freedom: because simulation happens before consensus, chaincode can be written in any language and even call non-deterministic APIs (Fabric detects disagreements in the validation phase rather than requiring bit-perfect replay).
The Five Steps, Walked Through
A single Fabric transaction is actually a small choreography between the client, endorsing peers, the ordering service, and committing peers. Here is the full flow, step by step.
Read-Set Versioning (MVCC)
Because transactions are simulated on a possibly stale snapshot, two transactions could legitimately read the same key at the same version and then both try to overwrite it. The validation phase catches this with an MVCC check: if the key's version in the committed state no longer matches the version recorded in the read set, the later transaction is rejected. This is how Fabric provides serialisability without locking.
Contrast with Ethereum
On Ethereum, every node executes every transaction in block order and must reach the exact same result. Non-determinism is catastrophic. On Fabric, only the endorsers execute a given transaction, and determinism is checked after the fact by comparing endorsement signatures. That flexibility is the reason chaincode can be written in general-purpose languages — and why Fabric nodes typically throughput orders of magnitude more TPS than Ethereum clients on equivalent hardware.
Channels & Privacy
On Besu you get privacy by bolting Tessera onto a shared chain and encrypting individual transactions. Fabric takes a completely different approach: don't share the chain in the first place. A channel is a private sub-ledger with its own genesis block, its own members, its own chaincode, and its own history. Two organisations that are not on the same channel literally cannot see each other's transactions — there is nothing to decrypt.
What Exactly Is a Channel?
Think of a channel as a completely independent blockchain, running on the same orderers but only visible to a declared subset of organisations. It has its own configtx (genesis), its own policy for adding members, its own chaincodes installed on its own peers, its own world state, and its own block history. The same physical Fabric network can host dozens of channels simultaneously, each one invisible to the others.
Private Sub-Ledger
Each channel is a full blockchain: it has blocks, transactions, state, and history. Peers maintain a separate ledger file per channel. Joining a channel is a privileged operation that requires a signed config transaction.
Member-Scoped Visibility
Only organisations listed in the channel config can run peers on the channel, endorse transactions, receive blocks, or query the state. There is no such thing as a “channel outsider with a decryption key” — you are either in the channel or you literally do not receive the data.
Multi-Channel Architecture
Real deployments use multiple channels for different business lines: one channel for bilateral contracts between Bank A and Bank B, another for a four-bank syndicated loan, another for a shared KYC registry. Peers join only the channels their organisation belongs to.
Private Data Collections
Sometimes you need even finer granularity: a transaction is on a channel of five banks, but only two of them should see the actual data. Enter Private Data Collections (PDCs): the data lives only on the authorised peers, while everyone else stores only a hash of it on the channel ledger — enough to prove integrity, not enough to leak content.
Hashes as Audit Trail
Because non-members still receive hashes, they can later audit a member's claim (“yes, Bank A told me they made this trade, here is the hash on the channel ledger that proves it”). Privacy and auditability coexist — a very enterprise-friendly property.
The Trade-Off
Channels are powerful but expensive to operate: each one needs its own chaincode lifecycle, its own policies, its own backups. Over-partitioning a Fabric network into too many channels is one of the most common design mistakes. As a rule of thumb, start with one channel and only split when a real privacy requirement appears.
Channels vs Privacy Groups
Besu's privacy groups work at the transaction level on top of a single shared chain: everyone has a block with a hash, only group members can decrypt. Fabric's channels work at the ledger level: non-members don't even have the block. Both are legitimate — but channels offer stronger isolation at the cost of operational complexity, while privacy groups offer lighter-weight confidentiality at the cost of a larger attack surface.
Chaincode: Fabric's Smart Contracts
Fabric's smart contracts are called chaincode. The name is not marketing fluff — it emphasises that these contracts are quite different from their Ethereum cousins. They are not written in Solidity, not compiled to a VM bytecode, and not sandboxed inside a global state machine. They run as ordinary processes — typically as Docker containers — alongside the peers that host them.
Go, JavaScript, or Java
Chaincode is written in Go (most common), JavaScript/TypeScript (via Node.js), or Java. Fabric ships SDKs for all three. There is no DSL: you use ordinary language tooling — linters, unit tests, IDEs — to build your contracts. For developers coming from enterprise backends, this feels very natural.
Packaged as Docker Containers
A chaincode deployment is a tarball + Dockerfile that Fabric builds into a container image. When a peer needs to execute the chaincode, it spins up the container, talks to it via gRPC, and shuts it down. This makes deployment closer to microservices than to “upload bytecode to an address.”
Install, Approve, Commit
The chaincode lifecycle has three stages: you install the package on each participating peer, each organisation approves the package version and endorsement policy, and finally the chaincode is committed to the channel once enough organisations have approved. This is governance by construction.
Endorsement Policies
Every chaincode has an endorsement policy, e.g. “AND('OrgA.member', 'OrgB.member')” or “OutOf(2, 'OrgA.peer', 'OrgB.peer', 'OrgC.peer')”. A transaction is only accepted if it carries signatures from exactly the orgs the policy requires. This is how you enforce business rules like “both buyer and seller must sign” at the protocol level.
No Gas, No Currency
Because there is no native token, there is no gas, no fee auctions, and no “out of gas” errors. A chaincode is free to run long loops and expensive queries — the operator pays the bill, not the user. Of course, in practice, operators set CPU and timeout limits to prevent misbehaving chaincode from DoS-ing the peer.
Key-Value World State
Chaincode reads and writes a key-value store (LevelDB by default, or CouchDB for rich JSON queries). There is no global storage mapping like Solidity's; you decide what the keys mean. This is closer to a document database than to the EVM's Merkle-Patricia trie.
Different Philosophy
Ethereum chose safety through sandboxing: a deterministic VM, gas metering, a narrow API. Fabric chose safety through governance: ordinary code, multi-org endorsement, MSP-backed identity. Neither is strictly better. When you trust your developers but not the network, Ethereum wins. When you trust your peers but need strong organisational guarantees, Fabric wins.
Identity & the Membership Service Provider
In Ethereum, identity is just a public key: whoever controls the private key is the address. It is elegant and completely pseudonymous. In Fabric, identity is a signed certificate. Every participant — user, peer, orderer, admin — carries an X.509 certificate issued by a Certificate Authority that the network trusts. It is the same PKI that powers HTTPS, ported to a blockchain context.
X.509 Certificates
Every identity in Fabric is an X.509 certificate carrying a subject (the user or node), an issuer (the CA that signed it), optional attributes (role, organisation unit), and a public key. Transactions are signed with the corresponding private key, and every peer can verify the signature against the public key embedded in the certificate.
Certificate Authorities
Certificates are issued by Certificate Authorities. Fabric ships its own reference CA — Fabric CA — but any enterprise PKI can be plugged in. Each organisation typically runs its own CA, so that it controls who becomes a member of its own org without needing permission from the consortium.
What the MSP Defines
The Membership Service Provider is the component inside each peer and orderer that says: “these are the CAs we trust, these are the certificates we recognise, this certificate belongs to this organisation, this admin role is valid.” Without the MSP, a signed message is just a blob of bytes — the MSP is what gives it meaning.
Org-Tied Identity
Every identity is tied to an organisation. You are not “user 0xabc,” you are “alice@bankA.example.com, member of BankAMSP.” Endorsement policies, channel access, and chaincode governance can all reference organisations directly, instead of trying to classify raw addresses.
Roles and Attributes
Certificates can carry custom attributes (e.g. department=compliance, clearance=level-3) that chaincode can read at runtime. This enables attribute-based access control inside contracts, something Ethereum can only simulate with external registry contracts.
Revocation
Unlike Ethereum private keys (which can only be rotated by moving funds), X.509 certificates can be revoked via a Certificate Revocation List (CRL). When an employee leaves an organisation, their CA publishes a CRL entry and peers immediately reject transactions signed by the revoked certificate. This is a big operational win in regulated environments.
Why PKI, Why Not Public Keys?
Enterprises already have PKI. They already have CAs, HR-driven certificate issuance, and CRL processes. Fabric plugs directly into that world. Ethereum, by contrast, asks enterprises to invent a whole new identity layer on top of raw public keys — which is why every real Ethereum enterprise deployment eventually ends up reinventing a certificate registry. Fabric just starts there.
Fabric vs Ethereum (Besu)
Both Fabric and Besu are enterprise blockchains. Both are Apache-2.0 open source. Both are governed by the Linux Foundation / Hyperledger. And yet their philosophies are almost diametrically opposite. This is the comparison you want in your head when an architect asks you “which one should we use?”
When to Pick Fabric
You have a clear set of organisations (not just wallets), each with its own users and its own governance. You need strict ledger-level privacy between sub-groups. You want to reuse existing enterprise PKI. You need to write contracts in Go or Java because that is what your team already knows. You never intend to connect to public Ethereum. That is Fabric territory.
When to Pick Besu
Your team already writes Solidity. You want full compatibility with the Ethereum tooling ecosystem (Hardhat, Foundry, viem, MetaMask, OpenZeppelin). You might want to migrate to or from public Ethereum one day. You are comfortable with privacy groups instead of channels. You want one binary to cover both “private consortium” and “public mainnet.” That is Besu territory.
Not Mutually Exclusive
Plenty of real organisations run both Fabric and Besu for different products. IBM's own consortia tend to use Fabric; their CBDC pilots with ConsenSys tend to use Besu. There is no single right answer — the right answer depends on the business requirements, the team's skills, and whether public-chain compatibility is on the roadmap.
Exercise & Self-Check
These exercises are all pen-and-paper: no Fabric installation required. The goal is to force you to actively reason about the architecture, not just recognise it on a slide. Draw things on real paper if you can — the diagrams stick better that way.
Exercises
- 1. Design a 3-org channel. Three banks — A, B, C — want to settle foreign exchange trades on a shared Fabric channel. Sketch the network: how many peers per org, how many orderers, which MSPs, which CAs, and what the endorsement policy for the FX chaincode should be. Justify each choice in one sentence.
- 2. Trace a transaction end-to-end. A client in Org A submits a
transferFX(1M USD, 900k EUR)call. Walk through all five steps of execute-order-validate. At each step, say exactly who is involved, what is produced (read set, write set, signatures, block), and what could go wrong. Bonus: what happens if the MVCC check fails on the committing peer? - 3. Endorsement vs ordering. In your own words (150–200), explain the difference between the endorsement phase and the ordering phase of a Fabric transaction. Why did Fabric's designers split these two responsibilities into different node types? What would break if a single node tried to do both?
- 4. Fabric or Besu? For each of the following scenarios, decide Fabric or Besu, and justify in one paragraph: (a) an NFT marketplace with hopes of going to public Ethereum later, (b) a shared KYC registry across 8 European banks, (c) a central bank digital currency pilot, (d) a supply-chain tracker where an NGO wants read-only audit access, (e) a consortium of 3 logistics providers sharing one bilateral trade lane.
- 5. Healthcare use case. Sketch a Fabric-based healthcare data-sharing network: hospitals, insurers, research labs. Who are the organisations? What channels make sense? Where would you use Private Data Collections instead of a dedicated channel? How are patients (who are not organisations) modelled? Draw it on paper and explain for 10 minutes to an imaginary stakeholder.
Self-Check
- Can you name and explain the roles of Fabric's three node types (clients, peers, orderers) — and why the ordering service is isolated?
- Can you walk through the execute-order-validate flow without looking, including what a read set and a write set contain?
- Can you explain the difference between a channel and a private data collection, and give one scenario where you would reach for each?
- Can you describe what an endorsement policy like
AND('OrgA.member', 'OrgB.member')means, and why it is enforced twice (once by the client, once by the committing peer)? - Can you compare Fabric and Besu on at least five concrete dimensions — currency, identity, privacy, consensus, language — and recommend one for a given consortium?