Is the expansion hope a false concept? Why is Layer 3 so controversial?

Original | Odaily Planet Daily

Author | Azuma

The controversial discussions surrounding Layer 3 have intensified in the past couple of days.

On one hand, the relevant tokens of representative Layer 3 projects like Degen Chain have seen astonishing increases in the past few days—DEGEN itself has surged by as much as 143% over the week; after choosing to transition to Base as a Layer 3, Aavegotchi's GHST has also strongly refreshed its historical high.

On the other hand, the voices of skepticism within the community regarding Layer 3 are growing louder. Vitalik himself expressed a somewhat opposing opinion today: "Layer 3 will not magically increase throughput."

Coincidentally, yesterday was April Fool's Day, and many projects took this as a focal point, jokingly making some comments about Layer 4 and Layer 5. For example, dYdX jokingly said, "The new version will be built on L4," which was even taken as news by some media outlets.

So, why is Layer 3 facing such skepticism? Why is the "adding a Rollup on top of a Rollup" logic not politically correct? Based on the community discussions, the main focus of skepticism surrounding Layer 3 is whether "Layer 3 truly has scalability significance."

Feasibility Assumptions of Layer 3

From a classic definition, Layer 2 is often defined as a network that relies on the Ethereum mainnet for settlement and possesses scalability; similarly, Layer 3 is defined as a network that relies on Layer 2 for settlement and has greater scalability.

In the context of Layer 2, the so-called "relying on Ethereum for settlement" is technically implemented by: packaging and compressing a large amount of transaction data from Layer 2, then synchronizing it to the Ethereum network, and storing it in the data space of Calldate (an early solution) or Blob (the current solution).

Ideally, if this settlement logic of Layer 2 is feasible, then the logic of Layer 3 relying on Layer 2 for settlement should also hold. Its technical implementation mechanism should be: packaging and compressing a large amount of transaction data from Layer 3, then synchronizing it to the Layer 2 network…

At this point, problems begin to arise.

Since Layer 2 itself does not confirm the "finality" of the network but relies on Ethereum for that, theoretically, the data from Layer 3 should also be submitted to Ethereum, where Ethereum gives the final confirmation.

For the compressed data of Layer 3 that has been submitted to Layer 2, there are two potential submission modes (continue compressing or not compressing anymore), but unfortunately, both modes currently have certain issues.

The Dual Paradox of Layer 3 Data Submission

First, the first potential submission mode is to compress the already compressed data again and submit it to the Ethereum mainnet along with other Layer 2 transaction data.

It sounds good in theory, but the reality is harsh—it's not feasible.

Vitalik wrote an analytical article about Layer 3 in 2022 titled "What Kind of Layer 3 Makes Sense," in which he explained why we cannot compress transaction data multiple times.

Rollup uses a series of compression schemes to reduce the amount of data stored for transactions. A simple transfer can be compressed from about 100 bytes to about 16 bytes, an ERC 20 transfer on an EVM-compatible chain can be compressed from about 180 bytes to about 23 bytes, and a ZK-SNARK transaction can be compressed from about 600 bytes to about 80 bytes. All of the above cases can achieve about 8 times compression efficiency… However, since Rollup still needs to maintain data availability on-chain, ensuring that all data is accessible and verifiable by users, such as independently computing the state of Rollup or joining as a new verification node when existing verification nodes are offline… Data can be compressed once, but cannot be compressed repeatedly. If it could, it would usually mean that we could incorporate the logic of the second compressor into the first, but that also means we could achieve the same effect with just one compression. Therefore, "adding a Rollup on top of another Rollup" does not provide a genuine solution for scalability.

In simple terms, due to data availability considerations, there are inherent limitations to compressing transaction data.

Under this premise, if we could achieve multiple compressions of Layer 3 data by integrating the logic of the second compression into the first, it would also mean we could achieve multiple compressions of Layer 2 data, thus directly achieving the same scalability effect at the Layer 2 level. So why do we still need Layer 3?

The reason is that compression algorithms essentially remove data redundancy to some extent, making the data more compact. However, once these redundancies are removed, it becomes increasingly difficult to compress already compressed data again, as the redundancies that can be eliminated will only decrease. Therefore, data compression is not a process that can be repeated indefinitely, and the benefits of compression are diminishing.

Next, we look at the second potential submission mode, which is to no longer compress Layer 3 data but to submit it directly to the Ethereum mainnet along with other Layer 2 transactions.

This also seems somewhat perplexing because, overall, the main bottleneck currently limiting the scalability effect of the Ethereum ecosystem does not lie in the insufficient block space on Layer 2 (including Layer 3) but rather in the limited data availability capacity of the mainnet—that is, the Blob storage space used to store Layer 2 data is still limited.

Keone Hon, co-founder of Monad, previously stated that the current capacity situation of Blobs is about 3 blobs of 125 kb produced per block (12 seconds), which means about 31.25 kb per second. Given that the size of a transaction is about 100 bytes (slightly higher than the number provided by Vitalik), this means that the shared TPS of all Layer 2 is around 300.

Under this premise, all Layer 2 (including Layer 3) will be constrained by the same data availability limit, which means that even if the block space provided by Layer 2 plus Layer 3 is increased, they still have to queue up one by one to complete the "finality" confirmation.

This is also why Vitalik emphasizes that Layer 3 will not magically improve the scalability situation of the Ethereum ecosystem.

Is Layer 3 Meaningless?

From the above analysis, it can be seen that due to limitations in compression efficiency and data availability, the current Layer 3 does not provide significant effects in terms of general scalability. Does this mean that Layer 3 is purely a "pseudo-concept" with no practical significance? The answer is not so absolute.

Starkware outlined some potential development directions for Layer 3 in "Fractal Scaling: From L2 to L3," suggesting that Layer 2 could operate as a general-purpose network, while Layer 3 could function as a specialized network by enhancing customization features; for example, Layer 2 could focus on trustless scalability, while Layer 3 could focus on weak trust scalability, addressing more challenging issues like data availability by introducing certain external trust conditions.

To conclude, I will borrow a line from Vitalik's article "What Kind of Layer 3 Makes Sense": "Stacking a Rollup on top of another Rollup, especially when both layers use the same technical mechanisms, is clearly not feasible. However, if Layer 2 and Layer 3 have different designs and different goals, such a three-layer scaling architecture is viable."