Research
What Is the Blockchain Trilemma? How Blockchains Scale
October 23, 2026
7 mins read
The blockchain trilemma says simple designs get only two of decentralization, security and scalability. See why, and how rollups and sharding answer it.
The blockchain trilemma is the idea that a blockchain built with simple techniques can only have two of three properties at once: decentralization, security and scalability. Vitalik Buterin, co-founder of Ethereum, is most closely tied to the framing and set it out in his April 2021 essay "Why sharding is great: demystifying the technical properties". Most of the scaling work of the past five years, from rollups to sharding to data availability sampling, is an attempt to get all three without giving up one.
Understanding the Blockchain Trilemma
The blockchain trilemma describes a trade-off: in a simple blockchain design, improving one of decentralization, security or scalability tends to weaken another.
The three properties
In his 2021 essay, Buterin defines the three properties in concrete terms:
- Scalability: the chain can process more transactions than a single regular laptop can verify.
- Decentralization: the chain can run without depending on a small group of large, centralized actors.
- Security: the chain can resist a large share of its participating nodes trying to attack it.
The point of the trilemma is that these properties pull against each other. If every node must check every transaction, the chain stays decentralized and secure, but throughput is capped by what an ordinary node can process. Raise that cap and fewer people can afford to run a node.
Three easy designs that each pick two
Buterin's essay names three "easy" designs, each of which drops one property:
- Traditional blockchains, such as Bitcoin and Ethereum before proof of stake, have decentralization and security but not scalability.
- High-throughput chains that run on a small set of powerful block producers are scalable and secure, but not decentralized.
- Multi-chain ecosystems, where different applications live on different chains and talk to each other through cross-chain protocols, are decentralized and scalable, but not secure, because an attacker only needs to win a majority of the consensus nodes on one of those chains.
Decentralization: why it matters
Decentralization means no single company or small group controls the network. Anyone can run a node, check the chain's history and refuse invalid blocks. This is what lets users rely on the rules of the chain rather than on the goodwill of an operator.
The practical test is node cost. If verifying the chain needs a data center, only large operators can do it, and the network depends on them. That is why many designs keep the hardware needed to run a node modest, even at the cost of throughput.
Security: protecting the network
Security in the trilemma sense is about how much of the network an attacker must control to rewrite history or censor transactions. Cryptography (digital signatures and hashes) protects individual transactions and data, while the consensus mechanism protects the order of blocks.
In proof of work, an attacker needs a majority of the mining power, which is the basis of the well-known 51% attack. In proof of stake, an attacker needs a large share of the staked tokens, and misbehaving validators can lose their stake. In both cases, a larger and more widely held network is more expensive to attack.
Scalability: the bottleneck for adoption
Scalability is the capacity to handle more transactions without raising costs for users or node operators. On a chain where every node re-executes every transaction, throughput is limited by the slowest node the network wants to support. When demand exceeds that capacity, fees rise and users are priced out.
This is the constraint the trilemma describes. Raising block size or block speed on a single chain adds capacity, but it also raises the cost of running a node, which pushes the network toward the high-throughput, less decentralized corner.
The root of the trilemma: one node, every transaction
The trade-off comes from one design choice: every full node downloads and verifies everything. Under that rule, the chain can only be as fast as its typical node. Breaking the trilemma therefore means finding ways for nodes to be confident a block is valid without each of them doing all the work.
Two techniques do that. Zero-Knowledge Proofs let a node check a short proof instead of re-running every transaction. Data availability sampling lets a node confirm that block data was published by checking small random pieces of it instead of downloading all of it.
Solutions to the Blockchain Trilemma
Most solutions cut how much work each node must do, either by moving execution off the main chain or by letting nodes check data without downloading all of it.
Rollups: execution moves off the main chain
Rollups execute transactions off the main chain and post compressed transaction data, and in the case of ZK rollups a validity proof, back to it. The main chain stays decentralized and secure, while rollups add throughput on top. Optimistic rollups assume batches are valid unless someone submits a fraud proof, evidence that a batch was wrong, within a challenge window. ZK rollups attach a validity proof, a Zero-Knowledge Proof that the batch was executed correctly. We cover how ZK rollups keep proof costs down in low-cost ZK rollups, and how rollups differ in their security and decentralization in security classification of Layer 2 rollups.
Data sharding: more room for rollup data
Earlier sharding plans split execution across many parallel chains. Ethereum's roadmap shifted to sharding data instead, so rollups get cheap space to publish their transaction data.
- EIP-4844 (proto-danksharding) went live with the Dencun upgrade on 13 March 2024. It added "blobs": a cheaper type of temporary data space that rollups use to post their transaction data to Ethereum, kept for about 18 days. According to ethereum.org, the upgrade significantly reduced the cost of rollups, mostly through lower Layer 2 fees.
- PeerDAS (EIP-7594) went live with the Fusaka upgrade on 3 December 2025. Nodes check that blob data is available by sampling pieces of it rather than downloading every blob, which lets the network raise blob capacity. Two follow-up upgrades that changed only blob settings raised the target number of blobs per block from 6 to 14 by January 2026, per the Ethereum Foundation's "Fusaka Mainnet Announcement" (November 2025).
Different consensus mechanisms
Consensus design also shifts the balance. Proof of work secures a chain through computation but limits speed and uses a lot of energy. Proof of stake replaces mining with staked capital and lets the network penalize misbehaving validators, which Ethereum adopted with the Merge in September 2022. Consensus changes alone do not remove the trilemma, but they change the cost of security and the hardware needed to take part.
State channels and sidechains
State channels and sidechains also move activity off the main chain. Channels suit repeated payments between the same parties. Sidechains run their own consensus, so they add capacity but do not inherit the main chain's security in the way rollups do. Our comparison of OP Stack and ZK Stack looks at how two rollup frameworks approach this.
Is the blockchain trilemma solved?
Opinions differ. In a post on 3 January 2026, covered by Decrypt in "Ethereum's Blockchain Trilemma 'Solved': Vitalik Buterin" (5 January 2026), Buterin argued that the trilemma has been solved "not on paper, but with live running code". He pointed to PeerDAS live on mainnet for data availability, and to ZK-EVMs (systems that prove Ethereum-style execution with a Zero-Knowledge Proof), which he described as production-quality on performance but still at alpha stage, with safety the main work that remains. Rollups still differ widely in how decentralized their sequencers (the operators that order transactions) and provers are, so the answer depends on which layer you measure.
What has changed is the shape of the problem. The question is no longer only how fast one chain can go, but how much work each node must do to stay confident in the result. Zero-Knowledge Proofs are central to that answer, because a short proof is cheaper to check than the computation it covers. The same idea applies beyond scaling: Orochi Network's zkDatabase generates a proof for every update to off-chain data, so others can verify it was stored and processed as claimed without re-running the work. Our explainer on ZK data rollups shows how that applies to Web3 projects.
View Docs: see how Orochi Network uses Zero-Knowledge Proofs to make data verifiable.
Related toResearch
