Blockchain Design — Ledger, State, Consensus, Execution, and Governance

NIST IR 8202 describes blockchains as tamper-evident and tamper-resistant digital ledgers implemented in a distributed fashion without a central repository. Note the careful wording: it does not say “impossible to alter.” Whether history can be replaced, and at what cost, depends on consensus rules, participants, keys, networking, implementations, and social adoption, not on hashing alone.

A blockchain is one kind of distributed system, not a synonym for all of them. Replicated databases, peer-to-peer file sharing, job schedulers, and transparency logs also run across many machines, and not all of them need a blockchain. Adopting one also does nothing to stop operational authority, hosting, client software, asset ownership, or governance from concentrating.

The first task, then, is not to choose the “best chain.” It is to define the asset being protected, the adversary, the failure model, the participation boundary, and what users can check for themselves. Blocks, tokens, and smart contracts are possible answers to those conditions, not goals in their own right.

Assurance does not come from the consensus layer alone. It depends on who counts as a voter, how data becomes state, whether the data needed for verification can be obtained, who reports facts from outside, and who adopts rule changes. Hardening one layer does not make up for a sole administrator key somewhere else: the trust boundary of the whole system shrinks to that key.

“Decentralization” is not a single number either. Block production, full validation, client diversity, network reachability, operators, ownership, improvement proposals, and emergency keys each have to be looked at on their own. A guarantee should say what happens when an assumption fails, not only how fast the system runs in normal operation.

Before it can reach consensus, a system has to decide whom to count. On a public network that gives one vote per identity, a single actor can simply create many pseudonyms. The Sybil problem, formalized by John Douceur, shows why a large number of identities is no guarantee of a large number of independent entities. A digital signature authenticates statements made with a key; it does not show that each key belongs to a separate person or organization.

Proof of Work and Proof of Stake do not identify morally correct participants. They tie the otherwise cheap creation of identities to a scarce resource or to a penalty. Both stay connected to resource markets, delegation, custody, and operating infrastructure. Who is eligible to take part and how concentrated block production actually is are two separate measurements.

On a permissioned network, a Membership Service Provider such as the one in Hyperledger Fabric can make certificates, roles, organizations, and revocation explicit. That moves the Sybil question to the identity issuers and to legal or organizational boundaries; it does not remove it. Open participation and authenticated participation are answers to different adversaries, different accountability needs, and different exit requirements.

A ledger is an ordered record of events; state is the current value you get by applying those events under the rules. In state-machine replication, replicas arrive at the same state by running the same deterministic transitions in the same order. Blockchains build on that principle, but it does not follow that every node must keep all history forever, or that every read has to go through consensus.

The Bitcoin UTXO model spends unspent outputs and creates new ones. An account model updates the balances, nonces, and contract storage tied to an address, and designs centered on objects or events are possible too. UTXOs make dependencies and parallel validation easy to see, while accounts make shared state convenient. Each model trades off differently on concurrency, storage, privacy, and developer experience.

A hash chain causes a change to an earlier record to show up in every later commitment, and a Merkle tree can prove inclusion under a root with a short proof. What the proof establishes is that a value was committed under that particular root. It does not show that the value is true in the outside world, that the root belongs to the legitimate chain, or that the underlying data is still available.

The word consensus usually hides several separate questions: whether a transaction is valid under the rules, how competing proposals are ordered, which history the fork-choice rule treats as canonical, and the conditions under which a decision can still be reversed. A majority vote does not turn an invalid state transition into a valid one: validating nodes reject any proposal that breaks their own rules.

Safety means two conflicting values are never both finalized; liveness means valid work eventually makes progress. Under network delay or partition, neither can be guaranteed without assumptions. A protocol that allows only for crashes differs from a Byzantine fault-tolerant one that also allows for signed, contradictory votes, and they differ in replica count, quorum, and communication cost.

Bitcoin confirmations are not a guarantee tied to the clock. They are probabilistic, economic settlement: the expected cost of replacing history rises as Proof of Work accumulates. Explicit finality in BFT-style systems likewise does not reach past a validator-key compromise, a change to the validator set, an implementation bug, or an emergency social fork. An application should state which failure conditions and which waiting time it accepts, instead of asking only whether a chain is “final.”

A ledger that validates transfers and one that runs general programs differ widely in cost and attack surface. Bitcoin Script is a restricted language for expressing the conditions under which a transaction output may be spent. Ethereum specified a state transition and the EVM in its Yellow Paper, creating a general execution environment in which contracts update shared state.

Replicas converge only if execution is deterministic. Reading a local clock, local randomness, or an external HTTP response directly would let results drift apart. Metering resources caps infinite loops and runaway computation or storage, but it brings fee markets, state growth, failed transactions, and outcomes that users may find hard to predict.

“Code is law” is not a technical security model. Code sits alongside compilers, clients, upgrade proxies, administrator keys, frontends, and oracles, and the agreement users had in mind may differ from the rule the machine actually runs. Specifications, implementations, audits, authority, and the paths for halting or recovering have to be assessed together.

Participants can agree on a block header or a state root and still leave an observer unable to check the transition, if the transaction data needed to recompute that root is withheld. Data availability is the assurance that the data required to verify a block was actually made available to participants. As the Ethereum documentation notes, that is separate from data retrievability, the ability to fetch history indefinitely.

A full node on a monolithic chain downloads block data, executes it, and rejects any block whose data is missing. Light clients, rollups, and modular designs scale by letting participants process less than all of the data, so they need other assurances: availability sampling, fraud proofs, validity proofs, committees, or publication to a base layer. A proof that execution was correct does not by itself hand a user the data needed to reconstruct state or exit.

Availability design cannot be separated from storage cost. “Everything on-chain forever” is expensive, and it collides with privacy or deletion requirements. Cheap off-chain storage weakens recovery once the custodians walk away. A design should state retention periods, who is responsible for archives, how synchronization works, and the minimum data needed for verification.

Protocol rules alone cannot tell a deterministic contract the market price, the weather, whether a parcel arrived, or how a court ruled. An oracle sources external data, verifies or aggregates it, and delivers it to a chain. Unanimous agreement among validators on one oracle value still says nothing about whether that value is true in the physical world. That boundary is the oracle problem.

Oracle design has to look at source diversity, reporter independence, update rate, the cost of manipulation, handling of outliers, fallbacks during an outage, signing keys, and governance. Averaging many feeds adds little independence when they share an upstream API or operator. There is also a trade-off between slow, well-confirmed observations and fast data that is easier to manipulate.

A bridge represents an event on chain A inside chain B, using light-client verification, validator signatures, multisignatures, or an optimistic challenge. The safety of the asset on the destination chain rests on both chains and on a new trust domain as well: message verification, custody, upgrade keys, relayers, and frontends.

A protocol is kept alive by documents, software, and the choices of participants, not by natural law. BIP 3, which replaced BIP 2, and EIP-1 set out processes for documenting and discussing improvements, but getting a proposal number or an author’s approval does not change the network rules. A change takes effect only when some combination of the specification, independent client implementations, node operators, block producers, wallets, exchanges, and users adopts it.

A soft fork can be described as narrowing what the old rules accept as valid, while a hard fork may allow history that old nodes reject. A compatibility label says nothing about who made the decision, whether those who disagree can stay safely, or which branch keeps the name and the market infrastructure. Governance lives in release permissions, standardization processes, communications, and funding as much as in any formal vote.

Being changeable is not a flaw in itself: bug fixes and cryptographic migration need an upgrade path. What matters is the difference between hidden administrator power dressed up as immutability and change conditions that are stated openly, with delays, auditability, key rotation, the ability to give up authority, and accountability in an emergency.

A permissioned blockchain uses identity policy to restrict which organizations, validators, readers, and writers take part. In Hyperledger Fabric, organizations, peers, orderers, channels, policies, and MSPs together form the accountability boundary of the network. Without an open contest for resources, privacy, approval workflows, regulated responsibility, and performance become easier to design among parties who already know each other.

Certification authorities, consortium agreements, revocation, the ordering service, and channel administrators become the trust points instead. A replicated, signed history can make unilateral changes by a database operator easier to detect, but it does not stop member organizations from colluding or authorized parties from entering false information.

Compare the design against a conventional database, an append-only transparency log, digital signatures, and BFT replication, without giving the word “blockchain” any credit of its own. If every writer answers to one company, the same administrator runs both the database and the validators, and users never verify anything themselves, the chain structure may add more complexity than assurance.

Before adopting anything, list the owners of the shared state, the writers, validators, readers, and auditors, by organization or role. Then decide which failures matter: crashes, network partitions, malicious signatures, a compromised administrator, censorship, data loss, or lost keys. Even when the requirement is “do not trust a central administrator,” the design still has to say which parties are trusted, and under what conditions.

When one organization is the canonical writer and needs fast updates, search, and correction, a conventional database with a signed audit log may fit better. Public verification on its own may need no more than a transparency log or a content-addressed archive. A blockchain becomes a candidate when several parties must order updates together and the value of avoiding a single administrator outweighs the cost of replication, consensus, and key management.

A pilot should test more than transaction volume. Stop validators, partition the network, rotate keys, upgrade the software, correct a bad entry, restore an archive, and remove a participant. Whether the organizations involved can still carry out a recovery after authority or data is lost tells you more about production assurance than a demonstration under normal conditions.

Bitcoin combines Proof of Work, UTXOs, hash-linked blocks, peer-to-peer propagation, difficulty adjustment, and issuance plus fees, all in service of one goal: keeping a history of electronic cash among public participants without a central identity issuer. A full node checks accumulated work and also whether transactions and blocks satisfy its own consensus rules. Miners gain no authority to vote an invalid block into validity.

Bitcoin is not a template to copy unchanged into a permissioned supply-chain ledger or a high-frequency general computer. Faster finality or richer execution on another chain does not bring with it the same public verifiability, exit properties, or monetary policy either. A comparison should line up purposes and trust assumptions rather than stop at transactions per second or block time.

The central lesson is that the choices hang together. Nodes that validate the supply rules, work that provides Sybil resistance, the way history is selected, incentives, restricted execution, and a conservative change process all point at one objective. Treating Bitcoin as a single tightly integrated point in a wider design space, rather than as the end of distributed-systems history, makes it possible to evaluate other approaches without exaggerating or downplaying the differences.