indexBlockchain State, Consensus & Finality#blockchain#consensus#finality

Blockchain State, Consensus and Finality

Introduction

Start below contracts: a network validates ordered transitions over shared state while peers may temporarily disagree about history. The branch makes that uncertainty visible before later layers hide it behind an RPC response.

Why It Matters

Protocol accounting, indexes, bridges, and user interfaces fail when “seen in a block” is treated as irreversible. Engineers need a vocabulary for forks, reorgs, safety, liveness, availability, and finalization.

Mental Model

Think in layers: transition validity filters blocks; fork choice selects a head; finality changes the cost or protocol status of reverting history; data availability determines whether independent verification is possible.

Questions This Branch Answers

  • What exactly is replicated, committed, and finalized?
  • How do reorgs change derived state?
  • Which assumptions are cryptographic, economic, network, or social?

Scope

Accounts and transactions, block/state commitments, forks, proof-of-stake, safety/liveness, finality, DA and light-client reasoning, plus focused EVM/UTXO contrasts.

Out of Scope

Validator operation at production scale, novel consensus research, mining economics, token-price analysis, and claims that every chain shares Ethereum semantics.

Dependencies

General hashing, signatures, networking, distributed-systems failure models, and Must Know.

Candidate Note Roadmap

  • replicated-state-machine — Model nodes replaying deterministic transitions over an ordered log.
  • accounts-transactions-and-state-roots — Connect transaction inputs to account updates and state commitments.
  • blocks-forks-and-reorgs — Simulate competing suffixes and explicit rollback of derived views.
  • proof-of-stake-and-fork-choice — Separate proposer/attester roles, validity, weight, and head selection.
  • finality-safety-liveness — Define what can and cannot be claimed under faults and partitions.
  • data-availability-and-light-clients — Explain verification when full state or block data is not local.
  • censorship-partitions-and-trust — Trace liveness failures and dishonest network views.
  • evm-utxo-and-ledger-contrasts — Compare stateful accounts with UTXO ownership and execution models.

Future Project

A TypeScript replicated-state-machine simulator with deterministic transitions, fork choice, reorg notifications, finality checkpoints, and an intentionally dishonest RPC view.

Initial Invariants

Valid blocks apply deterministic transitions; finalized history never changes inside the modeled fault threshold; rejected blocks commit no state; reorg handling removes every derived fact from the abandoned suffix.

Initial Threat Model

Equivocation, partitions, censorship, invalid-transition acceptance, stale or dishonest RPC views, confused finality labels, and clients that fail to roll back.

Primary Sources

Ethereum consensus specifications, the execution specification, Ethereum developer documentation, and the curated links in SOURCES.md.

Connects to: EVM execution, rollups and DA, and indexing and operations.