Blockchain
A blockchain is a replicated ledger and state-transition system whose participants use a consensus protocol to agree on an ordered history.
Category: Money and assetsCircle category cue
System record
Start with the economic purpose, participants, resources, and entitlements before studying implementation detail.
Why it exists
A blockchain lets parties who do not share one operator maintain and verify a common programmable record of assets, claims, and actions.
Traditional-finance analogy
Shared settlement ledger is the closest comparison recorded for this concept.
Where the analogy stops
- A public blockchain can accept independently submitted transactions and replicate execution across many operators instead of relying on one institution's books.
- Consensus, validator incentives, software rules, and chain finality replace—but do not eliminate—operational, governance, and legal trust assumptions.
Main actors
- ActorTransaction sender
- ActorNode operator
- ActorValidator or consensus participant
- ActorApplication and contract developer
Assets and claims
Assets — controlled or transformed resources
Assets are resources the mechanism moves, holds, values, or transforms.
- AssetNative fee and settlement asset
- AssetToken balances recorded in shared state
Claims — entitlements and corresponding dependencies
Claims are rights to value, repayment, redemption, control, or another party's performance; each depends on an obligation or system that must honor it.
- ClaimProtocol-recorded balance or entitlement
- ClaimTransaction receipt and state commitment as execution evidence
A blockchain is a shared state machine: independent computers apply agreed rules to an ordered history and converge on the state that applications read.
Why it exists
Section titled “Why it exists”Financial systems need a record of who controls assets, which claims exist, and which actions changed those positions. A blockchain makes that record replicable and independently checkable without assigning one organization as the sole bookkeeper. It does not remove trust. Trust moves into consensus, validator incentives, client software, governance, cryptography, and the rule used to decide when history is final.
Traditional-finance analogy
Section titled “Traditional-finance analogy”A shared settlement ledger is a useful starting point. Both record positions and accepted state changes. The analogy stops where a public blockchain lets unrelated parties submit transactions, lets programs hold and transform state, and asks many operators to reproduce the result. Legal title, customer support, privacy, and reversal rights do not arise merely because a balance is on-chain.
Actors, assets, and claims
Section titled “Actors, assets, and claims”| Role or object | What it does | Boundary to inspect |
|---|---|---|
| Transaction sender | Requests a state change | Authorization and fee budget |
| Node | Validates and relays data | Client version and network view |
| Validator or consensus participant | Proposes or attests to ordered history | Consensus power, incentives, and penalties |
| Native asset | Pays fees and may secure consensus | Issuance and value are protocol-specific |
| Token balance or entitlement | Lives in application state | Its economic issuer and redemption rules may sit elsewhere |
| Receipt or state commitment | Supplies execution evidence | Evidence is not automatically a financial guarantee |
An on-chain entry can record a direct protocol asset, a contractual claim, a governance right, or only evidence about an off-chain position. Start with the asset-versus-claim test before assigning economic meaning to a ledger value.
Mechanism and flows
Section titled “Mechanism and flows”- A sender authorizes a transaction under the network’s account rules.
- The network propagates it and chooses an order through its block-production and consensus process.
- Nodes validate the block and execute valid transactions against prior state.
- The resulting state and receipts become increasingly safe to rely on under the network’s finality model.
Capital flow occurs when valid state transitions move assets. Claim flow occurs when contract rules create, transfer, or extinguish entitlements. Information flow carries transactions, blocks, state commitments, and attestations. Control flow sits with whoever can sign, validate, upgrade clients, or change governed parameters. Return flow is not created by ledger operation; any fee, issuance, or application return has a separate payer and allocation rule. Risk flow reaches users when consensus, software, application code, or off-chain enforcement fails.
State and loss allocation
Section titled “State and loss allocation”| State | What is known | What remains uncertain |
|---|---|---|
| Submitted | A signed request exists | Inclusion, ordering, execution, and finality |
| Included | A block contains the request | Whether execution succeeded and history persists |
| Executed | A node derived a result and receipt | Whether a later reorganization replaces it |
| Finalized | The protocol’s declared finality condition holds | Exceptional protocol recovery and off-chain enforceability |
Blockchain operation alone does not create investment return. Fees can pay validators, sequencers, or protocol treasuries, and issuance may reward consensus participation, but those transfers have payers and dilution effects. Loss can fall on transactors, token holders, validators, applications, or off-chain claim holders depending on the failed assumption.
Beginner lens
Section titled “Beginner lens”Think of the chain as the shared notebook, consensus as the rule for accepting pages, and transactions as proposed edits. A visible entry proves what the accepted software state says; it does not prove every external fact behind it.
Practitioner lens
Section titled “Practitioner lens”For each chain, identify block production, confirmation policy, finality, reorganization behavior, fee asset, data availability, upgrade process, sequencer or validator concentration, and operational response to a halt. Policies should scale with value at risk instead of using one confirmation number everywhere.
Engineer or auditor lens
Section titled “Engineer or auditor lens”Ethereum is one concrete design, not the definition of every blockchain. Its developer documentation describes a replicated state machine, the EVM, nodes, transactions, blocks, and proof-of-stake consensus. Other networks may use different account models, execution environments, data-availability systems, sequencers, and finality rules.
Security review notes
Section titled “Security review notes”Review whether honest nodes applying the accepted rules reach the same state, whether authorization and issuance rules constrain value changes, whether applications wait for their stated finality condition, and whether unexpected state divergence is detectable. These are desired review properties, not a claim that any network has been proved absolutely safe.
Common misunderstandings
Section titled “Common misunderstandings”- “On-chain means trustless.” It makes some rules inspectable while adding protocol, software, validator, governance, and oracle assumptions.
- “A block makes a transaction irreversible.” Inclusion and finality are separate states.
- “The token balance proves ownership of the underlying.” Economic ownership depends on the token’s issuer, contract, custody, and redemption rules.
Prerequisites and learn next
Section titled “Prerequisites and learn next”This is the starting foundation. Continue with wallets and keys to learn how actions are authorized, then transactions and gas to follow a request into state.
Sources
Section titled “Sources”- Ethereum.org, Introduction to Ethereum — one implementation’s state-machine, node, block, and consensus model (accessed 2026-08-09).
- The supplied DeFi seed, sections 2, 3, 12, and 14 — system layers, analysis questions, and the blockchain learning stage.
Machine-readable model
Key equations
Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.
This concept does not require one canonical equation. Its mechanism and state transitions remain the authoritative explanation; do not invent a formula merely to make the topic look quantitative.
Assurance contract
Security properties
These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.
Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.
Honest nodes applying the same accepted rules derive the same valid state from the same finalized history
Transactions cannot create or transfer value outside the protocol's explicit issuance and authorization rules
The consensus and finality assumptions used by applications are explicit and monitored
Historical commitments make unauthorized state alteration detectable under the selected protocol assumptions
Knowledge check
Quiz
Answer in your own words, then open the model answer.
Does finalized on-chain state prove an off-chain asset exists?
Model answer
No. It proves what the chain accepted under its protocol rules. Custody, legal rights, and external facts need separate evidence and enforcement.