Skip to content
Financial Context Wiki

Blockchain: State, Consensus and Verification

A blockchain is a versioned protocol for ordering and validating state transitions across replicas. Hash links are only one component; trust depends on consensus, permissions, independent verification, data availability, governance and recovery.

Updated

Educational protocol analysis only. A blockchain label, valid hash chain or successful transaction does not by itself establish decentralization, truthful inputs, data availability, finality, legal ownership or investment value.

Direct answer

A blockchain is a versioned protocol that lets multiple replicas order proposed transactions, validate state transitions and converge on an accepted history under stated consensus and network assumptions. A block is a protocol-defined container with transactions or other data plus commitments to prior history and resulting state; the chain or directed history links accepted containers through cryptographic commitments.

Hash links make unauthorized historical changes detectable, but they do not independently make a system decentralized, immutable or correct. Those properties depend on who may propose and validate, whether users can verify independently, the fork-choice and finality rules, data availability, client diversity, governance, key control, incentives and recovery procedures.

Blockchains can use UTXO, account, object or application-specific state models; proof of work, proof of stake, Byzantine-fault-tolerant voting or permissioned consensus; and probabilistic or checkpoint-based finality. The word “blockchain” therefore names a broad architecture family, not one security guarantee or one database product.

1
Create

A wallet constructs a transaction with destination, value, fee parameters, and replay-protection data such as spent inputs or a nonce.

How it works

  1. Pin the chain, network, protocol version, permission model, state model and claim being tested. Record genesis or trusted checkpoint, chain identifier, client implementation and upgrade authority.
  2. Construct the exact transaction bytes and authorization. Check sender or input ownership, nonce or unspent-output references, amount, destination, fee limits, validity window, signatures and application calls before broadcast.
  3. Propagate the transaction through peers or gateways. Distinguish local admission and mempool policy from consensus validity; a node may reject, delay, replace or never receive a transaction that could be valid in a block.
  4. A proposer selects and orders transactions into a candidate block and commits to protocol fields such as parent, transaction, receipt, state or data roots. Ordering can affect execution results, fees, liquidations and extractable value.
  5. Independent nodes deserialize the block, verify consensus authorization and every required state transition, recompute commitments and reject invalid or unavailable inputs according to their rules. Producer signatures or proof of work do not override failed validation.
  6. Fork choice selects among competing valid histories, while confirmations, votes or checkpoints change reorganization risk over time. “Included,” “safe” and “finalized” are different states and remain protocol-specific.
  7. Reconcile protocol state with application intent, custody, bridge or venue accounting and archival requirements. Preserve transaction bytes, block hash, height or slot, receipt, logs, state proof, finality status, client version and independent endpoint evidence.

Worked examples

  • Account-state reconciliation. An account starts with 10 ETH and nonce 41. A valid transaction at nonce 41 transfers 2 ETH and consumes 0.00042 ETH in fees, so the simplified post-state is 10 - 2 - 0.00042 = 7.99958 ETH, the recipient gains 2 ETH, and the sender nonce becomes 42. A valid signature alone would not prove the pre-state balance or successful execution.
  • UTXO conservation. A transaction spends inputs of 0.80 BTC and 0.35 BTC, totaling 1.15 BTC. Outputs of 1.00 BTC and 0.1496 BTC total 1.1496 BTC; the difference is 1.15 - 1.1496 = 0.0004 BTC in fees. Nodes must also verify that every referenced output exists, is unspent and satisfies its spending conditions.
  • Commitment proof size. In an illustrative balanced binary Merkle tree with 8 leaves, an inclusion path needs log2(8) = 3 sibling hashes. With 256-bit = 32-byte hashes, those siblings occupy 3 * 32 = 96 bytes before indices and encoding. The proof binds a leaf to a claimed root; it does not prove that the source data is truthful or currently available.
  • Weight is not node count. In an illustrative voting protocol whose stated finality rule is >= 2/3 of weight, validators hold 30%, 25%, 20%, 15%, 10%. The first three total 30 + 25 + 20 = 75% and cross the rule, while the first two total 55% and do not. Real thresholds, correlation, equivocation and recovery rules must come from the named protocol.

Risks

  • Using the wrong chain, network, fork, checkpoint or chain identifier.
  • Treating a brand name as a complete protocol or trust-model specification.
  • Assuming hash linkage alone prevents authorized or consensus-approved rewrites.
  • Confusing a producer’s block proposal with independent node validation.
  • Treating mempool acceptance, broadcast, inclusion, execution success and finality as one state.
  • Signing bytes, domains or destinations different from what the interface displays.
  • Reusing nonces, spending stale UTXOs or miscalculating fees and change.
  • Trusting token symbols, labels, events or explorer interpretations instead of protocol identifiers and state.
  • Treating signed oracle, bridge or document inputs as proof that off-chain claims are true.
  • Ignoring transaction ordering, censorship, front-running and proposer or builder concentration.
  • Counting nodes or validators without resolving common operators, weights and infrastructure.
  • Ignoring client, cloud, geography, governance, key and software-supply-chain concentration.
  • Assuming all consensus models have the same fault thresholds or finality semantics.
  • Ignoring partitions, delayed finality, reorganizations, equivocation and recovery procedures.
  • Accepting block headers or proofs without the required data-availability assumptions.
  • Depending on one RPC, explorer, wallet, indexer or custodial platform as the source of truth.
  • Confusing protocol possession or control with legal title, recourse or recoverability.
  • Underestimating state growth, archival loss, synchronization cost and hardware barriers.
  • Ignoring upgrade keys, emergency pauses, social recovery and contentious forks.
  • Inferring privacy, scalability, investment value or application safety from the blockchain label.

Common misconceptions

  • Every blockchain is decentralized and immutable. Permission, operator independence, fork choice, governance and recovery determine who can change or reject history.
  • Data recorded on-chain must be true. Consensus can agree on faithfully recording a false price, forged document or malicious application input.
  • A valid transaction proves the intended outcome. It may target the wrong address, revert after consuming fees, emit misleading events or depend on later bridge and custody steps.
  • More replicas always improve security. Replicas under one operator, client, cloud or key can fail together and may not provide independent verification.
  • A blockchain is always better than a conventional database. A trusted operator, required deletion, high throughput or simple dispute resolution can make a conventional system more appropriate.

Sources

Navigation

Search the wiki...