The Ethereum community has been lately engaging a lot in debates revolving around scalability solutions.
What’s very notable in these discussions is the disagreement on the basic definitions that are needed for a proper debate.
Especially contentious is the definition of Layer 2 (L2). We can boil it down to two “camps”, each with its own view on what L2 encompasses.
But before we dive into that, let’s take a look at a definition of a blockchain and a definition of an L1 (which luckily doesn’t seems to be so contentious).
What is a blockchain?
Funny enough, we could say that blockchain also has two definitions: narrow and broad.
In a very narrow meaning, a blockchain is a data structure where chunks of data are grouped together into blocks. Each block (except the first one — the genesis block) contains an identifier (e.g., block hash or block number) of the previous block, which “links” the two blocks together (the “chain” part of the term “blockchain”). The data that is stored in a block is usually transactions, but it can also be a state or some other data.
The blockchain data structure is sometimes referred to as a linked list in computer science, but with a pointer to a predecessor element (a back-linked list, if you will).
But when people talk about blockchain, they mostly don’t mean just a data structure, but a complete solution that includes mechanisms that make a blockchain network practically useful, such as a consensus protocol, nodes/validators, etc.
So when I refer to a blockchain in the rest of this text, I’ll use it in a broader sense with all these mechanisms included.
L1 definition
L1 stands for Layer 1, and it means a blockchain that exists on its own and does not depend on any other blockchain.
If a blockchain relies on another blockchain so that it cannot function properly without it, it can’t be considered an L1. Layer 1 is always an independent and standalone chain.
L2 definition
Here’s where the disagreement between the two “L2 camps” begins. But before we consider the differences in views, let’s see where both camps agree on.
The part where they agree is that an L2 is a chain that cannot exist on its own. Instead, it needs an L1 and depends on it.
We can call this definition alone a broad L2 definition.
But the other camp wants to narrow the L2 definition even further and only considers chains or solutions that “fully derive security from L1” as being true L2.
What does “fully deriving security from L1” mean?
It’s a term that’s often used but not often explained.
Contrary to what you’d expect, it doesn’t mean that the chain that “fully derives security from L1” is necessarily more secure than a chain that only partially derives security from the L1 (at least not from the point of view of the chain security and proper functioning).
Instead, it means that the user funds on that L2 are more secure because there’s a mechanism on L1 that allows a user to safely remove funds from a (potentially malicious) L2 whenever they want to.
Where does the difference between the broad and the narrow L2 definition come from?
It comes from the point of view.
The broad definition comes from a chain’s point of view — from its ability to exist on its own vs. being dependent on another chain.
The narrow definition’s point of view is something completely different. It comes from a user’s point of view, more precisely from the safety of the user’s funds.
If a user can securely remove their funds from a (potentially malicious) chain by using mechanisms on L1, then it means the chain is indeed an L2 (according to the narrow definition). The necessary requirements to do that are on-chain data availability (storing all rollup transactions on L1) and validity/fraud proofs.
Conclusion
Each of the definitions makes sense within its own reasoning and, most importantly, from its respective point of view.
The Narrow L2 definition proponents are focused 100% on the safety of user funds and the ability to restore them (even if all L2 validators shut down).
On the other hand, the Broad L2 definition proponents believe layer 2 is wider than that and that there’s room for solutions that don’t store all data on-chain (on L1), allowing a higher throughput (higher TPS).
The throughput of rollups will always be limited by the amount of calldata that can be sent in a single transaction. So on-chain data availability solutions (like rollups) will always have lower throughput (smaller TPS and higher gas cost) than off-chain data availability solutions (like Polygon PoS Chain, zkPorter by zkSync, and Validium by Starkware).
The end-user should have a choice between maximizing security or lowering transaction costs.
