Blockchain

The data structure, described precisely

Strip the vocabulary and a blockchain is a linked list where each link is a cryptographic hash. Nakamoto's original description takes one sentence: each block contains the hash of the previous block, which ties each subsequent block to it, forming a chain.¹ Change one byte in an old block and its hash changes, so every block after it now points at something that no longer exists.

A Bitcoin block header carries the previous block's hash, a Merkle root committing to every transaction in the block, a timestamp, the difficulty target and a nonce.³ The Merkle root is what lets a light client prove one transaction sits in a block without downloading the block. The nonce is what makes a valid header expensive to produce in the first place.

Ethereum generalises the same structure. Its specification defines the chain as a state transition system, in which a single global state is transformed by a series of transactions.² Blocks still chain by hash. What they commit to is an account state rather than a set of unspent outputs, and that difference is why one chain runs arbitrary programs and the other mostly moves value.

The problem it solves is agreement, not storage

Hash chaining is decades older than Bitcoin and it solves tamper evidence, not agreement. If two people broadcast conflicting transactions spending the same coin, the data structure has no opinion about which one is real. Something has to choose, and it has to choose in a way nobody can capture.

That is the consensus rule's job. Bitcoin's answer is accumulated work: the chain carrying the most proof-of-work is canonical, and Nakamoto frames the longest chain as proof that it came from the largest pool of CPU power. Producing a valid block means scanning for a value that, when hashed, begins with a number of zero bits.¹ Work is the scarce resource that makes votes expensive enough to count.

So the honest one line definition is that a blockchain is a replicated state machine whose participants agree on an ordering without trusting each other. Everything else is implementation. If your problem does not contain mutually distrusting parties, you do not have a blockchain problem, and in our view that single filter disqualifies more projects than any regulation has.

What immutable does and does not mean

Nothing in the design prevents rewriting. The whitepaper is explicit that an attacker's probability of catching up falls as more blocks are added, which makes settlement probabilistic rather than absolute.¹ Six confirmations is a risk threshold somebody chose, not a physical law, and chains reorganise at depth one as ordinary weather.

Immutability is therefore economic. It is the cost of producing a competing chain longer than the current one, and it is paid every hour of every day. On a proof-of-work chain that cost is roughly measurable through electricity consumption, and the measurements disagree with each other in a way that is more instructive than any single figure.

The Cambridge Centre for Alternative Finance puts Bitcoin's annualised electricity consumption at a central estimate of 155.02 TWh, inside a stated range of 77.36 to 253.28 TWh, as of 2 August 2026.⁵ Digiconomist, working from an economic model that derives power draw from miner revenue rather than from a hardware efficiency mix, published 204.44 TWh for the same week.⁶ Neither is a measurement. Both are models with different assumptions, and quoting one without the other is quoting a modelling choice as a fact.

The second half of the caveat matters more if you are building. Bytes are hard to change; meaning is not. A contract behind an upgradeable proxy can be replaced at a fixed address, a bridge can be repointed at new logic, and the participants running the software can agree to run different software. The ledger is immutable. The system around the ledger is governed, and governance is a human process with all the failure modes that implies.

Permissioned and permissionless are different security models

Permissionless chains let anyone validate, which means anyone can also spin up ten thousand identities, which means sybil resistance has to be bought with something scarce: hashpower or staked capital. Permissioned chains skip that problem entirely. The validator set is a known list and admission is a business decision.

The trade is straightforward. A known validator set buys higher throughput, lower operating cost, control over who reads what, and a legal counterparty you can sue. It relocates the entire trust assumption into whoever controls the membership list, which is usually the same consortium that would otherwise have been the trusted intermediary.

Our position is that a permissioned chain earns its keep when several organisations who do not trust each other need one shared record, and an outside party has to be able to verify that record later. Outside those conditions a replicated database with signed writes does the same job with less ceremony and fewer people to convince. The question is not whether the technology works. It is whether the coordination problem is real.

The trilemma every chain is designed against

Buterin's framing has aged better than most. A chain tries to have three properties and, using simple techniques, gets two. Scalability means processing more transactions than a single ordinary consumer machine can verify. Decentralisation means running without trust dependencies on a small group of large centralised actors. Security means resisting a large share of participating nodes trying to attack it.⁴

Every chain a founder can deploy to has already picked its corner, and the node hardware requirements tell you which. High throughput networks with a small, well resourced validator set have chosen scalability and security over decentralisation. Networks that keep verification cheap enough for a laptop have chosen the other way and price their blockspace accordingly.

That makes chain selection a product decision wearing infrastructure clothes. Your choice sets your users' fee floor, your finality time, your censorship exposure, and how honestly you can describe the protocol as decentralised in a regulatory conversation. Pick against those four. Ecosystem grant size is not one of them.

A worked example: what one year of immutability costs

Cambridge publishes its assumptions alongside its estimate, including an average electricity cost of 0.05 US dollars per kilowatt hour used in the conversion, and a seven day moving average applied to smooth short term hashrate volatility.⁵ That makes the annual electricity bill implied by the model easy to compute.

155.02 TWh is 155.02 billion kilowatt hours. At the model's own five cent assumption that is about 7.75 billion dollars of electricity a year, purchased in aggregate, to keep Bitcoin's history expensive to rewrite. Running the same arithmetic across the published range gives roughly 3.87 billion dollars at the low end and 12.66 billion at the high end.⁵

Treat that as an order of magnitude rather than a figure. It is arithmetic on a modelled input, using a uniform price no miner actually pays. What it is good for is calibration. Immutability on a large public chain has a running cost in the billions of dollars a year, funded by issuance and fees, and a chain whose security budget cannot support a comparable number against the value it secures is making a weaker promise than the word blockchain implies.

That is the question worth carrying into a chain selection conversation. Not whether it is decentralised, but what an hour of this chain's history costs to rewrite, and who is currently paying for that.

What all this changes when you are building

Five things follow, and they are the ones we raise in a chain selection review. Finality time sets what your product can promise a user at the moment they click. Fee variability decides whether your smallest transaction is economic at the ninetieth percentile of gas prices rather than the median. Validator concentration is a regulatory fact as much as a technical one, because your decentralisation language will be read against it. Data availability cost is a live line item for anyone deploying to a rollup. And upgrade governance decides who can change the rules underneath you, on what notice.

Nothing here recommends a chain. The right answer depends on what you are settling, how much value sits exposed inside a single block, and which users you are asking to pay fees. What we do insist on is that the choice gets made explicitly and written down, with the trade named, because it quietly sets the outer boundary of everything a token design can do afterwards.