Charta is on Google Play: practise on the go. Get the app
Charta

Contrast the available models and methods for giving a ledger sharedness, programmability and trust, and set out when trust can break down in each.

FRM® Part II · Current Issues in Financial Markets · Tokenization and Financial Market Inefficiencies · FRM2.CI.7.e

The idea

A ledger needs three things: sharedness (many parties hold or see the same record), programmability (rules that execute automatically) and trust (confidence that the record is correct). There are several ways to supply them. A centralized ledger has one operator who keeps the record and runs the code. Trust rests on the operator and breaks if it fails, errs or is hacked. A permissioned distributed ledger uses known validators and a consensus rule. Classical Byzantine fault tolerant protocols need n ≥ 3f + 1 validators to tolerate f faulty ones. Trust breaks if too many collude or governance is captured. A permissionless blockchain lets anyone validate and relies on cryptography and economic incentives. Trust breaks if an attacker controls a majority of work or stake. Smart contracts supply programmability, and they fail through code bugs or manipulated oracle inputs even when consensus works.

Formulas

Validators needed for Byzantine fault tolerance

minimum validators = 3f + 1

f
the number of faulty or colluding validators to be tolerated

Classical BFT protocols. Beyond one third faulty, the network can stall or be manipulated; 10 validators tolerate 3.

A practice question

From the question bank, with the reason each wrong option is wrong.

On a permissionless blockchain, what is the primary basis of trust in the ledger?

  1. Cryptography plus consensus incentives that make attacking the record costly. - correct
  2. Legal vetting of each validator's identity by a regulator before it may validate.Why not: Describes a permissioned model; permissionless validators need no vetting.
  3. A single trusted operator who keeps the master copy and corrects errors.Why not: Describes a centralised ledger, not a distributed permissionless one.
  4. A government guarantee that covers losses from invalid transactions.Why not: No such guarantee underlies a permissionless chain; trust comes from the protocol design.

Because anyone can validate, trust cannot rest on identity. It rests on cryptographic signatures and hashing plus incentives (work or stake) that make rewriting history too costly.

A harder one

A consortium of 10 known institutions runs a permissioned ledger using a Byzantine fault tolerant protocol that requires n of at least 3f + 1 validators to tolerate f faulty or colluding ones. What is the largest number of faulty validators it can tolerate?

  1. 2Why not: Uses n of at least 4f, wrongly requiring a larger fraction of honest validators.
  2. 3 - correct
  3. 4Why not: Uses a simple majority rule (fewer than half), ignoring the one-third threshold for Byzantine faults.
  4. 5Why not: Allows up to half of the validators to be faulty, which exceeds the Byzantine one-third limit.

Need 10 >= 3f + 1, so f <= 3. At most 3 faulty or colluding validators can be tolerated. Beyond one third, the network can stall or be manipulated.

The hardest tier

Regulated banks want a ledger for tokenized deposits that avoids dependence on a single operator, needs known participants and has legal accountability. Which choice and residual trust risk is most accurate?

  1. A permissioned ledger; trust still depends on governance and a bound on validator collusion. - correct
  2. A permissionless public chain, because anonymous validators eliminate collusion risk.Why not: Anonymity does not eliminate collusion or stake concentration, and it conflicts with accountability.
  3. A centralised ledger run by the largest bank, because consensus then removes the need for trust.Why not: A single operator reintroduces the single point of failure and does not use consensus at all.
  4. A permissioned ledger, because known validators make collusion impossible.Why not: Known identity deters but cannot rule out collusion or governance capture.

Known, accountable participants point to a permissioned design, which removes single-operator dependence. It still relies on governance and a bound on collusion or failure, such as the one-third BFT limit.

In the app: 6 practice questions on this outcome, spaced review that brings it back before you forget it.

Start free →

More in Tokenization and Financial Market Inefficiencies