Separate a record, a rule and an agreement
By the end, explain the diagram in your own words, solve the case and justify the correction.
Prerequisites : None. Start here.
Level 1 · Beginner →Reading path · 1 / 12 · Beginner
A shared ledger needs both validity rules and a way to choose a history.
The essentials
A blockchain is a shared record whose updates are grouped into blocks linked by cryptographic fingerprints. Nodes independently check these updates against common rules. The useful innovation is not copying a database: it is allowing participants who do not fully trust one another to agree on an ordered history.
How it works
Suppose Alice sends the same funds to Bob and to Carol. Both instructions may look plausible separately. The network must accept one history and reject the conflicting spend. This is the double-spending problem. Signatures establish authority to spend; consensus determines the accepted order.
What to watch
Public networks generally let anyone verify the record. Permissioned networks restrict access or participation. Neither a token nor a chain of hashes alone guarantees decentralisation, censorship resistance or trustworthy input data. Ask who can validate, who can change the rules, and what happens when participants disagree.
Understand the details
A ledger records changes of ownership or claims. Replication means several computers keep copies; it does not mean those copies always agree immediately. A transaction can reach one computer before another. Each node first applies validity rules locally, then follows the consensus mechanism to select an accepted history. The state is the result of replaying that history, not a separate promise made by a website.
Boundaries and common mistakes
Permission to read, submit transactions and validate can differ. A public ledger is not necessarily private, and a permissioned ledger is not necessarily inaccurate. Ask which participants can reject a record, how disagreements are resolved, and who can change the rules. A shared database may be simpler when one trusted organization already controls all participants.
The mechanism at a glance
- Proposed payment
- Local rule checks
- History selected
- Copies converge
Apply the lesson to a case
Three shops keep a shared voucher ledger. Shop A sees a payment before shops B and C. Its screen says pending. Draw three copies and record when each receives, validates and accepts the payment. The temporary disagreement concerns visibility; it is not yet evidence of fraud.
They would not establish whether the voucher was still spendable. Add a validity check before acceptance, and a rule for conflicting histories. Your diagram should distinguish receipt from acceptance and show that three copies of a mistake do not make it valid.
Two competing payments
Alice has one spendable output worth 10 units. She signs one payment of 8 units to Bob and another of 8 units to Carol, each using that same output. A signature proves authority over an input; it does not create a second input. Once one transaction consumes the output in the accepted history, the other conflicts with it.
A node therefore checks two different things: whether the spending conditions are satisfied and whether the input remains unspent in the history being validated. Copying records or calculating hashes alone does not resolve competing histories. This distinction explains why validation and consensus are both necessary.
Check your understanding
Yes, when both spend the same output. Valid signatures do not prevent a double-spend attempt.
Terms in this lesson
- Hash
- A fixed-length fingerprint computed from data by a hash function. It checks consistency, not truth.
Prepare a correction note
Describe the passage and the proposed correction. This creates a local note for you to share; it sends nothing. Do not include personal or confidential information.