Written by: Vitalik Buterin, co-founder of Ethereum
Compiled by: Dong Yiming, chain catcher
Special thanks to Georgios Konstantopoulos, Karl Floersch and the Starkware team for their feedback and review.
A topic that often resurfaces in Layer 2 scaling discussions is the concept of "Layer 3". If we can build a Layer 2 protocol anchored to Layer 1 with the main purpose of achieving its security and increasing its scalability, then we can certainly achieve security by building a "anchored to Layer 2" and Add more scalability on top of the Layer 3 protocol to expand its scale?
A simple version of this idea is: if you have a solution that allows you to achieve quadratic growth, can you stack that solution on top of itself and get exponential growth? Similar ideas include my 2015 scalability paper and the multi-layer extension mentioned in the Plasma paper. Unfortunately, such a simple Layer 3 concept is not so easy to form a feasible solution. There is always something in the design that is not stackable and will only give you a scalability boost due to data availability constraints, reliance on urgently extracted Layer 1 bandwidth, or many other issues.
Newer ideas around Layer 3, like the framework proposed by Starkware, are more complex: they don't just stack the same thing on top of itself, they assign different uses to Layer 2 and Layer 3. Potential forms of this approach could work if it were done in the right way. This article will detail what may and may not make sense in a three-tier architecture.
Why can't you keep scaling by stacking Rollups on top of Rollups?
Rollups are a scaling technology that combines different technologies to solve the two main scaling bottlenecks of running a blockchain: compute and data. The computation has been solved by approaches such as "fraud proofs" or SNARKs, which rely on a very small number of participants to process and verify each block, requiring others to perform only a small amount of computation to check that the proof process was completed correctly. These schemes, especially SNARKs, are almost infinitely scalable; we can continue to make "SNARKs of many SNARKs" to reduce more computations to a single proof.
The data is different. Rollups use a series of compression techniques to reduce the amount of data that transactions need to store on the chain: a simple currency transfer is reduced from about 100 bytes to about 16 bytes, and an ERC20 transfer in an EVM-compatible chain is reduced from about 180 bytes to about 180 bytes. 23 bytes, a privacy-preserving ZK-SNARK transaction can be compressed from about 600 bytes to about 80 bytes. There is approximately 8x compression in all cases. But Rollup still needs to make the data available on-chain in a medium that ensures users can access and verify it, so that users can independently calculate the state of Rollup and join as certifiers when existing certifiers go offline. Data can be compressed once, but not again - - - If you can, then there is usually a way to put the logic of the second compressor into the first compressor and get the same benefit from compressing it once. So "Rollups on top of Rollups" doesn't actually offer huge gains in scalability, but, as we'll see below, this pattern can be used for other purposes.
So what is the "sane" version of Layer 3?
Well, let's see what Starkware advocates in their post on Layer 3. Starkware was formed by very smart cryptographers, they are sane, so if they advocate layer 3s, their version will be more complex than "if Rollups compress data 8x, then obviously Rollups on top of Rollups will compress data 64x" Much more.
Here's the picture from Starkware's post:
A few quotes:
The image above depicts an example of such an ecosystem. Its L3 includes:
1. StarkNet with Validium data availability, e.g., often used in applications that are extremely sensitive to pricing.
2. Application-specific StarkNet systems customized for better application performance, for example, by employing specified storage structures or data availability compression.
3. StarkEx systems (such as those serving dYdX, Sorare, Immutable and DeversiFi) have Validium or Rollup data availability, immediately bringing proven scalability benefits to StarkNet.
4. The privacy StarkNet instance (also L4 in this example) allows privacy-preserving type transactions to exist without including them in the public StarkNet.
We can condense the article into three visions of “L3”:
L2 is used for expansion, and L3 is used for customization features such as privacy. In this vision, there is no attempt to provide "quadratic growth in scalability"; instead, there is one layer in the stack that helps the application scale, and then there are independent layers to meet the custom functionality needs of different use cases.
L2 is used for general expansion, and L3 is used for customizable expansion. Customizable scaling may come in different forms: specialized applications that use something other than the EVM for computation, data compression rollups optimized for the application-specific data format (including combining "data" with " Proof" separately and replace the proof with a single SNARK) etc.
L2 is used for trustless extensions (Rollups), and L3 is used for weak trust extensions (Validiums). Validium is a system that uses SNARKs to verify calculations, but leaves data availability to a trusted third party or committee. In my opinion, Validium is seriously underrated: in particular, many "enterprise blockchain" applications might actually be better served by a prover running Validium and regularly submitting hashes to a centralized server of the chain. Provide the best service. Validium has a lower security level than rollups, but can be much cheaper.
In my view, all three visions are fundamentally sound. The idea that specialized data compression requires its own platform is probably the weakest claim - it's very easy to design L2 with a common base layer compression scheme that users can autoscale with application-specific subcompressors, but beyond that, These use cases are all legitimate. But that still leaves a big question: Is a three-tier structure the right way to achieve these goals? What's the point of anchoring authentication, privacy systems, and custom environments to L2 instead of just L1? It turns out that the answer to this question is quite complicated.
Do deposits and withdrawals become cheaper and easier in L2's subset tree?
One possible argument for the superiority of the three-tier model over the two-tier model is that the three-tier model allows the entire sub-ecosystem to exist in a single rollup, which allows cross-domain operations within that ecosystem to happen very cheaply without going through expensive L1 Finish.
But it turns out that even between two L2s or even L3s, deposits and withdrawals can be very cheap. The key to this is that tokens and other assets do not have to be issued in the root chain. That is, you can own an ERC20 token on Arbitrum, create a wrapper for it on Optimism, and move back and forth between the two without any L1 transactions!
Let's see how such a system works. There are two types of smart contracts: the base contract on Arbitrum and the encapsulated token contract on Optimism. To transfer from Arbitrum to Optimism, you need to send tokens to the underlying contract, which will generate a receipt. Once Arbitrum is finalized, you can take a Merkle proof of that receipt and root it in L1 state, then send it to the wrapped token contract on Optimism, which verifies it and issues you a wrapped token. To move the token back, you can do the same thing in reverse.
Although the Merkle path required to prove a deposit on Arbitrum goes through the L1 state, Optimism only needs to read the L1 state root to process the deposit - no L1 transactions are required. Please note that since rollups data is the scarcest resource, the actual implementation of this scheme will use SNARK or KZG proofs instead of Merkle proofs directly to save space.
Compared with L1-based tokens, this scheme has a fatal weakness (at least on optimistic rullups): deposits also need to wait for the fraud prevention window. If the token is rooted in L1, withdrawing from Arbitrum or Optimism to L1 requires a one-week delay, but deposits are instant. However, in this scheme, there is a one-week delay for both deposits and withdrawals. That said, it's not clear that a three-tier architecture on top of ideal rollups is better: there are a lot of technical complexities in ensuring that anti-fraud games happening inside a system that itself runs on anti-fraud games are secure.
Fortunately, none of these issues will be an issue with ZK Rollups. For safety reasons, ZK Rollups don't require a week-long waiting window, but they still require a shorter window for two other reasons (first-generation technology could require 12 hours). First, especially the more complex general-purpose ZK-EVM Rollups, take longer to cover the non-parallelizable computation time of the block. Second, economic considerations dictate that certifications need to be submitted infrequently to minimize the fixed costs associated with certification transactions. Next-generation ZK-EVM technology, including specialized hardware, will solve the first problem, while better-architected batch verification can solve the second problem. What we want to discuss next is the issue of optimization and batch submission proof.
Rollups and Validiums have a confirmation time versus fixed cost tradeoff. L3 can help solve this problem, but what else can do this?
The cost of rollups per transaction is cheap: it's just 16-60 bytes of data, depending on the application. But Rollups also have to pay a high fixed cost every time they submit a batch of transactions to the chain: Optimistic Rollups require 21,000 L1 gas per batch, and ZK Rollups require more than 400,000 Gas (if you want to provide quantum security only with STARKS, you need millions of Gas).
Of course, Rollup could simply choose to wait until there is an L2 transaction worth 10 million Gas to submit the entire batch (transaction), but this would give them a very long batch interval, forcing users to wait longer for high security confirm. Therefore, they require a trade-off: longer batch intervals and optimal costs, or shorter batch intervals and greatly increased costs.
To give us some concrete numbers, let's consider a ZK Rollup that costs 600,000 Gas per batch and process a fully optimized ERC20 transfer (23 bytes) that costs 368 Gas per transaction. Assume this Rollups is in early to mid-adoption and has a TPS of 5. We can calculate the gas per transaction and batch interval:
If we move into a world with a lot of custom validation and application-specific environments, many of them will be well below 5TPS. Therefore, identifying the trade-off between time and cost starts to become very important. In fact, the "L3" paradigm does solve this problem! ZK Rollup in ZK Rollup, even a simple implementation, only has a fixed cost of about 8,000 Layer-1 Gas (500 bytes for proof). This will change the table above to:
The problem is basically solved, so is L3 good? Maybe. But it should be noted that there is another way to solve this problem inspired by ERC 4337 aggregate verification.
The strategy is as follows. Today, if every ZK Rollup or Validium receives a proof, it is proof that Snew = STF(Sold,D) : the new state root must be the result of correct processing of transaction data or state increments on top of the old state root. In this new scheme, ZK Rollup will accept a message from the batch validator contract saying that it has verified the proof of a batch of statements, each of which is of the form Snew = STF(Sold,D) . Such batch proofs can be constructed through recursive SNARK schemes or Halo aggregation.
This will be an open protocol: any ZK-Rollup can join, and any batch prover can aggregate proofs from any compatible ZK-Rollup and receive compensation for transaction fees from the aggregator. The batcher contract will verify the proof once and then deliver a message to each Rollup with the ( Sold, Snew, D) triple of that sollups. The fact that the triple came from the batcher contract will be used as evidence that the transformation is Effective.
If optimized properly, the cost per rollup in this scenario could be closer to 8000, with 5000 for adding the newly updated state writes, 1280 for the old and new roots, and an additional 1720 for miscellaneous data processing. So it will give us the same savings. Starkware actually already has something similar, called SHARP, although it's not (yet) a permissionless open protocol.
One response to this approach might be: But isn't this really just another Layer 3 approach? Instead of base layer <- rollup <- validium we will have base layer <- batch mechanism <- rollup or validium. From the perspective of a certain philosophical framework, this may be true. But there is an important difference: the middle layer is not a complex full EVM system, but a simplified and highly specialized object, so it is more likely to be secure, and it is more likely to work without another specialized token. Situationally constructed, it is more likely to be minimally governed and not change over time.
Conclusion: What exactly is a "Layer"?
Three-tier scaling architectures consisting of identical scaling schemes stacked on top of themselves generally don't work well. The form of Rollups on top of Rollups (where two layers of Rollups use the same technology) is also unsatisfactory. However, a three-tier architecture with L2 and L3 serving different purposes could work. Validiums on top of Rollups do make sense, even if they're not definitely the best way to do things in the long term.
However, once we start getting into the details of which architecture makes sense, we get into philosophical questions: What are "layers" and what are not? base layer <- batch mechanism <- rollup or validium and base layer <- rollup <- rollup or validium do the same job, but in terms of how they work, the proof aggregation layer looks more like ERC-4337 than rollups . Normally, we would not refer to ERC-4337 as "layer 2". Likewise, we won't call Tornado Cash "Layer 2", so if we want to be consistent, we won't call the privacy-focused subsystem that sits on top of L2 L3. So, in terms of what should come first Called "Layer", there is an unresolved semantic debate.
There are many possible schools of thought in this regard. My personal preference is to limit the term "Layer 2" to things that have the following properties:
1. Their purpose is to improve scalability
2. They follow the "blockchain within a blockchain" model: they have their own transaction processing mechanism and their own internal state
3. They inherit all the security of the Ethereum chain
Therefore, ideal Rollups and ZK Rollups are L2, but verification, proof aggregation schemes, ERC 4337, on-chain privacy systems and Solidity are another matter. It might make sense to call some of them L3, but probably not all; in any case, it seems too early to nail down a definition, and the architecture of a multi-aggregation ecosystem is far from set in stone, with most discussions taking place only in theory.
That is, the linguistic debate is less important than the technical question of which structure actually makes the most sense. Clearly, certain "Layers" serving non-scaling needs such as privacy have an important role to play, and the important functionality of proof aggregation needs to be filled in some way, preferably through open protocols. But at the same time, there are good technical reasons to make the middle layer linking the user-facing environment and L1 as simple as possible; in many cases, being the "glue layer" for EVM rollup may not be the right approach. I suspect that as the L2 extension ecosystem matures, the more complex (and simpler) structures described in this article will start to play a greater role.
Original link:
https://vitalik.ca/general/2022/09/17/layer_3.html
**This article only represents the views of the original author and does not constitute any investment opinions or recommendations.
-END-
[The purpose of publishing articles is to disseminate more valuable information. The copyright of the article belongs to the original author. Its content and opinions do not represent the position of Unitimes. The pictures appearing on this WeChat platform are all collected from the Internet, and the copyright belongs to the copyright owner. If the copyright owner believes that his work is not suitable for everyone to browse or should not be used for free, please add WeChat uniforms2018 to contact us, and this platform will make corrections immediately. 】
Just click " Like " when you come.
