Blockchain and Distributed Ledger Fundamentals
Domain overview
This domain tests the technical vocabulary that underpins legal and compliance analysis: how a distributed ledger records transactions, how nodes reach consensus, and where finality, privacy, and control actually sit. Expect questions that ask you to map a business use case to a ledger type, identify trust assumptions, and spot when a claimed benefit is not delivered by the architecture.
Core concepts
- DLT and blockchain: a replicated ledger maintained by multiple participants; a blockchain adds cryptographic linking of blocks. Not every DLT uses blocks or chains.
- Keys and addresses: public/private key pairs control signing; an address is not a legal identity. Custody depends on who controls the private key.
- Consensus: PoW and PoS are public-network mechanisms; permissioned networks often use BFT-style voting or crash-fault-tolerant ordering. Finality can be probabilistic (more confirmations) or deterministic (protocol finality).
- Data boundaries: on-chain data is replicated and hard to erase; sensitive documents usually stay off-chain with hashes or references on-chain.
Worked example
A bank consortium wants a trade-finance ledger visible only to participating banks and regulators. A public PoW chain is proposed because it is trustless. The better answer is a permissioned ledger with known validators and deterministic finality: the parties already have contractual trust and legal accountability, and they need privacy and throughput. The exam reasoning should name the trust model, validator set, data visibility, and finality requirement, not just the word blockchain.
Traps that cost marks
Do not equate blockchain with Bitcoin or with immutability in every layer. Public keys are pseudonymous, not anonymous. A hash on-chain does not make off-chain data trustworthy. Confusing probabilistic finality with settlement finality costs marks.