How unit 5 is examined
This unit covers Hyperledger Fabric (architecture, identities, policies, channels, validation), chaincode in Fabric, smart contracts in Ethereum, and Ripple with Corda; no past questions are recorded, so all four topics are unasked and should be learnt as short definition-plus-points answers.
Hyperledger Fabric: architecture, identities and policies, membership and access control, channels, transaction validation
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>
Definition. <mark>Hyperledger Fabric is an open-source, permissioned enterprise blockchain platform, hosted by the Linux Foundation, in which only identified and authorised members take part and every transaction follows an execute-order-validate flow.</mark>
Diagram.
<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u5-01" viewBox="0 0 596 166" width="596" height="166" role="img" aria-label="Fabric flow. Cl = client, En = endorsing peers, Or = ordering service, Co = committing peers, Le = ledger"><style>#dsfig-u5-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u5-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u5-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u5-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u5-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u5-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u5-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u5-01 .t{fill:#16181D;font-weight:500}#dsfig-u5-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u5-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u5-01 .dot{fill:#16181D}#dsfig-u5-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u5-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u5-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u5-01 .ah{fill:#454C5A}#dsfig-u5-01 .ah.hi{fill:#2340B8}#dsfig-u5-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u5-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u5-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u5-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u5-01 .e{stroke:#B1B7C3}html.dark #dsfig-u5-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u5-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u5-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u5-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u5-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u5-01 .t{fill:#E6E8ED}html.dark #dsfig-u5-01 .t.inv{fill:#0F1115}html.dark #dsfig-u5-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u5-01 .dot{fill:#E6E8ED}html.dark #dsfig-u5-01 .ann{fill:#8FA3FF}html.dark #dsfig-u5-01 .lbl{fill:#858D9C}html.dark #dsfig-u5-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u5-01 .ah{fill:#B1B7C3}html.dark #dsfig-u5-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u5-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u5-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u5-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah5" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh5" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M58.7,122.5 Q125.8,110.1 165.1,56.9" marker-end="url(#ah5)"/><path class="e" d="M158.9,43.5 Q91.8,55.9 52.5,109.1" marker-end="url(#ah5)"/><path class="e" d="M59,126 L294.2,126" marker-end="url(#ah5)"/><path class="e" d="M334.2,126 L431.8,126" marker-end="url(#ah5)"/><path class="e" d="M471.8,126 L535,126" marker-end="url(#ah5)"/><g class="wl"><rect x="88.1" y="90.9" width="61.5" height="18" rx="9"/><text class="t" x="118.8" y="99.9" dy=".35em" text-anchor="middle">propose</text></g><g class="wl"><rect x="68" y="57.1" width="61.5" height="18" rx="9"/><text class="t" x="98.8" y="66.1" dy=".35em" text-anchor="middle">endorse</text></g><g class="wl"><rect x="150.5" y="117" width="54.3" height="18" rx="9"/><text class="t" x="177.6" y="126" dy=".35em" text-anchor="middle">submit</text></g><g class="wl"><rect x="360.5" y="117" width="47.1" height="18" rx="9"/><text class="t" x="384" y="126" dy=".35em" text-anchor="middle">block</text></g><g class="wl"><rect x="477.3" y="117" width="54.3" height="18" rx="9"/><text class="t" x="504.4" y="126" dy=".35em" text-anchor="middle">commit</text></g><circle class="n" cx="40" cy="126" r="18"/><text class="t" x="40" y="126" dy=".35em" text-anchor="middle">Cl</text><circle class="n" cx="177.6" cy="40" r="18"/><text class="t" x="177.6" y="40" dy=".35em" text-anchor="middle">En</text><circle class="n" cx="315.2" cy="126" r="18"/><text class="t" x="315.2" y="126" dy=".35em" text-anchor="middle">Or</text><circle class="n" cx="452.8" cy="126" r="18"/><text class="t" x="452.8" y="126" dy=".35em" text-anchor="middle">Co</text><circle class="n" cx="556" cy="126" r="18"/><text class="t" x="556" y="126" dy=".35em" text-anchor="middle">Le</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Fabric flow. Cl = client, En = endorsing peers, Or = ordering service, Co = committing peers, Le = ledger</figcaption></figure>
Key points.
- The architecture has clients that propose transactions, endorsing peers that simulate chaincode and sign the result, an ordering service that sequences transactions into blocks, committing peers that validate and store blocks, and a Membership Service Provider (MSP).
- Every participant has an identity that is an X.509 digital certificate issued by a Certificate Authority (CA), so each action can be traced to a known organisation.
- Policies are rules that say who may do what, and the endorsement policy states which organisations must sign a transaction, for example "2 of 3 organisations" or "Org1 AND Org2".
- Membership and access control are enforced by the MSP, which turns certificates into roles (admin, member, peer, client), and by channel access control lists (ACLs) that decide who can invoke chaincode or read the ledger.
- A channel is a private sub-network with its own ledger, its own members and its own chaincode, so data on one channel is hidden from organisations that are not on it.
- Transaction validation happens at the committing peer: it checks that the endorsement policy is satisfied and that the versions in the read-write set still match the world state (MVCC check); failed transactions stay in the block marked invalid but change no state.
- The ordering service (Raft in current versions) never executes chaincode, which is why Fabric separates ordering from execution and scales better than order-execute chains.
Answer frame. Open with the definition; draw the flow diagram; develop points 1-6 in that order; close with the line that Fabric gives privacy through channels and trust through policies.
Pitfall: Do not say Fabric mines blocks or uses a cryptocurrency; it is permissioned and has no mining.
Writing smart contract using Hyperledger Fabric
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>
Definition. <mark>In Fabric a smart contract is called chaincode: a program, written in Go, Java or Node.js, that runs in a container on the peers and reads or writes the ledger world state through the shim (stub) API.</mark>
Steps.
Step 1: Write the chaincode with functions such as CreateAsset, ReadAsset, UpdateAsset, TransferAsset.
Step 2: Package it and install it on each organisation's peers.
Step 3: Approve the chaincode definition (name, version, endorsement policy) for each organisation.
Step 4: Commit the definition to the channel.
Step 5: Invoke it from a client: endorse, order, validate, commit.
Key points.
- Chaincode stores data as key-value pairs in the world state using
PutState(key, value)and reads them withGetState(key), while the blockchain itself keeps the full history. - Each function receives a context or stub that gives the transaction ID, the caller's identity and the ledger access calls.
- Chaincode must be deterministic, so it must not use random numbers, the system time or outside web calls, otherwise different peers would produce different results.
- Fabric uses the lifecycle install, approve, commit, so the organisations agree on the same chaincode and endorsement policy before it becomes active.
- A query only reads the state and is not ordered, whereas an invoke changes the state and passes through ordering and validation.
Example. An asset-transfer contract stores each asset as asset1 -> {owner: Tom, value: 300}; TransferAsset reads asset1, sets owner to Anil and writes it back with PutState.
Answer frame. Open with the definition of chaincode; list the five lifecycle steps; develop points 1-5; close with one asset-transfer example.
Writing smart contract using Ethereum
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>
Definition. <mark>An Ethereum smart contract is a program written in Solidity, compiled to EVM bytecode and deployed at an address on the Ethereum blockchain, where it executes automatically whenever a transaction calls it.</mark>
Steps.
Step 1: Write the contract in Solidity (Remix IDE, Truffle or Hardhat).
Step 2: Compile it to bytecode and the ABI (application binary interface).
Step 3: Test it on a local or test network such as Sepolia.
Step 4: Deploy it with a transaction paying gas from a wallet such as MetaMask.
Step 5: Call its functions from a DApp front end using web3.js or ethers.js.
Key points.
- A contract contains state variables, functions, events, modifiers and a constructor, and a contract behaves like a class whose object lives on the chain.
- Every state-changing call costs gas, paid in ether, and a transaction that runs out of gas is reverted, which stops infinite loops.
- Reading a variable with a
viewfunction is free, while writing to storage costs gas. - Deployed code is immutable, so bugs cannot be patched, which makes testing and auditing essential; the DAO reentrancy attack is the classic example.
- A DApp is a web front end plus the contract as the back end, and it talks to the contract through its address and ABI.
contract Store {
uint public value; // state variable
function set(uint v) public { value = v; } // costs gas
}
Answer frame. Open with the definition; list the five steps; develop points 1-5; close with the note that immutability demands testing before deployment.
Overview of Ripple and Corda
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>
Definition. <mark>Ripple is a real-time gross settlement and cross-border payment network built on the XRP Ledger, whereas Corda is an open-source permissioned distributed ledger platform from R3 designed for regulated financial institutions.</mark>
Key points.
- Ripple settles international payments in a few seconds at very low cost, without mining, using a consensus protocol among trusted validators.
- Ripple's native token XRP acts as a bridge currency between two different currencies, which removes the need for pre-funded accounts in each country.
- Corda shares data only between the parties to a deal and not with the whole network, so privacy is preserved.
- Corda records facts as states, changes them through transactions that consume old states and create new ones, and binds them to contract code and legal prose.
- A notary service in Corda checks that an input state is not spent twice, which prevents double spending.
- Corda has no built-in cryptocurrency and no global blockchain, unlike Ripple which has XRP.
| Feature | Ripple | Corda |
|---|---|---|
| Purpose | Fast cross-border payments | Financial agreements between institutions |
| Data sharing | Public ledger | Only parties involved |
| Token | XRP | None |
| Double-spend protection | Validator consensus | Notary |
| Access | Validator list | Permissioned |
Answer frame. Open with the two definitions; give the comparison table; close with the line that Ripple is for payments and Corda for private agreements.
Last-minute revision
- Fabric is permissioned and follows execute-order-validate.
- The MSP and CA give identities as X.509 certificates.
- A channel is a private ledger with its own members and chaincode.
- The endorsement policy is checked at validation time along with the MVCC version check.
- Invalid Fabric transactions stay in the block but change no state.
- Fabric chaincode is written in Go, Java or Node.js and uses
PutStateandGetState. - Chaincode lifecycle is package, install, approve, commit, invoke.
- Ethereum contracts are written in Solidity and run on the EVM.
- Gas is paid in ether and a transaction that runs out of gas is reverted.
- Deployed Ethereum code is immutable, so test on a testnet first.
- Ripple uses XRP and validators for cross-border payments.
- Corda shares data only between parties and uses a notary against double spending.
Memory hooks
- Fabric flow: Endorse, Order, Validate (EOV).
- Fabric privacy comes from channels; Corda privacy comes from need-to-know sharing.
- Solidity belongs to Ethereum and chaincode belongs to Fabric.
- Ripple is for payments and Corda is for deals.
- Chaincode lifecycle: Install, Approve, Commit (IAC).
Coverage checklist
- Hyperledger Fabric- Architecture, Identities and Policies, Membership and Access Control, Channels, Transaction Validation: covered; no past questions.
- Writing smart contract using Hyperledger Fabric: covered; no past questions.
- Writing smart contract using Ethereum: covered; no past questions.
- Overview of Ripple and Corda: covered; no past questions.