Original Title: "Different types of layer 2s"

Original Author: Vitalik Buterin

Original Translation: Kaori, Sharon, Luccy, BlockBeats

The ecosystem has rapidly expanded in the past year. The ZK-EVM rollup ecosystem, traditionally represented by StarkNet, Arbitrum, Optimism, and Scroll, has made significant progress in improving its security, and the L2beat page provides a good summary of the status of each project.

In addition, we also see some teams building sidechains, while also starting to build rollup solutions (such as Polygon). Some layer one projects are trying to move towards validity verification (such as Celo), and there are also new attempts (such as Linea, Zeth...).

One of the inevitable results is that we see Layer 2 projects tending to become more heterogeneous. I expect this trend to continue for the following reasons:

Currently, some independent Layer 1 projects are seeking closer integration with the Ethereum ecosystem and may potentially transition into Layer 2 projects. These projects may wish to adopt a phased transition approach. Immediate overall transition would reduce usability as the technology is not yet ready to put all content into the rollup scheme. However, in a later overall transition, momentum may be sacrificed and may not have practical significance.

Some centralized projects hope to provide more security for their users and are exploring ways based on blockchain. In many cases, these projects may have previously studied "permissioned consortium chains". In fact, they may only need to achieve a level of "semi-centralization". In addition, they typically have very high throughput and are not suitable for using rollup solutions at least in the short term.

Non-financial applications, such as games or social media, hope to be decentralized, but only require a certain level of security.

In the case of social media, it actually involves handling different parts of the application in different ways: rare and high-value activities such as username registration and account recovery should be done in a rollup scheme, but frequent and low-value activities such as posts and voting require less security. If the chain fails and your post disappears, that is an acceptable cost. But if the chain fails and you lose your account, that would be a bigger problem.

One important theme is that although applications and users currently located on Ethereum Layer 1 are willing to pay small but still visible rollup fees in the short term, users from outside the blockchain world are less willing to do so: if you previously paid $1, it is easier to accept paying $0.10, but if you previously paid $0, it is difficult to accept.

This applies to applications that are still centralized today, as well as smaller Layer 1 projects that typically have very low fees in their user base.

One natural question is: for a specific application, which of these complex trade-offs between rollup schemes, validity checks, and other systems is reasonable for it?

Rollups vs Validiums vs Disconnected Systems

We will explore the first dimension of security and scalability as follows: If you have an asset issued on L1, deposit it on L2, and then transfer it to your possession, to what extent can you be guaranteed to retrieve the asset back to L1?

Meanwhile, there is a related question: what technology choice leads to this level of guarantee, and what are the trade-offs of this technology choice?

We can use a simple chart to describe this issue:

It is worth mentioning that this is a simplified solution, with many intermediate options available. For example:

Between rollup and validium: In validium, anyone can make on-chain payments to pay transaction fees, at which point the operator will be required to provide some data on-chain or risk losing their deposit.

Between Plasma and Validium: A Plasma system provides security guarantees similar to rollup, with off-chain data availability, but it only supports a limited number of applications. A system can provide a full EVM and offer Plasma-level guarantees for users who don't use these more complex applications, as well as Validium-level guarantees for users who do use them.

These intermediate options can be seen as a spectrum between rollup and validium. However, what drives an application to choose a specific point on this spectrum instead of a point further to the left or right? There are two main factors at play here:

The cost of Ethereum's native data availability will decrease over time as technology advances. The next hard fork of Ethereum, Dencun, introduces EIP-4844 (also known as "proto-danksharding"), which provides approximately 32 kB/second of on-chain data availability.

It is expected that in the coming years, with the full rollout of danksharding, data availability will gradually improve, with the ultimate goal of achieving data availability of approximately 1.3 MB/second. At the same time, improvements in data compression will allow us to achieve more functionality with the same amount of data.

Application's own requirements: How severe is the user's loss in terms of high costs compared to application problems? Financial applications will lose more due to application failures; games and social media involve a lot of user activity, and relatively low-value activities, so different security trade-offs make sense for them.

This trade-off roughly looks like the following, without considering the context and industry-specific terms:

这种权衡大致上看起来如图所示：

Another type worth mentioning is pre-confirmations. Pre-confirmations are messages signed by a group of participants in a rollup or validium, indicating "we prove that these transactions are included in it in this order, and the post-state root is this". These participants may sign a pre-confirmation that does not match reality, but if they do, their deposit will be destroyed.

This is very useful for low-value applications (such as consumer payments), while high-value applications (such as multi-million dollar financial transfers) may wait for "regular" confirmations supported by the system's complete security.

预确认可以被视为另一个混合系统的例子, similar to the "plasma/validium hybrid" mentioned earlier, but this time it is a mixture between a rollup (or validium) with complete security but high latency and a system with lower security but low latency. Applications that require lower latency will have lower security, but can coexist in the same ecosystem with applications that are willing to tolerate higher latency for maximum security.

无需信任地读取以太坊

translates to

Read Ethereum without Trust

Another less considered but still very important form of connection is related to the ability of the system to read the Ethereum blockchain. Specifically, this includes the ability of the system to roll back when a rollback occurs on Ethereum. To understand why this is valuable, consider the following scenario:

Assuming as shown in the figure, a rollback occurs in the Ethereum blockchain. This may be a temporary interruption within an epoch when the chain is not yet finally determined, or it may be a non-active leakage period where the chain cannot be finally determined for a long time due to too many validators being offline.

The worst-case scenario that could arise from this is as follows: suppose the first block of the top chain reads some data from the leftmost block of the Ethereum chain. For example, someone deposits 100 ETH into the top chain on Ethereum. Then Ethereum experiences a rollback, but the top chain does not. The result is that the future blocks of the top chain correctly follow the new, correct blocks on the Ethereum chain, but the incorrect old link (i.e. the deposit of 100 ETH) still exists on the top chain. This vulnerability could lead to currency inflation, turning bridged ETH on the top chain into partial reserves.

There are two methods to solve this problem:

These purple links can be hash links or bridging contracts that verify Ethereum consensus.

1. What would happen if Ethereum suffered a 51% attack?

3. How to handle the hard fork upgrade of your chain?

Such promises may never need to be truly executed: if the governance body of the top chain discovers evidence of a potential attack or hard fork, the governance body can be activated to only hard fork the top chain in the event of governance failure.

For the third question, the only viable answer is to establish some form of governance mechanism on Ethereum that can enable bridge contracts on Ethereum to be aware of hard fork upgrades on the top chain.

Summary: Bidirectional verification bridging is almost enough to make the chain a validium. The main remaining element is a social commitment, that is, if Ethereum experiences abnormal situations that cause the bridging contract to not function properly, the other chain will respond with a hard fork.

There are two key dimensions to 'connecting with Ethereum':

1. Security of Ethereum Extraction

These two are both very important and have different considerations. In both cases, there is a continuous spectrum:

There is value in many areas of the design space. For some applications, high security and tight connectivity are crucial. For others, looser conditions may be acceptable in order to achieve greater scalability. In many cases, starting with looser conditions today and gradually transitioning to tighter coupling over the next decade as technology improves may be the optimal choice.

"Original article link"

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