The Blockchain Trilemma Explained: Can It Be Solved?

The blockchain trilemma, also called the scalability trilemma, is the idea that a blockchain can easily achieve only two of three properties at once: decentralisation, security and scalability. Raise throughput by asking nodes to do more work and fewer people can run a node; spread the load across many small chains and each one becomes easier to attack. The framing was popularised by Ethereum co-founder Vitalik Buterin, and most modern blockchain designs can be read as an attempt to escape it.

This guide explains where the trilemma comes from, what each property actually means, how rollups, sharding and parallel execution try to get all three, and why some researchers think the trilemma is more of a rule of thumb than a law.

What is the blockchain trilemma?

The clearest statement comes from Buterin's April 2021 essay "Why sharding is great". He describes three properties a blockchain tries to have, and says that "simple" techniques only get you two of them:

• Scalability: the chain "can process more transactions than a single regular node (think: a consumer laptop) can verify."
• Decentralisation: the chain "can run without any trust dependencies on a small group of large centralized actors."
• Security: the chain "can resist a large percentage of participating nodes trying to attack it."

The idea is older than that essay. Ethereum's Sharding FAQ, an early research document, already asked whether "there's some kind of scalability trilemma at play", defining decentralisation as a system where each participant only needs the resources of "a regular laptop or small VPS".

Notice what the definitions do. Scalability is measured against what one ordinary node can handle, not as a raw transactions-per-second figure. A chain that does 100,000 transactions per second but needs data-centre hardware to verify them has not solved the trilemma; it has chosen scalability over decentralisation.

The three classic trade-offs

Buterin's essay sorts naive designs into three groups, each of which picks two corners:

The underlying tension is resource cost. If every node must check everything, the slowest node you want to include sets the speed limit. If you raise that limit, you shrink the set of people who can participate. If you split work between groups, each group is smaller and cheaper to corrupt. Our proof of stake vs proof of work guide covers how the cost of attacking a chain is set in the first place.

Rollups: scaling execution off-chain

Ethereum's main answer has been layer 2 rollups. A rollup runs transactions on a separate network, then posts the data to Ethereum along with either a validity proof (ZK rollups) or a claim that anyone can challenge with a fraud proof (optimistic rollups). The base layer stays small enough for ordinary nodes to verify, while execution happens elsewhere.

In trilemma terms, rollups try to keep Ethereum's decentralisation and security while adding scale. Buterin's December 2021 essay "Endgame" spelled out the compromise: "Block production is centralized, block validation is trustless and highly decentralized, and censorship is still prevented." A powerful operator can produce blocks, as long as anyone can cheaply check them.

The practice has lagged the theory. As of 17 October 2026, L2BEAT rated 57 of the 67 layer-2 projects it had staged at Stage 0, meaning operators could still override the rules. On 3 February 2026 Buterin wrote that "the original vision of L2s and their role in Ethereum no longer makes sense, and we need a new path", citing slow progress on decentralisation and a base layer that now scales with low fees (The Defiant). Our layer 2 guide covers rollups in detail.

Sharding: splitting the work on layer 1

Sharding attacks the trilemma head-on. Instead of every node processing every transaction, validators are split into groups (shards) that each handle part of the load, while a coordinating layer keeps the shards in agreement. To stop an attacker concentrating on one shard, validators are assigned randomly and reshuffled. Buterin's 2021 essay argues that this combination is "a technique that gets you all three": each node does a fraction of the work, no supernodes are needed, and an attacker has to beat the whole system rather than one small piece of it.

Ethereum itself moved away from sharding execution. It now shards data instead: blobs from the Dencun upgrade (13 March 2024) and PeerDAS from the Fusaka upgrade (3 December 2025) let nodes confirm that rollup data is available by sampling it rather than downloading all of it (Ethereum Foundation).

MultiversX runs execution sharding on its main chain. Its adaptive state sharding combines network, transaction and state sharding, with a metachain that decides at each epoch which nodes move between shards; selection uses randomness so it can't be predicted in advance. Under its Secure Proof of Stake consensus, each validator must stake at least 2,500 EGLD (MultiversX docs). The live network configuration on 17 October 2026 showed 3 execution shards, 400 nodes per shard and a 600 ms round (MultiversX gateway).

The cost is complexity. A transaction that touches accounts on two shards runs in two steps and is asynchronous, which makes some DeFi interactions harder to compose. Our sharding guide and the EGLD and MultiversX explainer go deeper.

DAGs and parallel execution: the Sui approach

A third route keeps one chain but uses every core of every validator. Sui orders transactions with Mysticeti, a consensus protocol in which validators propose blocks in parallel and blocks reference each other to form a directed acyclic graph (DAG). The Sui docs say Mysticeti commits in about 0.5 seconds on average with sustained throughput of 200,000 transactions per second in benchmarks, while warning that these are controlled-test figures, not production metrics.

Sui's data model helps too. Each transaction declares the objects it uses, and per the transaction lifecycle docs, transactions that don't conflict on inputs execute completely in parallel. Two people trading in two different pools don't wait for each other.

In trilemma terms, this pushes scalability by making each validator more efficient rather than by splitting the network. The trade-off is the hardware bar. Sui's validator guide suggests at least 24 physical cores, 128 GB of memory, 4 TB of NVMe storage and a 1 Gbps connection, which is well beyond a consumer laptop. Our guides to Sui and Mysticeti explain the design.

Is the trilemma real? The main critiques

The trilemma is useful shorthand, but it isn't a proven theorem. Common objections:

• The terms are fuzzy. "Decentralised" and "secure" have no single agreed measure. A chain can count its validators, its full nodes, its stake distribution or its client diversity, and each gives a different answer.
• It's a snapshot of today's technology. The original framing describes what "simple" techniques achieve. Validity proofs, data availability sampling and better consensus protocols have each moved the frontier, which is why Buterin himself argues sharding and rollups can get all three.
• Hardware keeps improving. What counts as a "regular node" grows every year, so a throughput level that once required centralisation may later run on consumer machines.
• Other trade-offs matter too. Latency, composability, cost and complexity don't appear in the triangle, yet they decide which design suits which use. Sharding, for example, scales well but makes cross-shard calls asynchronous.
• Marketing abuses it. Plenty of projects claim to have "solved the trilemma". In practice, check what a chain assumes about validator hardware, how many independent parties run nodes, and what an attacker would need to control.

A fair summary: there is no free lunch, but the price of each corner has fallen. Designs differ mainly in which assumptions they are willing to make.

Where JewelSwap fits

JewelSwap is built on layer 1s that take different routes through the trilemma: liquid staking JWLEGLD on sharded MultiversX, JWLSUI on Sui, and JWLXRD on Radix. Each chain's design shapes fees, speed and what you need to trust.

Frequently asked questions

What is the blockchain trilemma in simple terms?

It is the idea that a blockchain can easily have only two of three properties: decentralisation, security and scalability. Improving one, such as throughput, usually costs one of the others, such as the number of people who can afford to run a node.

Who came up with the blockchain trilemma?

Vitalik Buterin, co-founder of Ethereum, popularised it. It appears in Ethereum's early Sharding FAQ and in his April 2021 essay "Why sharding is great", which defines all three properties.

Is the scalability trilemma the same as the blockchain trilemma?

Yes. Both names describe the same trade-off between decentralisation, security and scalability. Buterin's own writing calls it the scalability trilemma.

Has anyone solved the blockchain trilemma?

No chain has proven it beyond doubt. Rollups, sharding and parallel execution each push the limits, but each relies on assumptions about operators, hardware or cross-shard complexity. Treat "trilemma solved" as a marketing claim and check the details.

How do layer 2s relate to the trilemma?

Rollups move execution off the base layer so Ethereum stays easy to verify, aiming to add scale without giving up decentralisation or security. In practice, most were still rated Stage 0 on L2BEAT in October 2026, meaning operators could override the rules.

Keep reading

• Layer 2 crypto explained
• What is sharding?
• Proof of stake vs proof of work
• What is Sui?
• What is EGLD and MultiversX?

This article is educational and isn't financial advice. Figures are as of 17 October 2026 from L2BEAT, the Ethereum Foundation and the MultiversX and Sui documentation, and they change over time; sources are linked throughout.