Why Permissioned Blockchains?
Bitcoin and Ethereum are public. But enterprises often can't use them — privacy, compliance, performance. Part 3 introduces permissioned blockchains: Hyperledger Besu, Fabric, and R3 Corda. Start here with the fundamental question: when and why?
Recap: From Public to Permissioned
In Part 1 you explored Bitcoin, Proof of Work, and the architecture of public blockchains. In Part 2 you mastered Ethereum, Solidity, smart contracts, testing, security, and deployment. Both Bitcoin and Ethereum are public — anyone in the world can read the ledger, submit transactions, run a node, or become a validator. This openness is a feature, not a bug: it is what makes them censorship-resistant and globally neutral.
But there is a catch
For most enterprises, banks, hospitals, and governments, putting sensitive data on a public chain is a non-starter. They face strict privacy laws (GDPR, HIPAA), regulatory obligations (KYC/AML), throughput requirements (thousands of transactions per second), and the simple business reality that you don't want your competitors reading your supply chain in real time. This is where permissioned blockchains enter the picture.
What Part 3 Covers
Part 3 is the enterprise track. Over the next modules you will learn Hyperledger Besu (an Ethereum client tuned for consortia), Hyperledger Fabric (IBM's modular permissioned platform), and R3 Corda (a purpose-built ledger for financial institutions). This module — the gateway to Part 3 — answers the fundamental question: why would anyone use a permissioned blockchain in the first place?
Key Idea
A permissioned blockchain is a distributed ledger where participation (reading, writing, or validating) is restricted to identified, approved parties. It keeps the cryptographic integrity and shared-state benefits of blockchain, but trades global openness for privacy, performance, and compliance.
Public vs Permissioned: The Core Differences
Before we dive into the why, let's draw the line clearly. Public and permissioned blockchains share the same cryptographic DNA — blocks, hashes, signatures, consensus — but they are built for radically different worlds.
Public vs Permissioned at a Glance
| Dimension | Public (Bitcoin, Ethereum) | Permissioned (Besu, Fabric, Corda) |
|---|---|---|
| Access | Anyone can read and write. | Only approved members can read and/or write. |
| Consensus | Open (PoW, PoS) — any validator can join. | Committee-based (IBFT, QBFT, Raft) — known validators. |
| Identity | Pseudonymous addresses, no legal identity. | Identified participants with certificates (PKI). |
| Throughput | 15–30 TPS (Ethereum L1), ~7 TPS (Bitcoin). | Thousands to tens of thousands of TPS. |
| Governance | Global, informal, hard-fork driven. | Formal consortium agreements and by-laws. |
The Mental Model
Think of a public chain as a public highway — anyone with a car can drive on it, tolls are paid in ETH, and everyone sees the traffic. A permissioned chain is more like a private industrial park: you need a badge to enter, the roads are reserved for members, and the cameras are turned off for outsiders.
Why Enterprises Need Permissioned Blockchains
Six reasons come up again and again when enterprises explain why they chose a permissioned chain over a public one. Each of these is, on its own, usually enough to rule out Ethereum mainnet.
1. Privacy
European GDPR, US healthcare HIPAA, industrial trade secrets, client lists, contract pricing — none of this can be published on a public ledger. Even if the data is hashed, the metadata (who talks to whom, how often, for how much) is sensitive. Permissioned chains restrict visibility to the parties that actually need to see the data.
2. Regulatory Compliance
Regulated industries must perform KYC/AML checks, keep audit trails, respect jurisdictional rules, and be able to prove — to a regulator, in court — who did what, when. Public pseudonymity is incompatible with compliance. Permissioned networks embed identity at the protocol level.
3. Performance
Ethereum L1 handles 15–30 TPS. A single retail bank processes thousands of payments per second. Supply chain systems need sub-second finality for scanner events. Permissioned chains use BFT consensus between a handful of validators and routinely reach 10,000+ TPS with deterministic finality.
4. Cost Predictability
On Ethereum, gas prices swing wildly with market conditions — a simple transfer can cost $1 or $100 depending on the day. Enterprises need predictable operating costs. In a permissioned network, transactions are typically free at the protocol level; the cost is the fixed infrastructure you run together with your partners.
5. Known Identity & Accountability
In a consortium, if something goes wrong, you can sue the other party. That sounds mundane, but it is revolutionary compared to public chains where a bug or exploit leaves you chasing an anonymous address. Known identities enable legal accountability, counterparty risk management, and real-world dispute resolution.
6. Governance
Who decides when to upgrade? Who adds new members? Who sets the fees? On Ethereum, it takes years of off-chain politics. In a permissioned network, governance is defined up front by a consortium agreement: the members decide together, on their own schedule, and can upgrade the chain on their terms.
Real Enterprise Use Cases
Permissioned blockchains are not science fiction — they run production systems in some of the world's largest companies. Here are the flagship categories, with real examples you may have heard of.
Supply Chain Traceability
Walmart uses IBM Food Trust (Hyperledger Fabric) to trace leafy greens from farm to shelf in 2.2 seconds — down from 7 days with paper records. Maersk and IBM ran TradeLens for container shipping. The value: faster recalls, fraud detection, and proof of provenance for premium products.
Trade Finance
Letters of credit, invoice financing, and cross-border trade rely on piles of paper documents shared between banks, buyers, sellers, shippers, and customs. Platforms like Marco Polo (Corda) and we.trade (Fabric) digitise and synchronise these workflows across institutions, cutting days off settlement times.
Healthcare Records
Patient records are scattered across hospitals, labs, insurers, and pharmacies. Permissioned chains let authorised providers share consistent, tamper-evident references to medical history while keeping the raw data off-chain, respecting HIPAA and GDPR constraints.
Interbank Settlement
Projects like JPM Coin, Fnality, and several central bank digital currency (CBDC) pilots use permissioned ledgers for wholesale payments between financial institutions — atomic delivery-versus-payment, instant settlement, and far lower reconciliation costs.
Government Registries
Land titles, business registries, diplomas, and identity documents benefit from an immutable audit trail that citizens and auditors can verify. Several governments (Estonia, Georgia, UAE) run permissioned ledgers for notarisation and registry services.
Carbon Credits & ESG
Carbon markets are plagued by double-counting and fraud. Permissioned chains let issuers, verifiers, and buyers share a single source of truth for the issuance, transfer, and retirement of credits — a growing use case for ESG reporting and climate regulation.
Trade-offs: What You Gain, What You Lose
Permissioned blockchains are not a free lunch. For every benefit they unlock, they give something up compared to public chains. Being honest about this trade-off is the mark of a mature architect.
What You Gain
- Privacy: only members see the data — or even finer-grained sub-channels within a single network.
- Speed: thousands of TPS with sub-second, deterministic finality.
- Compliance: identified participants, audit logs, jurisdictional controls.
- Cost predictability: fixed infrastructure cost instead of volatile gas fees.
- Formal governance: upgrades and membership follow a consortium agreement.
What You Lose
- Decentralisation: a handful of validators can collude or be compelled by a regulator.
- Censorship resistance: if the consortium kicks you out, you are out.
- Global settlement: you lose Ethereum's worldwide network effect and composability.
- Open innovation: no anonymous developer can deploy a new DApp on your chain.
- Public trust minimisation: members must still trust each other to some degree.
The Blockchain Spectrum
It helps to think of blockchains on a spectrum of openness: at one extreme, fully public chains like Bitcoin and Ethereum, where anyone can read, write, and validate. In the middle, consortium chains run by a group of organisations (e.g. IBM Food Trust, Marco Polo, we.trade). At the other extreme, fully private chains run inside a single organisation — often barely more than a distributed database with signatures. The right choice depends on how much trust and how much openness you need.
Public
Bitcoin, Ethereum
Consortium
IBM Food Trust, Marco Polo, we.trade
Private
Single-org Fabric / Besu networks
When NOT to Use a Blockchain
Brutal truth: most projects marketed as “blockchain solutions” should just be a database. Blockchain is expensive, slow, operationally complex, and hard to change. Before reaching for it, you must earn the right to use one by answering a few hard questions.
The Four Questions
- 1. Are there multiple writers? If a single organisation owns all the data, use PostgreSQL.
- 2. Do the writers distrust each other? If they all trust a central operator, use a shared database with access control.
- 3. Do you need an immutable audit trail? If not, a normal database with backups is simpler and cheaper.
- 4. Do you need disintermediation? If an existing trusted third party works fine, a blockchain adds cost without benefit.
Verdict
If you answer no to any of these, you probably don't need a blockchain — you need a well-designed database with good access control, backups, and maybe a digital signature scheme. A permissioned blockchain makes sense only when multiple mutually-suspicious parties need to share and jointly update the same state, with cryptographic guarantees of tamper-evidence and no single operator in charge.
Common Anti-Pattern
“We want a blockchain for our internal ERP.” Unless your ERP crosses organisational boundaries and the other party refuses to trust you, this is a distributed database with extra steps. Save yourself the pain: use PostgreSQL, Kafka, and a signed audit log.
Governance Models
Who makes decisions on a permissioned chain? Unlike public blockchains, where governance happens in messy off-chain forums, permissioned networks need explicit, contractual answers to this question — usually before they ever run a single block.
Single Organisation (Private)
One company runs all the nodes. Decisions are unilateral, upgrades are fast, but there is very little trust benefit over a regular database. This is often a stepping stone before onboarding partners into a consortium.
Consortium (Federated)
A fixed group of organisations — say, five banks or a dozen shipping lines — jointly own the network. A consortium agreement defines voting rules, validator rotation, membership changes, and dispute resolution. Most real enterprise networks live here.
Hybrid
A consortium runs the validators, but reads (and sometimes writes) can be opened to a wider ecosystem of clients, regulators, or the public. Think of a carbon credit network where anyone can verify, but only accredited issuers can mint.
BFT Consensus for Enterprise
Permissioned chains don't use energy-hungry Proof of Work. They use Byzantine Fault Tolerant (BFT) consensus algorithms — IBFT and QBFT in Hyperledger Besu, Raft for crash-fault tolerance in Fabric ordering, and Corda's notary model. BFT protocols deliver deterministic finality (no reorgs) as long as fewer than one third of validators are malicious, and scale comfortably to dozens of validators.
On-chain vs Off-chain Governance
On-chain governance encodes rules in smart contracts: voting, upgrades, and parameter changes happen via transactions. Off-chain governance relies on legal agreements, boardroom decisions, and manual coordination. Most enterprise networks combine both: off-chain legal contracts as the backbone, on-chain votes for day-to-day operational decisions.
Exercise & Self-Check
Time to put this module to work. These exercises are open-ended — the goal is to develop the architect's reflex for choosing (or rejecting) a permissioned blockchain.
Exercises
- 1. Match the use case. For each of the following, decide whether you would use a public chain, a permissioned chain, or no blockchain at all: (a) a DeFi lending protocol, (b) hospital patient records, (c) an internal HR database, (d) interbank wholesale settlement, (e) an NFT art marketplace.
- 2. TPS comparison. Look up the latest TPS numbers for Bitcoin, Ethereum L1, an Ethereum L2 (e.g. Arbitrum), Hyperledger Fabric, and Visa. Make a bar chart. Which workloads are each of them realistically suited for?
- 3. Apply the four questions. Take a project you know (work, school, or imaginary) and run it through the four questions from Section 6. Does it actually need a blockchain? Write a short memo arguing yes or no.
- 4. Design a consortium. Imagine five companies in the same supply chain want to share shipment data. Sketch the governance: who validates, how decisions are made, how a new member joins, what happens if one behaves badly.
- 5. Case study. Research one of: IBM Food Trust, TradeLens, Marco Polo, we.trade, or JPM Coin. Write 200 words on why they chose a permissioned chain, what worked, and what didn't.
Self-Check
- Can you explain the difference between a public and a permissioned blockchain to a non-technical manager in under a minute?
- Can you list at least four concrete reasons an enterprise might reject a public chain?
- Do you know three real-world permissioned blockchain use cases and the platforms behind them?
- Can you articulate what a permissioned chain loses compared to Ethereum?
- Can you apply the four-question test to decide whether a project needs a blockchain at all?