The logic of "matryoshka dolls" is blocked. Is Layer 3 a pseudo-concept?

24-04-03 13:20
Read this article in 12 Minutes
总结 AI summary
View the summary 收起
Original title: "Expansion Hope or False Concept?" Why is Layer3 so controversial? 》
Original author: Azuma, Odaily Planet Daily


The controversial discussion surrounding Layer 3 has intensified in the past two days.


On the one hand, the related tokens of representative Layer 3 projects such as Degen Chain have increased astonishingly in the past few days - DEGEN itself has a weekly increase of as high as 143.%; After Aavegotchi chose to transform into Base-based Layer 3, GHST also hit a record high.


But on the other hand, doubts about Layer 3 within the community are getting louder and louder. Vitalik even left the stage today to express his objections in person: "Layer 3 does not magically increase throughput."


As yesterday was April Fool's Day, many projects This is the focus, and some jokes about Layer 4 and Layer 5 are made with a bit of ridicule. For example, dYdX once joked that "the new version will be built based on L4". This joke was even reported by some media Treat it as news dissemination.



So, why is Layer3 so questioned? Why is the matryoshka logic of "Rollup plus Rollup" not politically correct enough? Judging from the discussion in the community, the focus of doubts surrounding Layer 3 is mainly on "whether Layer 3 really has expansion significance."


Feasibility hypothesis of Layer 3


From the classical definition, Layer 2 is often defined as a network that relies on the Ethereum main network for settlement and is scalable; by analogy, Layer 3 is defined as a network that relies on Layer 2 for settlement and is more scalable.


In the Layer 2 environment, the so-called "relying on Ethereum for settlement", the technical implementation mechanism is: Layer  ;2 A large amount of transaction data is packaged and compressed, then synchronized to the Ethereum network, and stored through the data space of Calldate (early solution) or Blob (current solution).


Ideally, if the settlement logic of Layer 2 is feasible, then the logic of Layer 3 relying on Layer 2 for settlement seems to also be true. From a technical level The implementation mechanism should be: package and compress a large amount of Layer 3 transaction data, and then synchronize it to the Layer 2 network...


At this step, the problem It's about to start showing up.


Since Layer 2 itself is not responsible for confirming the "finality" of the network, but relies on Ethereum, thenTheoretically Layer 3 The data should eventually be submitted to Ethereum, and Ethereum will "finally make the final decision".


For Layer 3 compressed data that has been submitted to Layer 2, there are two potential submission modes (continue compression or no longer compress) , but unfortunately, no matter which mode there are certain problems for the time being.


Layer 3 Double paradox of data submission


The first is the first potential Submission mode, compresses the compressed data again and submits it to the Ethereum main network together with other Layer 2 transaction data.


It sounds wonderful, but the reality is cruel - no.


Vitalik wrote an analysis article about Layer 3 in 2022, "What kind of Layer 3 is meaningful", in which he explained Why can't we compress transaction data multiple times:


Rollup uses a series of compression schemes to reduce the amount of data stored in transactions. A simple transfer can be approximately 100 bytes can be compressed 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. byte. All the above cases can achieve about 8 times compression efficiency... However, because Rollup still needs to maintain data availability on the chain to ensure that all data is accessible and verifiable by users, such as independently calculating the status of Rollup, or in existing When the verification node is offline, it is added as a new verification node...The data can be compressed once, but cannot be compressed repeatedly. If possible, it usually means that we can put the logic of the second compressor into the first one, but it also means that we could have achieved the same effect with just one compression. Therefore, "putting another Rollup on top of a Rollup" does not have a real expansion effect.


Simply put, due to data availability considerations, there are certain limitations in compressing transaction data.


Under this premise, if we can implement Layer  by integrating the logic of the second compression into the first compression process. 3. Multiple compression of data, which means that we can also directly perform multiple compression on Layer2 data, and then achieve the same expansion effect at the Layer2 level. So why do we still need Layer3?


The reason is that the compression algorithm essentially removes data redundancy to a certain extent, making the data more compact, but once Once these redundancies are removed, it becomes more difficult to compress already compressed data because there is less redundancy to remove. Therefore, data compression is not a process that can be repeated infinitely, and the returns of compression are diminishing.


Then we look at the second potential submission mode, that is, the Layer 3 data is no longer compressed, but directly combined with other Layer 2 The transaction is submitted to the Ethereum mainnet together.


This also feels a bit puzzling, because overall, the main bottleneck currently limiting the expansion of the Ethereum ecosystem is not It’s not that the block space on Layer 2 (including Layer 3) is insufficient, but that the data availability and carrying capacity of the main network is limited - that is, the Blob storage space used to store Layer 2 data is still limited.


Monad co-founder Keone Hon has previously posted that the current Blob capacity is about 3 per block (12 seconds) 125 kb of Blobs, which is 31.25 kb per second, which means all Layer 2 The shared TPS is about 300.


Under this premise, all Layer 2  (including Layer 3) will be subject to the same data availability limit, which makes even Layer  ;2 plus Layer 3 No matter how much block space is provided, they still have to be queued one by one when completing the "finality" confirmation.


This is why Vitalik emphasized that Layer 3 will not magically improve the expansion of the Ethereum ecosystem.


Is Layer 3 meaningless?


Based on the above analysis, it can be seen that due to limitations in compression efficiency and upper limit of data availability, the current Layer 3 cannot provide significant effects in general expansion. . So does this mean that Layer 3 is purely a "pseudo-concept" and has no practical significance? The answer is not so absolute.


Starkware once outlined some potential development directions of Layer 3 in "Layered Capacity Expansion, from L2 to L3", such as Layer 2 It can run as a general-purpose network, and Layer 3 can run as a dedicated network by strengthening customization functions; for another example, Layer 2 can focus on trustless expansion, and Layer 3 can focus on weak trust expansion, that is, through Introduce certain external trust conditions to deal with more difficult issues such as data availability.


Finally, let’s apply Vitalik’s original words in “What kind of Layer 3 makes sense”: “Superimpose a Rollup on top of a Rollup. , especially when the two layers use the same technical mechanism, it is obviously not feasible. However, if Layer 2 and Layer 3 have different designs and different goals, such a three-layer expansion architecture is feasible. ."


Original link

Welcome to join the Rhythm BlockBeats official community:

Telegram subscription group: https://t.me/theblockbeats

Telegram communication group: https://t.me/theblockbeatsApp

Twitter official account: https://twitter.com/BlockBeatsAsia


欢迎加入律动 BlockBeats 官方社群:

Telegram 订阅群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方账号:https://twitter.com/BlockBeatsAsia

举报 Correction/Report
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit