Every blockchain has to make a trade-off between three things it would ideally have all of: security, decentralization, and scalability. Improving any one of them tends to weaken at least one of the others. This trade-off is so consistent across designs that it has a name: the blockchain trilemma. Once you have this framework, every chain you meet becomes a point in the same triangle. You can read its design choices as a specific bet about which two corners to prioritize. This lesson walks through the trilemma, places the major chains inside it, then looks at one of the ways modern designs try to escape it. That way out is called Layer 2.

Three properties matter for any blockchain. Briefly:

Security is how expensive it is for an attacker to overturn confirmed transactions or trick the network into accepting invalid ones. A chain with strong security has a long track record, a large pool of validators or miners with real economic stake, and rules conservative enough that attacks would cost more than they could plausibly earn. Bitcoin's security is the strongest of any chain by this measure.

Decentralization is how widely distributed the set of validating parties is. A decentralized chain has many independent nodes run by people in different jurisdictions, on hardware ordinary users can afford, with no single party able to influence the chain's behavior on their own. The classic test is: can a motivated hobbyist run a full node on a laptop? If yes, the chain is decentralized. If no, the chain is at best partially decentralized.

Scalability is how many transactions per second the chain can process while preserving the other two properties. A scalable chain can handle the throughput of a real consumer payment system without breaking. By 2025, the major credit card networks handle tens of thousands of transactions per second at peak. Most L1 blockchains handle far fewer.

The trilemma is the empirical observation that improving any of these three tends to weaken at least one of the others. The reasons aren't mysterious. They fall out of the design choices each property requires.

Wanting more scalability typically means bigger blocks, faster block times, or both. But bigger blocks take more storage and bandwidth to relay. This raises the cost of running a node, which thins out the set of people willing to run one. Fewer node operators means weaker decentralization. Faster block times mean less time for blocks to propagate across a global network before the next block is produced, which increases the chance of accidental forks and makes consensus less reliable, which weakens security.

Wanting more decentralization means keeping hardware requirements low enough that ordinary people can participate. But low hardware requirements cap how much computation, storage, and bandwidth the network can collectively handle, which caps throughput. Decentralization and scalability pull against each other on the base layer.

Wanting more security means long confirmation times, conservative upgrades, and heavy economic stake required to be a validator. All of those make the chain feel slow and inflexible. That's the trade-off Bitcoin has been making for fifteen years. Security comes from caution, and caution costs speed.

These aren't strict laws. They're observations about how the design choices tend to interact. A clever design might push the trade-off in one direction without hurting the others as much as the typical trade would, but no design has eliminated the trade entirely.

The diagram is qualitative. There are no scores. Bitcoin sits up near the security/decentralization edge because that's what its design optimizes for, with the well-known cost of base-layer throughput. Solana sits closer to the scalability/security edge, with higher hardware requirements that cap how many people can run a full node. Ethereum tries to balance all three on L1 by being conservative about base-layer throughput. It pushes the scaling work off the base layer entirely, to a category of systems called Layer 2.

A quick definition of those two terms before we go further. They show up in every conversation about blockchain scaling. A Layer 1 or L1 is a base blockchain that runs by itself and doesn't depend on any other chain for security. Bitcoin is an L1. Ethereum is an L1. Solana is an L1. When you hear the phrase "base layer," it means the L1. A Layer 2 or L2 is a system built on top of an L1 that handles transactions separately but periodically writes its state back down to the L1, inheriting the L1's security in the process. L2s are not chains in the usual sense. They're protocols that use an L1 as their foundation. Bitcoin has Lightning as its main L2. Ethereum has several. Solana, designed for high base-layer throughput, has fewer.

If the trilemma forces every L1 to compromise on one of the three properties, the natural question is whether you have to do everything on the L1. The answer, increasingly, is no. Layer 2 systems handle transactions off the base chain and only periodically write back to it.

The idea is simple. The L1 is slow, expensive, and very secure. So use the L1 for what it's best at: providing strong final settlement that nobody can roll back. Above it, run a faster system that handles the actual transaction volume. That faster system regularly anchors its state back to the L1, inheriting the L1's security guarantees without being constrained by the L1's throughput.

There are three styles of L2 worth knowing by name. Each one approaches the same problem differently.

Payment channels are Bitcoin's primary L2 approach. Two parties open a "channel" by jointly locking up some bitcoin on the L1. Once the channel is open, they can exchange any number of transactions privately between themselves, with each transaction updating the balance inside the channel. None of these intermediate transactions touch the L1. When the parties are done, they close the channel by writing the final balance back to Bitcoin. The L1 sees two transactions, open and close, regardless of how many transactions happened inside. The Lightning Network is the largest deployed example of this pattern.

Optimistic rollups run on Ethereum and similar smart-contract chains. They execute many transactions off the L1, batch them together, and post the batch to L1 with a summary of the resulting state. The L1 accepts the summary as valid unless someone challenges it within a fixed time window, typically about a week. If a challenge succeeds, the disputed batch is rolled back. The "optimistic" name comes from this assumption that batches are valid unless proven otherwise. They're cheap and fast to operate, but withdrawals from the L2 back to the L1 take the length of the challenge window to finalize.

ZK rollups do the same thing but instead of "trust unless challenged," they post a cryptographic proof along with each batch that mathematically demonstrates the off-chain execution was correct. The L1 verifies the proof and either accepts or rejects the batch immediately. ZK rollups are more complex to operate but withdrawals back to L1 are fast because there's no challenge window. The math behind ZK proofs is one of the deepest topics in modern cryptography and gets a proper treatment in the Ethereum track.

The broader idea behind these L2s, sometimes called the modular blockchain thesis, is that a chain doesn't have to do everything itself. It can specialize in one job, typically settlement and data storage, and let other layers handle execution, ordering, and fast finality. Each layer trades off the trilemma differently, but when you stack them together, the combined system can be stronger along all three axes than any single chain could be alone.

This is a deliberate escape from the trilemma's hardest limitation. It doesn't break the trade-off, but it lets different layers in the stack make different bets, with the most security-sensitive operations anchored to the slowest and most decentralized layer.