FOLLOW THE MECHANISM
- 1Rules
Define valid state transitions.
- 2History
Order transactions into linked blocks.
- 3Consensus
Choose an accepted valid history.
- 4State
Compute the balances and permissions that follow.
A conceptual sequence. Real implementations can add steps, intermediaries, and conditions.
History and state answer different questions
History records accepted transactions and their ordering. State describes the result relevant now: unspent outputs, account balances, contract storage or other protocol-specific records. A node can apply valid transactions to an earlier state to reconstruct a later one. The blockchain connects those transitions into a history that participants can inspect. An asset’s current owner and the route by which it arrived are related but distinct questions.
Agreement needs more than replication
Copying a database to many computers does not explain how those computers resolve conflicting updates. A cryptocurrency network must reject double-spends and choose between competing valid branches despite delays and adversarial behavior. Proof of work and proof of stake provide different resource-based mechanisms for that coordination. Their security assumptions include how much influence an attacker can acquire and how honestly connected participants behave.
Immutability is a conditional property
Changing an old record changes later commitments. To persuade other nodes to accept a replacement history, an attacker must also satisfy or defeat the network’s consensus conditions. That can be economically difficult without being a magical impossibility. Software upgrades and social coordination are another layer: communities can disagree about which rules to run. “Immutable” is best understood with explicit protocol, resource and governance assumptions.
The ledger cannot inspect the outside world
A chain can consistently record that a contract received an oracle price or that a token moved between addresses. It cannot independently verify a warehouse inventory, a legal ownership promise or whether a person intended a payment. Those claims require external evidence and institutions. This boundary explains why putting a claim onchain does not automatically remove the issuer, custodian or data supplier that makes it meaningful.
MAKE IT CONCRETE
A reliable record of an unreliable claim
An illustrative warehouse token claims to represent one stored object. A blockchain can prevent the same token from being transferred twice in the accepted state. If the warehouse never held the object, the ledger can still record every token transfer correctly. Reliable digital bookkeeping and reliable physical backing are separate requirements.
FAILURE PATHS & COMMON MISREADINGS
Where the model can break
- A distributed ledger does not guarantee decentralized control of every application.
- Onchain transparency cannot reveal every offchain obligation.
KEEP EXPLORING