Awarded once after a correct answer.
Separate a record, a rule and an agreement
Start here. No prior knowledge needed.
Find your bearings · Step 1 / 6
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
- 01Proposed payment
- 02Local rule checks
- 03History selected
- 04Copies converge
Read these as connected concepts, not necessarily consecutive steps.
Read the explanation
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.
Put the mechanism into context
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.
Apply it in the workshop →What this mechanism does not guarantee
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 distinction that changes the analysis
A shop can receive a payment request before checking whether the voucher was already spent. Copying that request to three shops increases visibility, not validity. Record the validation result separately from the arrival time.
Explain it yourself
Revisit the case above. Name what is established, what remains to be checked and the evidence needed to conclude. A strong answer addresses both sides of the diagram.
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.