The blockchain trilemma
Decentralisation, security, scale — the claim is that you can have two. It is not a proven theorem, and it has been a remarkably good guide.
The observation, associated with Vitalik Buterin, is that blockchain designs appear able to optimise strongly for two of three properties and must compromise the third.
The three
- Decentralisation. How many independent parties can verify and participate, and how cheap it is for an ordinary person to do so.
- Security. How costly it is to attack — to rewrite history, censor, or double-spend.
- Scalability. Throughput and cost per transaction.
No one has proved the trade-off is unavoidable, and the interesting engineering of the last decade has been attempts to escape it. But the pattern is consistent enough to be a reliable first question of any new design: which of the three did this one give up, and does the marketing mention it?
How the major designs resolve it
- Bitcoin. Maximises decentralisation and security. Accepts very limited throughput, and moves payments to a second layer.
- Ethereum. Prioritises decentralisation and security on the base layer, and pushes scale to rollups — an attempt to get all three by splitting the problem across layers.
- High-throughput chains. Prioritise scale and security by raising the hardware needed to run a node, which reduces how many independent parties can. Fast and cheap, with fewer validators.
- Permissioned ledgers. Abandon decentralisation entirely for scale and control. Usually a worse database than a database. See what a blockchain is.
Why decentralisation is the one that gets quietly traded
Throughput is a number. Security has an estimable cost of attack. Decentralisation has no agreed metric — validator counts, client diversity, stake distribution, geographic and jurisdictional spread and governance concentration all capture part of it and none captures it. A network can advertise thousands of validators while a handful of entities control most of the stake, and both statements are true.
The questions worth asking
- What does it cost to run a fully verifying node? If the answer is data-centre hardware, ordinary users cannot check anything themselves.
- How many independent implementations of the software exist? One codebase means one bug can stop the network.
- Who can halt it? If any party can pause the chain, the trade-off has already been made.
- How is stake or hashing power distributed among genuinely separate parties — not accounts, which are free to create?
Escaping it
The two credible research directions are layering — settle on a decentralised base, execute elsewhere — and cryptographic verification, where zero-knowledge proofs let a weak device verify a computation it could never perform. The second is the more radical: if verifying is far cheaper than executing, the link between throughput and participation cost weakens considerably.
That is a live research programme with real deployed systems and real remaining limitations. It is not solved, and it is the most substantive thing happening technically in the field.