Vitalik: What kind of Layer3 is meaningful?
Original title: "What kind of layer 3s make sense?"
Original author: Vitalik
Original compilation: 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 3s". If we can build a layer 2 protocol anchored to layer 1 to achieve its security and increase its scalability as the main purpose, then of course we can build a "anchor to layer 2 to achieve security, and in its A layer 3 protocol that adds more scalability on top of it to scale up?
A simple version of this idea is: if you have a solution, you can Letting you achieve quadratic growth, can you stack this scheme on top of itself and get exponential growth? Similar ideas include my 2015 scalability paper and in Plasma paper, etc. Unfortunately, such a simple concept of layer 3s is not so easy to form a feasible solution. Due to data availability constraints, reliance on layer 1 bandwidth for urgent fetches, or many other issues, there will always be something in the design that is not stackable and will only give you a scalability boost once.
Newer ideas around layer 3s like Starkware's framework is more complex: they don't just stack the same thing on top of themselves, they assign different uses to layer 2 and layer 3. A potential form of this approach might work if it's done in the right way. This post will detail what might and might not make sense in a three-tier architecture.
Why can't you keep scaling by stacking rollups on top of rollups?
Rollups (see my here ) is a scaling technique that combines different technologies to solve the two main scaling bottlenecks of running a blockchain: computation and data. Computations have been solved by methods such as "fraud proofs" or SNARKs, which rely on extremely A small number of participants process and verify each block, requiring others to perform only a small amount of computation to check that the proof process was done correctly. These schemes, especially SNARKs, scale almost infinitely; we can continue to make "SNARKs of many SNARKs" to reduce more computations into a single proof.
The data is different. Rollups use a series of compression techniques to reduce the amount of data a transaction needs to store on-chain: Simple currency transfers reduced from about 100 bytes to about 16 bytes, ERC20 transfers in EVM compatible chains from ~180 words section is reduced to about 23 bytes, and a privacy-preserving ZK-SNARK transaction can be compressed from about 600 bytes to about 80 bytes. Approximately 8x compression in all cases. But rollups still need to make data available on-chain in a medium that is guaranteed to be accessible and verifiable by users, so that users can independently compute the state of the rollup and join as provers if existing provers go offline. The data can be compressed once, but not again - - - If it can, then there is usually a way to put the logic of the second compressor into the first and get the same benefits by compressing once. So, "Rollups on top of Rollups" doesn't actually provide 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?
Okay, let's see what Starkware is advocating in their post about layer 3s. Starkware was formed by very smart cryptographers, they are sane, so if they advocate l ayer 3s, their version will be more complicated than "if rollups compress data by a factor of 8, then obviously rollups on top of rollups will compress data by a factor of 64".
Here is the image from the Starkware post:
A few quotes:
The diagram above depicts one such ecosystem example. Its L3 includes:
1. StarkNet with Validium data availability, eg, often used in extremely pricing-sensitive applications.
2. Application-specific StarkNet systems tailored for better application performance, for example, by employing specified storage structures or data availability compression to fulfill.
3, StarkEx systems such as those serving dYdX, Sorare, Immutable and DeversiFi have Validium or Rollup data availability, bringing proven scalability advantage.
4. A private StarkNet instance (also acting as L4 in this example) allows privacy-preserving types of transactions to exist without including them in the public StarkNet.
We can condense the article into "Three Visions of "L3s"":
· L2 is used for scaling and L3 is used for custom features such as privacy. In this vision, there is no attempt to provide "quadratic scalability growth"; instead, there is a layer in the stack that helps the application scale, and then there are separate layers to meet the custom functional requirements of different use cases.
· L2 is used for general expansion, and L3 is used for customized expansion. Customizable scaling can come in different forms: specialized applications that use something other than the EVM for computation, data compression rollups that are optimized for a specific application's data format (including combining "data" with " proof" and replace the proof with a single SNARK), etc.
· L2 is used for untrusted extensions (rollups), and L3 is used for weak trust extensions (validiums). Validium is a system that uses SNARKs to validate computations, but leaves data availability to trusted third party or committee. In my opinion, Validium is grossly underestimated: in particular, many "enterprise blockchain" applications might actually be best served by a prover running validium and periodically submitting hashes to the chain's centralized server Provide the best service. Validium is less secure than rollups, but can be much cheaper.
In my It appears that all three visions are largely plausible. The idea that specialized data compression requires its own platform is probably the weakest proposition - it's very easy to design L2 with a general base layer compression scheme that users can auto-scale with application-specific sub-compressors, but otherwise, These use cases are all reasonable. 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? The answer to this question turns out to be quite complicated.
Do deposits and withdrawals become cheaper in subset trees in L2 , easier?
One possible argument for the three-tier model over the two-tier model is that the three-tier model allows an entire sub-ecosystem to exist within a single rollup, which allows The cross-domain operations can happen very cheaply without going through the expensive L1.
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 Token and other assets do not have to be issued in the root chain. That is, you can have an ERC20Token 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 encapsulation 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, and send it to the wrapping token contract on Optimism, which verifies it and issues you a wrapping token. To move the token back, you can do the same thing in reverse.
Although in proving Arbitrum The Merkle path required for a deposit is through the L1 state, Optimism only needs to read the L1 state root to process the deposit - no L1 transaction required. Note that since rollups data is the scarcest resource, a practical implementation of this scheme would use SNARK or KZG proofs instead of Merkle proofs directly to save space.
Compared with L1-based Token, this scheme has a fatal weakness (at least on optimistic rullups): the deposit still needs to wait Fraud window. Withdrawing from Arbitrum or Optimism to L1 requires a one-week delay if the token is rooted in L1, but deposits are instant. In this scheme, however, 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's a lot of technical complexity in making sure a fraud game happening inside a system that itself runs on a fraud game is secure.
Fortunately, none of these problems will be a problem with ZK rollups. For security reasons, ZK rollups do not require a week-long waiting window, but they still require a shorter window (perhaps 12 hours for first-gen technology) for two other reasons. First, especially the more complex generic ZK-EVM rollups take longer to cover the non-parallelizable computation time of blocks. Second, due to economic considerations, attestations need to be submitted infrequently to minimize the fixed costs associated with attesting transactions. Next generation ZK-EVM technology including dedicated hardware will solve the first problem , and better structured batch verification can solve the second problem. It is the problem of optimization and batch submission of proofs that we will discuss next.
Rollups and validiums have a confirmation time vs. fixed cost tradeoff. L3 can help with this, but what else can do the same?
Rollups are cheap per transaction: it's just 16-60 bytes of data, depending on the application. But rollups also have to pay high fixed costs every time they submit a batch of transactions to the chain: optimistic rollups need 21000 L1 gas per batch< /a>, and ZK rollups are over 400,000 gas (millions of gas if you want to provide quantum-safe stuff with only STARKS).
Of course, rollups could simply choose to wait for 10 million gas worth of L2 transactions to submit the full batch, but this would take a very long time for them The batch interval of , forcing users to wait longer for high-security confirmations. Therefore, they come with a trade-off: longer batch interval and optimal cost, or shorter batch interval and greatly increased cost.
To give us some concrete numbers, let's consider a fully optimized ERC20 transfer (23 bytes) that costs 600,000 gas ZK rollup per batch and processes 368 gas per transaction. Assume this rollup is in the early to mid stages of adoption with a TPS of 5. We can calculate the gas for each transaction and batch interval:
If we Enter a world with a lot of custom validation and application-specific environments, many of which will be well below 5TPS. Therefore, the trade-off between confirmation time and cost starts to become very important. In fact, the "L3" paradigm does solve this problem! ZK rollups in ZK rollups, even for naive implementations, only have a fixed cost of about 8,000 layer-1 gas (500 bytes for proofs). This will change the above table to:
The problem is basically solved, so is L3s good? Maybe. But it should be noted that there is another way to solve this problem is subject to ERC 4337 aggregation verification inspired.
The strategy is as follows. Today, if each ZK rollup or validium receives a proof that Snew = STF(Sold,D): The new state root must be the result of correctly processing 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 that it has verified a proof of a batch of statements, where each statement is of the form Snew = STF(Sold,D). Such batch proofs can be constructed via 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 pass a message to each rollups with the (Sold, Snew, D) triple. Triple fact for that sollups from the batcher contract will be used as evidence that the transformation works.
If optimized properly, the cost per rollup in this scenario could be closer to 8000, with 5000 for state writes adding new updates and 1280 for old roots and new root, and an additional 1720 for miscellaneous data processing. So it will give us the same savings. Starkware actually has something similar already, called SHARP, although it's not (yet) a Licensed Open Protocol.
One response to this approach might be: Isn't this really just another layer 3 approach? We will have base layer <- batch mechanism <- rollup or validium instead of base layer <- rollup <- validium. From the point of view 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 safe, and it is more likely to be used without another dedicated Token Constructed under the circumstances, it is more likely to be minimally governed and not change over time.
Conclusion: What exactly is "Layer"?
A three-tier scaling architecture consisting of stacking the same scaling scheme on top of itself usually doesn't work well. The form of rollups on top of rollups (where two layers of rollups use the same technique) is also less than ideal. However, a three-tier architecture where L2 and L3 have different purposes can work. Validiums on top of rollups do make sense, even if they're not sure the best way to do things in the long run.
However, once we start to get into the details of which architecture makes sense, we get into philosophical questions: what are "layers" and what aren't? base layer <- batch mechanism <- rollup or validation and base layer <- rollup <- rollup or validation do the same job, but the proof aggregation layer looks more like ERC-4337 in terms of how it works , instead of rollups. Usually, we don't refer to ERC-4337 as "layer 2". Likewise, we don't refer to Tornado Cash as "Layer 2", so if we want to be consistent, we don't refer to the privacy-focused subsystem that sits on top of L2 as L3. There is an unresolved semantic debate over what should be called a "Layer" in the first place.
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
< br>
3. They inherit all the security of the Ethereum chain
Therefore, the ideal rollups and ZK rollups are L2, but Verification, proof aggregation schemes, ERC 4337, on-chain privacy systems, and Solidity are another. Calling some of them L3 might make sense, but probably not all; in any case, it seems too early to settle on a definition, and while the architecture of the multi-aggregate ecosystem is far from set in stone, most discussions are only theoretical.
That said, the linguistic debate is less important than the technical question of which structure actually makes the most sense. Clearly, certain "layers" that serve non-scaling needs like privacy can play an important role, and the important functionality of proof aggregation needs to be populated in some way, preferably through an open protocol. But at the same time, we have good technical reasons to make it as simple as possible to link the middle layer facing the user environment and the L1; in many cases, the "glue layer" that acts as an EVM rollup may not be the right approach. My guess is that as the L2 scaling ecosystem matures, the more complex (and simpler) structures described in this article will start to play a bigger role.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
