My progress
Menu

Blockchain and Trust Infrastructure Engineer · Focus area 2: Distributed ledgers

BC6: Choosing a ledger: public, permissioned, or an ordinary database

Goal: decide honestly whether a problem needs a blockchain at all, compare public chains and layer 2 networks with permissioned ledgers such as Hyperledger Fabric, plan for the fact that records are hard to change, and weigh the costs and governance of running a shared ledger.

You'll need: BC4, BC5, Module 57 (Transactions and Indexes), Module 79 (Privacy and Data Protection), Module 94 (Distributed Systems), and the SakhiKosh practice kit (README.md, capstone/design-notes-template.md).

Where this is used: every blockchain project starts with this choice, and many good projects end with "use a database". Supply chains, trade finance, land records, certificates and payments have all been tried both ways.

How it differs: in ordinary software, choosing a database is a technical detail. Here, the choice decides who controls the record, who can see it, what it costs, and whether mistakes can be fixed, so it's a decision for the people involved, not just the engineers.

Time: reading about 3 hours · practice (the Try it tasks) about 3 hours · assignment about 4 hours.

Lessons

  1. 1Do you need a blockchain?Reading 15–25 minutes, plus practice✓
  2. 2Public chains and layer 2 networksReading 15–25 minutes, plus practice✓
  3. 3Permissioned ledgers: Hyperledger Fabric and othersReading 15–25 minutes, plus practice✓
  4. 4When records can't simply be changedReading 15–25 minutes, plus practice✓
  5. 5Costs, governance and hybrid designsReading 15–25 minutes, plus practice✓

🛠️Assignment: Choosing SakhiKosh's ledger

  1. Apply the four questions from Lesson 1 to SakhiKosh, at group level and at federation level.
  2. Compare a database, a permissioned ledger, a public network or layer 2 network, and a hybrid in a table: trust, privacy, cost, effort and data rights.
  3. Recommend one, and say what would change your mind.
  4. Write how corrections and members' data rights would work in your choice.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How would you decide whether, and which, shared ledger to use?

Show a good answer

A good answer mentions: asking whether several distrustful parties write a shared record that outsiders must check, and using a database otherwise; middle paths such as hash-chained logs and anchoring; public chains and layer 2 networks for open verification with fees and public data; permissioned ledgers such as Fabric with identities, channels, chaincode and endorsement policies; corrections instead of edits and personal data kept off-chain; and running costs, governance, exit plans and hybrid designs.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. One hospital wants a blockchain for its own patients' appointment records. What's the best advice?

Why each option is right or wrong

  • “Use a public chain, so that every appointment can be checked by anyone, from anywhere, at any time” (Incorrect): Health data must not be public.
  • “Use a permissioned ledger with the hospital as the only member” (Incorrect): A one-member ledger is a slow database.
  • “Use a layer 2 network to keep fees low” (Incorrect): Fees aren't the question; the need is.
  • “Use a database with access controls and audit logs; one trusted operator writes it” is correct.

    Nothing here needs several distrustful writers.

    • Plus: signed exports if others need proof.

📖 Revise: Lesson 1: Do you need a blockchain?

Question ID sp-blockchain-06-q1 · Report a mistake in this question
2. A team says "we need a blockchain strategy, so let's find a use for it". What's the problem?

Why each option is right or wrong

  • “Blockchains can only be used for payments” (Incorrect): They have other uses.
  • “Strategies should be written only after the code is finished, so they match what was actually built” (Incorrect): Order isn't the point.
  • “The team should choose the cheapest chain first” (Incorrect): Cost comes after need.
  • “It starts from the technology instead of a trust problem that needs it” is correct.

    Projects built this way often cost more and deliver less.

    • Start with: who writes, who distrusts whom.

📖 Revise: Lesson 1: Do you need a blockchain?

Question ID sp-blockchain-06-q2 · Report a mistake in this question
3. A university wants graduates' degrees checkable by anyone for decades, while graduates keep their privacy. Which design fits best?

Why each option is right or wrong

  • “Full names and degrees in a public contract, so anyone can search them” (Incorrect): They can't be corrected or removed.
  • “A private database that employers must email each time they want to check a graduate's degree” (Incorrect): That works, but outsiders can't check alone.
  • “A permissioned ledger that only the university can read and write” (Incorrect): Outsiders can't check it.
  • “A yearly Merkle root on a public chain, with each graduate holding their own proof” is correct.

    Anyone can check a proof; no names are public.

    • Like: BC1's inclusion proofs.

📖 Revise: Lesson 2: Public chains and layer 2 networks

Question ID sp-blockchain-06-q3 · Report a mistake in this question
4. A project plans fees for its public-chain app using today's quiet-period prices. What's the risk?

Why each option is right or wrong

  • “Fees go down over time on every network, so the budget is too high” (Incorrect): They change both ways.
  • “Public chains charge one fixed fee per app per year” (Incorrect): Fees are per transaction.
  • “Fees are paid by the network, not users” (Incorrect): Senders pay.
  • “Fees can rise sharply when the network is busy, breaking the budget” is correct.

    Plan for busy periods, or consider a layer 2 network.

    • Remember: prices change with demand.

📖 Revise: Lesson 2: Public chains and layer 2 networks

Question ID sp-blockchain-06-q4 · Report a mistake in this question
5. Three federations share a Fabric ledger. Which setting stops one federation writing a loan alone?

Why each option is right or wrong

  • “A single channel that's shared by all three of the federations and nobody else” (Incorrect): Channels decide who shares, not who must approve.
  • “A private data collection for each federation” (Incorrect): That's for privacy.
  • “Writing the chaincode in Go instead of Java” (Incorrect): The language doesn't matter.
  • “An endorsement policy requiring two of the three federations” is correct.

    Each new loan needs approval from at least two.

    • Also: each runs its own peer.

📖 Revise: Lesson 3: Permissioned ledgers: Hyperledger Fabric and others

Question ID sp-blockchain-06-q5 · Report a mistake in this question
6. In a "shared" permissioned ledger, one company runs every peer. What's wrong?

Why each option is right or wrong

  • “Nothing, since permissioned ledgers are run by one company by design” (Incorrect): Then it's not shared.
  • “The ledger will be too slow for the members' everyday needs” (Incorrect): Speed isn't the issue.
  • “Fabric can't run more than one peer per company” (Incorrect): It can.
  • “Members must trust that company completely, as with a database” is correct.

    Each member should run its own peer.

    • Check: who controls the endorsers and orderers.

📖 Revise: Lesson 3: Permissioned ledgers: Hyperledger Fabric and others

Question ID sp-blockchain-06-q6 · Report a mistake in this question
7. A member asks to have their personal details removed from a project. The details are in a public contract's events. What's true?

Why each option is right or wrong

  • “The project can delete the events with an admin key” (Incorrect): Events can't be deleted.
  • “The details vanish after a year, so there's no problem” (Incorrect): Chain data stays.
  • “Encrypting the events now hides the old ones too” (Incorrect): Old data stays as it was.
  • “They can't be removed from the chain, which is why personal data should stay off it” is correct.

    Keep details off-chain; put only hashes or IDs on-chain.

    • Laws: such as the DPDP Act and GDPR.

📖 Revise: Lesson 4: When records can't simply be changed

Question ID sp-blockchain-06-q7 · Report a mistake in this question
8. A deposit was recorded for the wrong member on the ledger. What's the right way to fix it?

Why each option is right or wrong

  • “Ask the node operators to edit the old block” (Incorrect): Blocks aren't edited.
  • “Delete the contract and start a new one without history” (Incorrect): That loses everyone's history.
  • “Leave it as it is, since a ledger can't hold any kind of correction once an entry is made” (Incorrect): They can, as new entries.
  • “Add an approved correcting entry, keeping both in the history” is correct.

    Balances become right and the reason is visible.

    • Approval: the group's threshold.

📖 Revise: Lesson 4: When records can't simply be changed

Question ID sp-blockchain-06-q8 · Report a mistake in this question
9. After two years, two of four societies stop running their ledger nodes. What would have helped most?

Why each option is right or wrong

  • “A faster consensus protocol that works with fewer nodes” (Incorrect): The problem is people, not speed.
  • “Switching to a public chain without asking the members” (Incorrect): That's a decision for the members.
  • “Paying for bigger servers for the two remaining societies” (Incorrect): Size doesn't share control.
  • “A written charter with duties for each member and a plan for members leaving” is correct.

    Governance keeps a shared ledger shared.

    • Or: move to a simpler design.

📖 Revise: Lesson 5: Costs, governance and hybrid designs

Question ID sp-blockchain-06-q9 · Report a mistake in this question
10. A group wants day-to-day records to be private and easy to correct, but tamper-evident to outsiders. What design fits?

Why each option is right or wrong

  • “Everything on a public chain, with corrections as new entries” (Incorrect): That makes daily records public.
  • “A spreadsheet that's emailed every month to each member and to any outsider who asks for a copy” (Incorrect): It isn't tamper-evident.
  • “A permissioned ledger with no outsiders able to check anything” (Incorrect): Outsiders can't check it.
  • “A database for daily work, with a monthly Merkle root anchored to a public chain” is correct.

    Private daily work, with public tamper evidence.

    • Name: a hybrid design.

📖 Revise: Lesson 5: Costs, governance and hybrid designs

Question ID sp-blockchain-06-q10 · Report a mistake in this question

ProLearners Assist