One worker doing four jobs
Picture a tiny restaurant where a single person greets you, cooks the food, washes every dish, and keeps the books — all alone, for every customer. It works while the place is quiet. But the moment a crowd arrives, that one overworked person becomes the ceiling on how fast the whole restaurant can go. You cannot serve more diners without finding a faster human, and there is a limit to how fast any one human can be.
A classic chain like early Ethereum is that one overworked person. Every full node is asked to do four jobs at once for every single transaction: re-run the computation (execution), agree on the one true ordering (consensus), make sure the underlying data is actually published so anyone can check it (data availability), and anchor the final, agreed-upon state where disputes are resolved (settlement). Bundling all four into one node, run by everyone, is what we call a monolithic design. It is beautifully simple and self-contained — and, like the lone cook, it has a hard ceiling.
Splitting the chain into layers
The first idea is the same one that rescued our restaurant: hire specialists. Bring in a dedicated cook, a dedicated dishwasher, an accountant, a host — each doing the one thing they are best at, in parallel. A modular blockchain does exactly this. Instead of one chain doing all four jobs, it splits them into separate layers, and lets each layer be optimized, scaled, and even swapped out on its own.
The usual carving gives you three or four roles. The execution layer runs the transactions and computes new state — this is where the heavy work lives. The settlement layer is the trusted home base where disputes are resolved and final state is anchored. The consensus layer agrees on the one true ordering of what happened. And the data availability layer guarantees that the raw transaction data was genuinely published, so anyone can download it and check the execution for themselves. Pull those apart and each can be tuned hard for its own job.
MONOLITHIC MODULAR (one node, all jobs) (specialized layers) +-------------------+ +-------------------+ | EXECUTION | | EXECUTION (L2) | fast, cheap | CONSENSUS | +-------------------+ | SETTLEMENT | -> | SETTLEMENT (L1) | secure anchor | DATA AVAIL. | +-------------------+ | (all in one) | | CONSENSUS + DA | shared base +-------------------+ +-------------------+
How rollups slot into the stack
This is exactly where a rollup earns its keep, and why the modular story and the Layer 2 story are really one story. A rollup is an execution layer that lives above a base chain. It does the busy work off to the side — thousands of transactions, ordered and computed cheaply — then bundles them up and posts a compact summary back down to the secure base layer, usually Ethereum. The base layer never re-runs all those transactions; it just holds the data and the proof, and lends its security to the result.
So a rollup is the execution layer of a modular stack, and the base chain plays settlement plus data availability. The magic is in that last word: by posting its raw data down to the base, a rollup lets anyone reconstruct and check its work, so it inherits the base's security instead of inventing its own. A ZK rollup goes further and attaches a zero-knowledge proof that the batch was computed correctly — a tiny receipt the base layer can verify in an instant without redoing the math. That single move is how you can have cheap execution and strong security at the same time, the trilemma's forbidden pairing.
Sharding: splitting the load, not the jobs
Sharding attacks the same ceiling from a different angle. Borrowed from how giant databases cope, the idea is: stop asking every node to handle every transaction. Instead, divide the network into subsets — shards — and have each shard process only its own slice of the traffic. Ten shards, each handling a tenth of the load in parallel, can do roughly ten times the work of one. Where modular splits the kinds of jobs, sharding splits the volume of one job across groups.
The trouble is that splitting the load can split the security along with it. If only a tenth of the validators watch each shard, an attacker who could never threaten the full network might cheaply overwhelm one lonely shard. Making shards talk to each other safely, and shuffling validators around so no shard can be quietly captured, turns out to be genuinely hard — which is why early sharding plans were so ambitious and so slow to ship.
The frontier's surprise twist is that the two ideas converged. Rather than shard execution, Ethereum chose to shard only the data availability layer — splitting the cheap, plentiful job of publishing data across the network, while leaving execution to rollups on top. This is data sharding, and it is the cleanest illustration of the whole modular philosophy: shard the part that scales easily, specialize the part that is hard, and let the layers borrow security from one another.
Trade-offs and the takeaway
None of this is free. A monolithic chain has one clear story, one place where security and data live, and no seams to leak through. A modular system buys scale by adding complexity at the joints: data must be reliably published, proofs must be checked, and moving value between layers needs a bridge — historically the single most attacked spot in the whole field. More moving parts means more places for something to go subtly wrong, and the field is still actively working out the best ways to glue the layers together.
Hold onto the core picture and the rest follows. Monolithic packs every job into one node — simple, but capped by its busiest node. Modular hands each job — execution, consensus, settlement, data availability — to a specialized layer, so each can scale on its own. Rollups are the execution layer that does the work cheaply off to the side and borrows security from the base. Sharding splits the load across subsets, and modern designs shard the easy, abundant part — data — while leaving the hard part to rollups. The big bet of the trilemma frontier is that you no longer have to choose two of three: with the right seams, a stack of humble layers can be decentralized, secure, and fast all at once.