Layer 3 in-depth

Yihan Xu@Foresight Ventures

1. From layer 1 to layer 3

Layer 1 is the base network, for example, Ethereum, Bitcoin, and Solana are all layer 1 blockchains.

Layer 2 is a set of Ethereum scaling solutions. They are separate blockchains that aim to boost throughput and reduce cost while inheriting the security of Ethereum. For example, Arbitrum, Optimism, and Zksync are all layer 2 blockchains.

what is Layer 3?

In summary, layer 3 is expected to carry out some customized designs that layer2s cannot achieve easily, including customized scaling and privacy-preserving, etc.

The idea of layer 3 is in the early stage, but experts had purposed several related proposals. First, let’s take a look at the multi-layers architecture, I will do further analysis, which might help you gain a clear outline of layer 3.

2. The multi-layer network by Starkware

This Ethereum multi-layer architecture was first proposed by the StarkWare team in “Fractal Scaling: From L2 to L3”. In this architecture design, the current layer2 serves as a general-purpose scaling, while layer3 accomplishes customized scaling.

The following section shows an analysis of this architecture.

a. StarkEx Volition（rollup+validium） → low-cost scaling

You probably know Validium, a blockchain scaling solution that uses zero-knowledge proof to verify the computation result and utilizes validators, instead of layer 1, to guarantee data availability. Since the transaction data is not stored on the Ethereum main net, Validiums provides higher levels of throughput at a relatively low cost. However, the trade-off of the off-chain data availability is the relatively lower security and the demand for trust assumptions.

The StarkEx Volition provides Dapps with more choices of scaling. Projects can choose StarkEx Rollup for the higher security or StarkEx Validium for a lower cost. Currently, StarkEx is still a layer2 scaling solution, but in the multi-layer architecture, StarkEx can be updated to a layer3 architecture, which builds on top of Starknet and carries out a more customized and cheaper scaling solution.

b. App-specific StarkNet → customized scaling

Take zk-rollup as an example, the general-purpose scaling design means those circuit designs sacrifice efficiency to some degree, which can be a bottleneck for applications that lay strong emphasis on the interaction of millions of potential players. The app-specific circuit design of layer 3 can help those games to achieve better performance and lower cost. Also, a game application does not have to share circuit resources with other Dapps.

In this scenario, layer 2 solves the programmability and the composability problem, while layer 3 provides a customized design for superior performance.

c. StarkNet（Validiums） → low-cost scaling

Similar to StarkEx Volition, StarkNet(Validiums) provides a low-cost scaling solution for Dapps that are sensitive to cost.

d. Privacy StarkNet → customized functionality

The implementation of privacy StarkNet can be regarded as an app-specific design. In consideration of the security and data availability, transaction data still needs to be compressed and post on layer 1 as a history log.

3. Again, what is layer 3？

The previous analysis might give you a brief idea about what layer 3 might look like. In this section, I will summarize the problem that layer 3 is trying to solve.

Vitalik’s vision

1. L2 is for scaling, and L3 is for customized functionality.
2. L2 is for general-purpose scaling, L3 is for customized scaling
3. L2 is for trustless scaling (rollups), L3 is for weakly-trusted scaling (valium)

Further Interpretation

1. Since layer2 serves as a general-purpose scaling solution, the purpose of layer3 can be quite another thing, to realize the functionality that layer2 cannot achieve easily, such as privacy;
2. Current zk-rollup emphasizes compatibility, it provides a scaling solution that fits all Dapps. Hence, this design has a trade-off: The underlying ZK(E)VM is less zk-friendly. In this case, layer 3 can be an app-specific scaling solution for superior performance, designing customized circuits depending on the demand of a specific Dapp.
3. In order to ensure data availability, zk-rollup has to push compressed data to layer 1, which brings more gas. Instead, Validium avoids this part of the cost and resulting in a lower price. From this perspective, layer 3 can be a low-cost scaling solution, which means projects have more choices depending on their use case.

Layer3 as a further scaling solution is mentioned on both 2 and 3, then what’s the difference？

They serve different purposes and solve different pain points that current layer 2 faces. The app-specific design mentioned in the second point is for performance boosting, while the third point aims for a more general-purpose but low-cost scaling solution.

All the proposals mentioned above can potentially be the development orientation of layer 3. Some of the Dapps need more functionalities than simply scaling, some Dapps will benefit from low-cost scaling, and some projects acquire better performance by adopting app-specific design.

In a word, layer 3 will improve the performance in various ways and create more possibilities for the whole ecosystem.

4. Is layer 3 necessary？

There are two questions emerge:

1. Layer 3 is awesome, why not keep stacking layers to achieve “ultimate scaling”?
2. Check out the diagram from Vitalik. Instead of stacking another layer on top of the current layer2, stuffing all those architectures into layer2 seems feasible. Validium can be a layer2 and still cost less gas; App-specific design still delivers superior performance, and it is viable to create a roll-up with privacy. Then why expend beyond layer 2?

Can we improve the scalability infinitely？

The answer is NO.

From the computation perspective

Considering the zk-rollup, which is more suitable for the idea of “stacking layers” than optimistic rollup. Theoretically, layer 3 zk-rollup can generate zkps and send them to layer 2 zk-rollup, and then layer 2 generates a zkp to prove a heap of zkps from layer 3.

That presumption works from the computation perspective.

From the data perspective

Except for the computation, we still need to put data storage into count. Rollup still needs to send transaction data to layer 1 to make sure everyone can become a validator and verify the authenticity of the proof. That procedure ensures data availability. It turns out that the data cannot be further compressed. Therefore, the improvement of scalability is limited.

That presumption does not work from the data perspective.

We can refer to what Vitalik mentioned in his article: “There’s always something in the design that’s just not stackable, and can only give you a scalability boost once — limits to data availability, reliance on L1 bandwidth for emergency withdrawals, or many other issues.”

Two-layer or multi-layer architecture?

I believe the two-layer network is the most cost-efficient solution for now, but the future of Ethereum belongs to multi-layer architecture.

To prove that point, we have to be clear about the value of layer 3.

5. The value of layer 3

In summary: to reduce cost and improve efficiency.

Cost breakdown

One of the most significant benefits of layer 3 is the optimization of cost. There might be other awesome killer designs of layer 3, but the cost is always the biggest concern.

Taking into consideration cutting gas fees, the current layer2 cannot submit a batch of transactions to layer1 too frequently, for example, submitting once per Ethereum block time, which is around 12~14 seconds. Mainly because of the following two facts:

1. There is a base cost every time submitting a batch to layer 1, according to Vitalik, more than 400,000 gas per batch for zk-rollup;
2. The number of transactions that rollup is about to pack is limited in a short among of time.

Based on the facts above, the more transactions packed in a batch, the less gas allots to each transaction. In other words, submitting batches frequently is diseconomy.

Therefore, the roll-up design needs to consider the trade-off between confirmation time, which directly associates with user experience, and the cost for every transaction.

The impact of introducing layer 3

If layer 3 is brought in, for example, a zk-rollup on top of the current layer2 zk-rollup, will vastly reduce the base cost. One reason is using one zkp to prove many zkps. According to Vitalik, the base cost of submitting a batch to layer 1 would then become 8000 gas.

Let’s do a simple math based on the data mentioned by Vitalik

Known:

1. gas per transaction = transaction cost + batch cost / transaction amount
2. transaction cost = TPS * batch interval

— > gas per transaction = TPS * batch interval + batch cost / transaction amount

Under ideal situation:

1. batch cost = 400,000 gas
2. transaction cost = 368 gas
3. TPS = 5
4. batch interval = confirmation time

Current layer 2 cost:

1. confirmation time = 12s（Ethereum block time）
2. gas per transaction = 368 + 400000 / （5 * 12）= ～7035
3. confirmation time = 1h
4. gas per transaction = 368 + 400000 / （5 * 3600）= ～390

Under the current layer2 design, gas per transaction has a strong correlation with the batch interval, which refers to confirmation time on the user side. Keeping confirmation time in a short interval results in a much higher cost.

After introducing layer 3:

1. confirmation time = 12s（Ethereum block time）
2. gas per transaction = 368 + 8000 / （5 * 12）= ～501
3. confirmation time = 1h
4. gas per transaction = 368 + 8000 / （5 * 3600）= ～368

Summary:

1. The impact of layer 3 is significant. Extending confirmation time from 12 seconds to 1 hour, which means including more transactions in each batch, does not bring many financial benefits. Meanwhile, layer 3 achieves almost the same level of cost in a short amount of time(12s) as layer 2 reaches in 1 hour. That architecture greatly cuts costs while still ensuring the user experience.
2. Another point that has been overlooked is that layer 3 is more suitable for being an app-specific or customized solution. Because of the reduction of batch cost, the increase in transactions per batch won’t bring too many benefits in terms of gas fees, which also means layer 3 does not rely on the trading frequency of rollup to offset the base cost per batch.

Efficiency breakdown

Similar to cost, the purpose of designing a multi-layer network must include efficiency.

The implementation of wrapped tokens reduces the interoperation cost between layer2 rollups, but the efficiency still remains to be improved.

Optimistic rollup → 14 days

Due to the fraud-proof mechanism, depositing in one roll-up and then withdrawing in another each takes ~7 days.

ZK-rollup → better than optimistic rollup, ～12h

Zk-rollup avoid trust assumption, but still has the following two problems:

1. The current ZK(E)VM is designed to be “one Virtual Machine fits all Dapps,” which means it compromise with some zk-unfriendly circuit designs, which results in the overhead of handling certain command when generating zkp;
2. As mentioned previously, the current rollup has to consider the trade-off between confirmation time and cost, which means the batch interval cannot be too small.

After introducing layer3:

1. Layer3 is designed to be a customized and app-specific scaling solution, which means the overhead of generating zkp can be optimized based on specific Dapp.
2. Based on the previous computation results, layer 3 improves efficiency while promising a reasonable cost. Compared to the two-layer network, the operation does not need to go through layer 1, which is expensive and congested, every time, 。

Summary

To sum up this section, the multi-layer network further keeps the functionality of layer 1 simple, which is ensuring security, and moving other functions, such as computing, to the sub-system.

6. Another layer3 design

Vitalik mentioned another design pattern in his article, which also can be regarded as a multi-layer structure.

Layer1: base layer

Layer2: batch mechanism

Layer3: rollup、validium

Interpretation of this architecture

In short: an interlayer, which integrates aggregation, verification, and distribution, between current layer 1 and layer 2.

To be more specific, a batch mechanism that operates as an open protocol, which allows current layer 2 rollups to join.

The core function of this batch mechanism are the following:

1. A batch prover aggregate proof from different zk-rollups and record every new state, previous state, and state changes;
2. A batch handler only needs to verify the aggregated proof once. Then, it sends the verification result together with a tuple in the format like [new state, previous state, state changes] to each roll-up, as evidence for them to update the state.

Again, the value of layer3

Lower cost

Compared to the current layer1, in which each verifier contract verifies batch proofs from different rollups, the new design apportions the cost between each roll-up. According to Vitalik, the cost would be as low as ~8000 gas.

Higher Security

This batch mechanism is specially designed for a specific purpose. The focused function makes this layer more secure and can be governance-minimized.

*SHARP from Starkware is doing something similar(the recursively proof mechanism shown in the graph below). Check out their article at: https://medium.com/starkware/recursive-starks-78f8dd401025

7. The future of layer 3

1. The two-layer network is the most cost-efficient for now, but the future belongs to the multi-layer network;
2. The idea of layer 3 is in an early stage. However, layer 3 must be driven by cost optimization and efficiency improvement. Layer 2 is still a general-purpose scaling solution while layer 3 accomplishes more customized function on top of it;
3. Based on the current proposals of layer 3, the underlying technology of layer 3 is closely related to zero knowledge. Therefore, exploring zk technology is essential to the development of layer 3.

Reference

https://vitalik.ca/general/2022/09/17/layer_3.html

https://medium.com/starkware/fractal-scaling-from-l2-to-l3-7fe238ecfb4f

https://medium.com/starkware/recursive-starks-78f8dd401025

https://ethereum.org/zh/layer-2/

About Foresight Ventures

Foresight Ventures is dedicated to backing the disruptive innovation of blockchain for the next few decades. We manage multiple funds: a VC fund, an actively-managed secondary fund, a multi-strategy FOF, and a private market secondary fund, with AUM exceeding $400 million. Foresight Ventures adheres to the belief of “Unique, Independent, Aggressive, Long-Term mindset” and provides extensive support for portfolio companies within a growing ecosystem. Our team is composed of veterans from top financial and technology companies like Sequoia Capital, CICC, Google, Bitmain, and many others.

Website: https://www.foresightventures.com/

Twitter: https://twitter.com/ForesightVen

Medium: https://foresightventures.medium.com

Substack: https://foresightventures.substack.com

Discord: https://discord.com/invite/maEG3hRdE3

Linktree: https://linktr.ee/foresightventures