Enterprise blockchains: Hyperledger Fabric and Corda

Computer Science and Engineering (B.E./B.Tech) · Blockchain · free study notes for exams, placements and interviews

In short

Enterprise (permissioned) blockchains are distributed ledgers in which every participant is a known, identified legal entity admitted by a membership authority, so consensus can rely on identity and legal contracts instead of mining or staking. Hyperledger Fabric (Linux Foundation, now under LF Decentralized Trust) and R3 Corda are the two dominant designs: Fabric is a general modular ledger with channels and chaincode, while Corda is purpose-built for financial agreements and shares data only with the parties to a transaction. Neither has a native cryptocurrency, both give deterministic finality, and both are examined in university DLT/blockchain electives and in GATE-style objective questions on permissioned ledgers, consensus and CAP trade-offs. In India they underpin the Indian Banks' Blockchain Infrastructure Company (IBBIC) letter-of-credit network on Corda, SEBI-mandated DLT monitoring of debt securities at the depositories, NPCI's Vajra, and MeitY's Vishvasya blockchain-as-a-service stack. Employers who ask about them include Infosys, TCS, Wipro, Tech Mahindra, Accenture, IBM, HCLTech, R3 partners and bank technology teams.

Explained

Where enterprise blockchains sit in the classification

Permissionless / public: anyone may read, write and join consensus (Bitcoin, Ethereum); Sybil resistance by proof-of-work or proof-of-stake; probabilistic finality.
Permissioned / private: write and consensus rights restricted to admitted members; Sybil resistance by identity issuance (a CA), so classical BFT or crash-fault-tolerant consensus suffices.
Consortium (federated): the common enterprise case - several organisations jointly govern, each running its own nodes; Fabric and Corda target this.
Consequences of being permissioned: no mining, no token needed, far higher throughput, deterministic immediate finality, but trust shifts to the governance body and the CA.
Fabric is a shared-ledger-per-channel design; Corda is not a blockchain at all in the strict sense - it has no global chain of blocks, only a network of hash-linked transactions held by those entitled to see them.

Hyperledger Fabric: architecture

Peer: holds the ledger and runs chaincode. Roles: *endorsing peer* (simulates transactions), *committing peer* (validates and writes), *anchor peer* (cross-org gossip), *leader peer* (receives blocks from orderers).
Ledger = two parts: an append-only blockchain log (immutable, file-based) plus the world state - a key-value snapshot in LevelDB (keys only) or CouchDB (JSON documents, supports rich queries and indexes).
Ordering service: orders transactions into blocks and signs them. Raft (etcdraft) is the standard crash-fault-tolerant option; Kafka-based and Solo orderers are obsolete; Fabric v3.x adds a BFT ordering service (SmartBFT) for mutually distrusting orderers.
Membership Service Provider (MSP): maps X.509 certificates issued by Fabric CA (or any CA) to organisations and roles (client, peer, admin, orderer). Identity, not anonymity, is the base layer.
Channel: a private sub-ledger with its own genesis block, members, policies and chaincode - the primary isolation mechanism. Channel configuration itself is updated by signed config transactions.
Chaincode (smart contract): written in Go, Node.js or Java, packaged and run in an isolated container; must be deterministic (no random numbers, no system time, no external HTTP calls).
Gossip protocol spreads blocks peer-to-peer within an organisation and syncs lagging peers.
Fabric Gateway (v2.4+): moves most client logic into the peer, so applications submit through a single gateway peer instead of orchestrating endorsements themselves.

Fabric: the execute-order-validate transaction flow

Propose: client (signed with its MSP identity) sends a transaction proposal to the endorsing peers named by the endorsement policy.
Execute (simulate): each endorser runs the chaincode against its own world state and produces a read-write set (RWSet) - keys read with their versions, keys written with new values - and signs it. No state is changed yet.
Collect: client gathers endorsements and checks they match; mismatched RWSets reveal non-determinism.
Order: client submits the endorsed transaction to the ordering service, which batches it into a block (cut on MaxMessageCount, PreferredMaxBytes or BatchTimeout, whichever hits first) and delivers the block to all channel peers.
Validate: every peer checks (a) endorsement policy satisfaction via the VSCC, and (b) MVCC - that the version of every key in the read set is still current.
Commit: valid transactions update the world state; invalid ones are still written to the block, flagged MVCC_READ_CONFLICT or ENDORSEMENT_POLICY_FAILURE, and emit events to listeners.
Why execute-before-order matters: parallel execution scales, and only nodes in the endorsement policy ever see the contract logic; the cost is MVCC conflicts on hot keys.
Chaincode lifecycle (v2.x): package → install on peers → each org *approves* a definition → *commit* to the channel once the lifecycle policy (usually majority of orgs) is met. Decentralised, unlike v1.x where one admin instantiated it.
Endorsement policies: principal expressions such as AND('OrgA.peer','OrgB.peer'), OR(...), OutOf(2,'A.peer','B.peer','C.peer'); also state-based endorsement (a policy attached to a single key) and private data collection policies.
Private data collections: the actual values are gossiped only to authorised orgs and stored in their transient/private state database; only a hash of the private data goes into the block, so non-members can still verify but not read. Supports purge after N blocks.

R3 Corda: architecture and model

Node: a JVM process with an identity certificate from the network's identity manager (doorman), a vault (its own relational database of states it is party to) and point-to-point AMQP/1.0 messaging over TLS - no broadcast.
States: immutable fact objects consumed and created by transactions - a UTXO model. A transaction has input state references, output states, commands, signers, attachments, and an optional time-window.
Contract: a JVM class with a verify(tx) method that must be deterministic and either throw or return; it decides whether a transaction is *valid*. Validity is a pure function of the transaction and its dependencies.
Flows: the CorDapp's business logic - a resumable, checkpointed state machine that drives the multi-party handshake (collect signatures, notarise, record). Flows are what make Corda a workflow engine as much as a ledger.
Notary service: the only consensus service; it signs a transaction to assert uniqueness - that no input state has been consumed before - giving finality. It can itself be a cluster (Raft/BFT) or a single trusted entity, and a network may have several notaries.
- Non-validating notary: sees only the input state references and the transaction id - better privacy, but a malicious party could try to consume someone else's state.
- Validating notary: verifies the whole transaction and its dependency chain - safer, but sees all the data.
Transaction resolution / backchain: to verify a transaction you recursively fetch and verify its input states' creating transactions. The chain of provenance travels with the data, which is why tear-offs (Merkle-proof sub-transactions, used for oracle signing) and SignedTransaction filtering matter.
Attachments and oracles: zipped files (legal prose, rate tables) referenced by hash; an oracle signs a command containing off-ledger data such as a FIX rate.
Network layers: a *Corda Network* provides identity and notary services; business networks sit on top with their own membership operator. Corda 5 re-architected the node into Kubernetes-based worker clusters with CorDapps packaged as CPK → CPB → CPI; Corda 4.x remains widely deployed.

Comparing the two (and the Ethereum-derived option)

Data visibility: Fabric = everyone on the channel sees every transaction (unless private data collections are used); Corda = only parties and the notary, by design.
Consensus: Fabric separates ordering (Raft/BFT) from validation; Corda has no ordering at all - only per-transaction uniqueness by a notary, so there is no total order of unrelated transactions.
Data model: Fabric = key-value world state (account-style); Corda = UTXO states in a relational vault.
Languages: Fabric = Go/Node/Java chaincode; Corda = Kotlin/Java contracts and flows.
Permissioned Ethereum alternatives: Hyperledger Besu and GoQuorum run EVM bytecode with IBFT/QBFT consensus and private transactions - chosen when teams already know Solidity; they trade Corda's privacy model for EVM compatibility.
Advantages of permissioned ledgers: thousands of transactions per second, no gas fees, instant finality, confidentiality, legal identity and recourse, easy upgrade and GDPR/DPDP-friendly off-chain storage.
Limitations: governance is hard (who runs the notary/orderers?), partial centralisation, no public censorship resistance, interoperability across networks is immature, operations-heavy (CAs, certificate renewal, node upgrades), and network effects fail - several big Corda trade-finance consortia (Marco Polo, Contour) shut down for commercial, not technical, reasons.

Indian practice, law and standards

IBBIC Pvt Ltd - set up in 2021 by a group of Indian banks - runs a domestic letter of credit / trade document network on Corda, so Corda experience is directly hireable in Indian banking IT.
SEBI requires security and covenant monitoring of listed debt securities on a DLT platform hosted by the depositories (NSDL/CDSL), with issuers, debenture trustees, credit rating agencies and auditors as participants.
NPCI Vajra is a permissioned DLT platform for payment clearing and settlement automation; RBI's e-rupee (CBDC) retail pilot uses DLT components. There is no Indian Act specific to DLT; enterprise ledgers run under general law.
MeitY runs the National Blockchain Framework and launched Vishvasya (blockchain-as-a-service), NBFLite (a lighter stack for startups and research) and Praamaanik in 2024; the NIC Centre of Excellence in Blockchain Technology offers government BaaS used for certificates and property-record pilots. State land-record and e-stamping pilots exist in Andhra Pradesh, Telangana and Maharashtra.
Legal validity: electronic records and digital/electronic signatures are recognised under the Information Technology Act, 2000, and electronic records are admissible in evidence under the Bharatiya Sakshya Adhiniyam, 2023 (which replaced the Indian Evidence Act, 1872) with the prescribed certificate - so design ledgers to produce exportable, hash-verifiable records with a signatory who can certify them.
Privacy: under the Digital Personal Data Protection Act, 2023, the Data Fiduciary duties in the DPDP Rules, 2025 - notice, consent, breach intimation and erasure - take effect from 13 May 2027; until then IT Act section 43A and the SPDI Rules, 2011 apply. Because an immutable ledger cannot delete, the standard pattern is to keep personal data off-chain and put only salted hashes or pointers on-chain.
Standards: ISO/TC 307 is the international committee; ISO 22739:2024 is the blockchain and DLT vocabulary standard, and India participates through BIS. Bank deployments must also satisfy RBI's IT governance, outsourcing and cyber-security directions, plus data-localisation requirements for payment data.

Key points

Permissioned ledger - write/read/consensus rights limited to identified members; identity replaces proof-of-work as Sybil defence.
Fabric MSP - maps X.509 certificates to organisations and roles; the root of all Fabric authorisation.
Channel - an isolated ledger with its own members, policies and chaincode; Fabric's main privacy unit.
Chaincode - Fabric smart contract in Go/Node/Java; must be deterministic or endorsements will not match.
Execute-order-validate - Fabric's flow; parallel simulation first, ordering second, MVCC validation last.
Read-write set - the keys and versions read plus values written during simulation; the basis of MVCC validation.
Endorsement policy - which organisations' signatures a transaction needs; checked again at commit by the VSCC.
Ordering service - Raft for crash faults, SmartBFT in Fabric v3 for Byzantine faults; cuts blocks by count, size or timeout.
Private data collection - values gossiped only to authorised orgs, hash on the ledger for verifiability.
World state - LevelDB (key-value) or CouchDB (JSON, rich queries); the blockchain log remains the source of truth.
Corda state - an immutable UTXO fact; transactions consume inputs and create outputs.
Corda contract - deterministic verify() deciding validity; flow - the checkpointed multi-party workflow.
Notary - asserts uniqueness (no double-spend) and gives finality; validating or non-validating.
Need-to-know - Corda sends data only to transaction parties and the notary; there is no global ledger copy.
Backchain resolution - verifying a Corda transaction means verifying its ancestors; tear-offs limit disclosure.
No native token - both ledgers can represent assets but neither requires a cryptocurrency or gas.
Finality - deterministic and immediate in both, unlike probabilistic public-chain confirmation.
India - IBBIC (Corda, trade finance), SEBI DLT for debt securities, NPCI Vajra, MeitY Vishvasya BaaS.

Formulas and examples

Byzantine fault tolerance: n ≥ 3f + 1, i.e. f = ⌊(n − 1)/3⌋ - n = total consensus nodes, f = maximum malicious nodes tolerated
Crash fault tolerance (Raft): n ≥ 2f + 1, quorum q = ⌊n/2⌋ + 1, f = ⌊(n − 1)/2⌋
Endorsement sets satisfying "k of n": C(n, k) = n! / (k!(n − k)!)
Block cut time t = min(BatchTimeout, MaxMessageCount/λ, PreferredMaxBytes/(λ·s)) - λ = arrival rate (tx/s), s = mean transaction size (bytes)
End-to-end latency L = T_endorse + T_order + T_validate + T_commit (seconds); T_order ≈ block cut time + one ordering round trip
Ledger growth per peer = λ_day × s × 365 (bytes/year) - λ_day = transactions per day
Data copies per transaction: public/broadcast = N nodes; Corda = p parties + 1 notary
Message complexity per consensus round: Raft O(n); classical PBFT O(n²)

Example 1 - sizing an ordering service. A consortium of five banks each runs one Raft orderer (n = 5).

Quorum q = ⌊5/2⌋ + 1 = 3 nodes; crash tolerance f = ⌊(5 − 1)/2⌋ = 2 orderers may fail and the channel still orders.
If instead a Byzantine-tolerant orderer is required with f = 2, then n ≥ 3(2) + 1 = 7 orderers.
With n = 4 BFT nodes, f = ⌊3/3⌋ = 1 - so a four-bank BFT network survives only one malicious orderer.

Example 2 - endorsement policy combinations. A channel has 10 member organisations and the policy is OutOf(2, ...) over all ten.

Distinct valid endorsement sets = C(10, 2) = (10 × 9)/2 = 45.
If the policy were OutOf(3, ...): C(10, 3) = (10 × 9 × 8)/6 = 120 sets.
Verification cost at commit for a 3-of-10 transaction = 3 endorsement signatures + 1 client signature + 1 orderer block signature = 5 signature checks per transaction, plus the block header check once per block.

Example 3 - block cutting and latency. BatchTimeout = 2 s, MaxMessageCount = 100, PreferredMaxBytes = 512 KiB, mean transaction size s = 3 KiB, arrival rate λ = 500 tx/s.

By count: 100/500 = 0.20 s. By size: 512/(500 × 3) = 524,288/1,536,000 ≈ 0.34 s. By timeout: 2 s.
The minimum is 0.20 s, so blocks are cut by message count, 5 blocks per second, each of 100 transactions.
If T_endorse = 60 ms (endorsers queried in parallel), ordering round trip 90 ms, validate + commit 80 ms, then L ≈ 60 + (200 + 90) + 80 = 430 ms - well inside the one-second expectation of a trade-finance UI.
Lowering MaxMessageCount to 20 gives blocks every 0.04 s and L ≈ 270 ms, at the cost of more blocks and larger per-block overhead.

Example 4 - ledger storage planning. A letter-of-credit network commits 1,000 transactions per day of 4 KiB each, with four peers per organisation across three organisations (12 peers), each holding the full channel ledger.

Per peer per day = 1,000 × 4,096 = 4,096,000 bytes ≈ 3.91 MiB; per year ≈ 3.91 × 365 ≈ 1,426 MiB ≈ 1.39 GiB.
Across 12 peers ≈ 16.7 GiB per year of replicated raw block data, before CouchDB indexes (typically 1.5-3× the raw state) and before orderer copies.
Moving the 3.5 KiB document payload into a private data collection with only a 64-byte hash on the chain cuts the *public* block growth to roughly 1,000 × 640 B/day ≈ 0.61 MiB/day ≈ 0.22 GiB/year per peer, with the payload held only by the two counterparty organisations.

Example 5 - privacy by construction. A 50-member network processes a bilateral invoice-financing deal.

Broadcast model: all 50 nodes store the transaction - 50 copies, 48 of them unnecessary.
Fabric with a dedicated channel for the two parties: 2 peers + orderers see it; with one shared channel and a private data collection: 50 peers see a hash, 2 hold the data.
Corda: parties p = 2 plus 1 notary = 3 copies; a non-validating notary sees only state references, so only 2 parties ever see the invoice amount.

Feature	Hyperledger Fabric	R3 Corda	Public Ethereum
Access	Permissioned, MSP/X.509	Permissioned, doorman-issued certs	Permissionless
Data model	Key-value world state	UTXO states in a vault	Account/state trie
Smart contract	Chaincode (Go/Node/Java)	Contract + flow (Kotlin/Java)	Solidity on EVM
Consensus	Ordering (Raft/BFT) + endorsement + MVCC	Notary uniqueness + contract validity	PoS, global
Data sharing	All peers on a channel	Need-to-know, point-to-point	Global broadcast
Native token	None	None	ETH, gas
Finality	Immediate, deterministic	Immediate on notarisation	Probabilistic until finalised
Typical throughput	Thousands of tx/s per channel	Hundreds to thousands (notary-bound)	Tens of tx/s

Notary type	Sees	Risk	Use when
Non-validating	Input state refs, tx id, time-window	A party could try to consume a state it does not own (detectable, needs recovery)	Privacy is paramount, parties are legally bound
Validating	Full transaction and backchain	Notary learns the business data	Correctness and dispute-proofing matter more

Where it is used

Banking and trade finance: IBBIC's Corda-based domestic letter-of-credit network; bank-guarantee and invoice-discounting platforms built by Infosys Finacle, TCS Quartz and Tech Mahindra for Indian banks.
Capital markets and regulation: SEBI-mandated DLT monitoring of listed debt securities at NSDL/CDSL; NPCI Vajra for clearing-house automation; RBI CBDC pilot infrastructure.
Government and public records: MeitY's Vishvasya BaaS and the NIC Centre of Excellence in Blockchain Technology for certificate issuance, property records and document verification; state e-stamping and land-record pilots.
Insurance, healthcare and identity: shared claim and KYC registries where competitors must agree on a fact without exposing customer data - private data collections or Corda need-to-know are the enabling features.
Job roles: blockchain developer (chaincode/CorDapp), solution architect, DevOps/SRE for Fabric networks (Kubernetes, Fabric CA, Raft), QA automation, and consulting roles in Infosys, TCS, Wipro, Accenture, IBM, HCLTech and R3 partner firms; interviews lean heavily on Docker, Kubernetes, Go/Java and PKI alongside the ledger itself.
Internal enterprise reconciliation: inter-company settlement between group entities, dealer-financing and loyalty-point ledgers, where a permissioned ledger replaces nightly file reconciliation.

Interview questions

Q: Why does a permissioned blockchain not need proof-of-work? A: Sybil attacks are prevented by certificate-based admission - every node is a known legal entity - so consensus only has to tolerate crash or Byzantine faults among a known set, which Raft or BFT does cheaply.
Q: What is Fabric's execute-order-validate model and why is it used? A: Transactions are simulated by endorsers first, then ordered into blocks, then validated against endorsement policy and MVCC at every peer. It allows parallel execution, non-deterministic-free contract isolation and confidentiality of contract logic, unlike order-execute where every node runs every contract.
Q: When does a Fabric transaction get marked invalid after it is already in a block? A: When the endorsement policy is not satisfied, or when the version of any key in its read set changed between simulation and commit - an MVCC_READ_CONFLICT. It stays in the block for audit but does not change the world state.
Q: How do you avoid MVCC conflicts on a hot key such as a counter? A: Do not keep a single mutable key; write per-transaction delta keys and aggregate on read, or shard the counter, or serialise updates in the application layer.
Q: Channels versus private data collections - when do you use which? A: A channel is a separate ledger for a stable subset of members with its own chaincode; a private data collection keeps confidential fields among a subset of the *same* channel, with only a hash on-chain. Use collections when all parties share the same contract but not the same data.
Q: What exactly does a Corda notary do? A: It signs a transaction to certify that none of its input states has already been consumed, providing uniqueness consensus and finality; it does not order unrelated transactions and does not maintain a global chain.
Q: Difference between a validating and non-validating notary? A: A validating notary verifies the full transaction and its backchain (safer but sees the data); a non-validating one sees only input references and the transaction id (private but relies on legal and contractual recourse against a party that tries to consume another's state).
Q: Why is there no global ledger in Corda? A: Corda shares transactions only with the parties involved and the notary, so each node's vault holds just the facts it is party to - privacy is structural, not an add-on.
Q: Why must chaincode and Corda contracts be deterministic? A: Multiple nodes execute or re-verify the same code; any dependence on time, randomness, map iteration order or network calls produces different results, so endorsements will not match or verification will fail on replay.
Q: Where would you store a scanned invoice or personal data in such a network? A: Off-chain in a document store or private data collection, with only a salted hash and metadata on the ledger - needed both for block size and because an immutable ledger cannot honour an erasure request under the DPDP regime.
Q: Fabric or Corda for a multi-bank trade-finance platform, and why? A: Corda if deals are bilateral or small-group with strict need-to-know and legal-prose attachments; Fabric if the consortium wants a common shared state, rich queries and a broader non-financial asset model. Both give identity and immediate finality.
Q: What replaced the old Fabric instantiate step? A: The v2.x decentralised chaincode lifecycle - each organisation approves a chaincode definition and it is committed to the channel once the lifecycle policy is met, so no single admin can impose contract code.

Common mistakes

Saying "Fabric uses PoW/PoS" or "Corda mines blocks" - neither has mining, a native token or probabilistic finality.
Treating the ordering service as the validator: ordering is blind to transaction validity; the endorsement and MVCC checks happen at every peer afterwards.
Writing non-deterministic chaincode (timestamps, rand, external API calls) and then being puzzled by endorsement mismatches.
Using GetState inside a loop to build a running total, creating a huge read set and guaranteed MVCC conflicts under load.
Assuming a private data collection hides the *existence* of a transaction - the hash and the transaction are on the channel; only the values are restricted.
Confusing Fabric's channel-level privacy with Corda's per-transaction privacy, or claiming Corda has a chain of blocks.
Putting personal data or full documents on-chain, then discovering the immutability conflicts with erasure obligations and inflates every peer's storage.
Quoting public-chain throughput limits or gas costs in a permissioned design, and ignoring the real operational burden - certificate expiry, CA key custody, orderer quorum loss and version upgrades.