IOBC Capital: Will Layer3 be the new direction for Ethereum?

Source: IOBC Captial

Vitalik discussed the concept of Layer 3 in a recent article. So, what is Layer 3?

Let's briefly review Layer 1 and Layer 2 first.

Early public chains, especially Ethereum, had their ecosystem development constrained by network performance, with a relatively low number of transactions per second (TPS), frequent network congestion, and expensive transaction GAS fees, making it difficult to support high-performance applications. To enhance network scalability, various scaling solutions have been proposed.

There are mainly two routes for scaling:

• One is to scale on the original blockchain itself, that is, scaling on Layer 1, allowing the blockchain to have higher transaction capacity and processing speed.

  The main issue with this solution is: if scaling is achieved through larger blocks, then blocks become harder to verify, and the network becomes more centralized.

• The second is to add a layer on top of the blockchain, commonly referred to as Layer 2 scaling. This approach does not place all activities (such as computation, storage, consensus) directly into the original chain (a monolithic Layer 1 blockchain), but instead processes a series of transactions through a modular execution layer, which consists of some off-chain Layer 2 protocols. The smart contracts on-chain only perform two tasks: handling deposits and withdrawals, and verifying that all off-chain activities comply with the rules.

During the discussion of Layer 2 scaling, a new concept gradually emerged—Layer 3.

Layer 3 is based on the idea that:

If Layer 2 protocols can be added on top of Layer 1 to help process transactions, thereby enhancing security and scalability, then can we also add additional Layer 3 protocols on top of Layer 2 to further increase security and scalability?

This idea sounds good, but it faces many practical issues that make such a scaling solution difficult to stack simply.

1. Is it feasible to continuously scale by stacking more layers?

Rollup is a scaling technology primarily aimed at addressing the two major bottlenecks of blockchain operation: computation and data.

The computation bottleneck can be solved by fraud proofs or SNARKs, relying on a small number of people to process blocks, while others only need to perform a small amount of computation to verify the correctness of these processing results.

These solutions, especially SNARKs, can scale almost indefinitely, as many computations can be compressed into a single proof by applying SNARKs on top of SNARKs.

However, data is different. Rollup uses a series of techniques to reduce the amount of data that needs to be on-chain for a transaction; for example, the size of a simple currency transfer is compressed from 100 bytes to 16 bytes, and a privacy-protecting ZK-SNARK transaction can be compressed from 600 bytes to 80 bytes.

However, Rollup still needs to maintain on-chain data availability. This means that on-chain data must be accessible and verifiable for users, allowing them to independently compute and verify the state of the Rollup and join as validators when existing validators are offline.

Data can only be compressed once; the same compression logic cannot be applied to already compressed data.

Therefore, the solution of Rollups on Rollups (multi-layer stacking) does not actually provide more benefits in terms of scalability.

However, the Layer 3 model can be used for other purposes.

2. If it is not suitable for general scaling, what is a reasonable use for Layer 3? Polynya introduced a feasible Web3 network in the article "Fractal Scaling." The article mentions that trying to fit everything into one server and parallelizing within one server is far less effective than bringing the concept of parallelism to the next layer, that is, adding a Layer 3 for parallel processing, which can extend content across multiple servers. By using a fractal approach for parallelism and specific scaling, this is where we need Layer 3. Any computation-intensive application will require customized rollups for the application. This approach has several benefits:

• Optimized applications with zero virtual machine overhead
• No MEV, or limited MEV, meaning harmful MEV can be mitigated through simple solutions
• Fine-tuning hardware for specific purposes (general chains will always have some bottlenecks unsuitable for certain applications).
• Addressing the transaction quality triangle—allowing for low transaction fees while still avoiding spam through targeted anti-DDoS solutions.

Starkware has also proposed their Layer 3 solution. The recursive concept they adopt can even be applied to more layers to achieve fractal hierarchical solutions. Their proposal showcases examples of this ecosystem, as shown in the figure below.

Its Layer 3 includes:

• StarkNet with Validium data availability, primarily for applications that are particularly sensitive to price.
• A StarkNet system with better application processing performance specifically designed for apps, such as those using specially designed storage structures.
• The StarkEx system serving platforms like dYdX, Sorare, Immutable, and DeversiFi, which have Validium or Rollup data availability, providing scalability advantages to StarkNet.
• Privacy StarkNet instances (also serving as L4 in this example) can facilitate privacy-protecting transactions without including them in the public StarkNet.

Starkware mentioned three visions regarding Layer 3 in their article, which Vitalik also acknowledged in his article:

1. Custom functionality. That is, Layer 2 is used for scaling, and Layer 3 is used for specific functions, such as privacy. In this vision, there is no attempt to provide "the square of scalability," but rather a layer in the stack specifically to help applications scale, while other layers provide customized functionalities for different use cases.
2. Custom scalability. That is, Layer 2 is used for general scaling, and Layer 3 is used for customized scaling. Customized scaling can take different forms: special applications that do not use EVM for computation, Rollups that optimize data formats for specific applications, etc.
3. Custom security. That is, Layer 2 is used for trustless scaling (rollups), and Layer 3 is used for weak trust scaling (validiums). Validium is a system where SNARKs are used to verify computations, but data availability is placed with a trusted third party or committee off-chain. Vitalik believes that Validiums are severely underestimated: for most "enterprise blockchain" applications, running a validium prover and regularly submitting hashes to the chain from a centralized server can meet the needs. Although the security of Validium is not as strong as that of rollups (due to centralization), their costs are much lower.

3. The costs of Layer 3

Rollups and validiums need to balance confirmation time and fixed costs. But Layer 3 can address these.

The fees for each transaction in a Rollup are very low: depending on the application, it is about 16-60 bytes of data.

However, Rollups also have a high fixed cost, stemming from the need to submit a batch of transactions to the Layer 1 chain each time: if it is an optimistic rollup, it requires 21,000 Layer 1 gas per batch; if it is a ZK rollup, it exceeds 400,000 gas; and if it is a quantum-safe STARK, it requires over a million gas.

Of course, Rollups can simply choose to wait until there are transactions worth 10 million gas before submitting the entire batch, but this would result in very long batch intervals, forcing users to wait longer for high-security confirmations.

Thus, they need to weigh different options: longer batch intervals with optimal costs, or shorter batch intervals with increasing costs.

Vitalik illustrated a case with a batch cost of 600,000 gas for a ZK rollup and a per-transaction cost of 368 gas for a fully optimized ERC20 transfer (23 bytes). Assuming this rollup is in the early adoption phase with a TPS of 5, the gas per transaction and batch interval can be calculated:

If there are a large number of customized Validiums and tailored environments for apps, they may not need to utilize 5 TPS. In fact, Layer 3 can indeed solve this problem. The Layer 1 cost in ZK rollups is only about 8,000 gas (500 bytes for the proof). This will change the above table to:

4. What are the advantages of Layer 3?

The advantages of Layer 3 include:

• Better scalability: Derived from the multiplicative effect of using recursive proofs.

• Application designers building Layer 3 have better control.

• Privacy: For example, zero-knowledge proofs applied to privacy-protecting transactions on open Layer 2.

• Cheaper/simpler Layer 2-Layer 3 interoperability:

  Currently, the processes of depositing and withdrawing between Layer 1 and Layer 2 are very expensive. In contrast, due to the cost-effectiveness of Layer 2, these processes are not only attractive when applied to Layer 3 but also easy to implement. Although the latency of moving assets between Layer 2 and Layer 3 may be longer than the latency between applications deployed on the same Layer 2, the costs and throughput are proportional.

• Cheaper/simpler Layer 3-Layer 3 interoperability: Independent Layer 3s will interoperate through Layer 2 rather than Layer 1. Layer 2 is clearly cheaper than its Layer 1. Without Layer 3, these would all run on Layer 2, necessitating interoperability through relatively expensive Layer 1.

• Layer 3 as a "canary" network for Layer 2: New innovations can be tested on Layer 3 before being made available to the public on Layer 2 or Layer 3 (similar to the role of Kusama in Polkadot).

6. Implementation of Layer 3 Starkware introduced the specific implementation of Layer 3 in their proposal.

A classic Layer 2 structure includes the following components:

• A smart contract that tracks the state root of Layer 2 on Layer 1 (for example, StarkNet smart contracts on Ethereum)

• A Verifier smart contract to prove the validity of state transition proofs

• A bridge contract on Layer 1 to manage the tokens coming in and out of Layer 2

• A token contract on Layer 2 to serve as the counterparty for tokens on Layer 1, such as ERC20, ERC721

A fractal Layer 3 structure is illustrated below. By placing state tracking and Verifier smart contracts on Layer 2, Layer 3 can securely operate on Layer 2 using validity proofs. When Layer 2 also uses validity proofs submitted to Layer 1, this will create a very elegant recursive structure, where the compression advantages of Layer 3 proofs can exponentially increase the compression advantages of Layer 2 proofs.

7. Layer 3—Choices for DApp Developers

For dApp developers, there are several choices regarding infrastructure:

1. Develop a Rollup (ZK Rollups or Optimistic Rollups) yourself. The advantage is that you can inherit Ethereum's ecosystem (users) and its security, but for a dApp team, the development costs of a Rollup are clearly too high. 2. Choose Cosmos, Polkadot, or Avalanche. The development costs will be lower (for example, dydx chose Cosmos), but you will lose Ethereum's ecosystem (users) and security. 3. Develop a Layer 1 blockchain yourself. This brings high development costs and difficulty but allows for the highest level of control. Let's compare the three scenarios: Difficulty/Cost: Alt-layer 1 > Rollup > Cosmos Security: Rollup > Cosmos > Alt-layer 1 Ecosystem/Users: Rollup > Cosmos > Alt-layer 1 Control: Alt-layer 1 > Cosmos > Rollup As a dApp developer, if you want to inherit the security and traffic of Ethereum, you cannot redevelop a chain; you can only choose Rollup. However, developing a Layer 2 Rollup yourself is very expensive, so the appropriate solution becomes to use the Layer 3 SDK to develop your own application-specific Rollup (application-specific rollup), that is, Layer 3.

8. Conclusion

Layer 2 can reduce the gas cost per transaction and improve on-chain scalability. At the same time, Layer 2 retains the benefits of decentralization, general logic, and composability. Through the design of recursive structures, Layer 3 may also inherit these advantages from Layer 2.

Currently, a common viewpoint is that some applications require specific customized services, which will be provided by Layer 3.

Layer 3 may open up a new space for Ethereum or blockchain, just like Rollup. However, there are still many technical details that need to be resolved, and this will take time.

Since 2020, there has been little innovation at the application layer. The past reasons for the lack of explosive growth in blockchain applications often cite the insufficient performance of existing public chains to support high-computation, high-concurrency applications, a mindset that remains rooted in the era of monolithic blockchains. However, with the maturation of Layer 3 solutions, a new batch of applications is expected to emerge, which can only be realized under fractal scaling conditions. On-chain games or similar projects that rely heavily on computation may become the first batch of projects to deploy their own Layer 3.