Vitalik Buterin Explores the Distinctions of Various Layer 2 Solutions in Ethereum

Vitalik Buterin Explores the Distinctions of Various Layer 2 Solutions in Ethereum

Vitalik Buterin Explores the Distinctions of Various Layer 2 Solutions in Ethereum

Title: Different types of layer 2s
Author: Vitalik Buterin
Translated by: BlockBeats

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

In addition, we have seen some teams building sidechains while also starting to construct rollup solutions (such as Polygon). Some L1 projects are attempting to move towards validity proofs (such as Celo), and there are also new experiments (such as Linea and Zeth).

An inevitable result of this is that we are seeing L2 projects becoming more heterogeneous. I expect this trend to continue due to the following reasons:

1. Some independent L1 projects are seeking closer integration with the Ethereum ecosystem and may transition into L2 projects. These projects may prefer a phased transition as an immediate full transition would lower usability since the technology is not yet ready to put all the content into rollup solutions. A later full transition may sacrifice momentum and not have practical significance.

2. Some centralized projects are looking to provide more security for their users and are exploring blockchain-based approaches. In many cases, these projects may have previously looked into “permissioned consortium chains”. In reality, they may only need a level of “semi-centralization”. Additionally, they usually have very high throughput, which is not suitable for rollup solutions at least in the short term.

3. Non-financial applications, such as games or social media, want 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 differently: rare and high-value activities like username registration and account recovery should be done in rollup solutions, but frequent and low-value activities like posting and voting require less security. It is acceptable if a blockchain failure leads to the disappearance of your posts, but it would be a bigger problem if it causes you to lose your account.

An important topic is that while applications and users currently on Ethereum L1 are willing to pay a lower but still visible rollup fee in the short term, users from outside the blockchain world are less willing to do so. It is easier to accept paying $0.10 if you previously paid $1, but it is harder to accept if you previously paid $0. This applies to both centralized applications today and smaller L1 projects with very low fees in their user base.

A natural question arises: in the complex trade-offs between rollup solutions, validiums, and other systems for specific applications, which one is reasonable?

We will explore the first dimension of security and scalability, which can be described as follows: if you have an asset issued on L1, then deposit it into L2, and then withdraw it back to L1, to what extent can you be guaranteed that you can retrieve the asset on L1?

There is also a related question: what technological choices lead to this level of guarantee, and what are the trade-offs of these technological choices?

We can describe this issue with a simple chart.

It is worth noting that this is a simplified scheme with many intermediate options. For example:

Between rollups and validiums:
– In validiums, anyone can make on-chain payments to pay for transaction fees, and the operator is forced to put some data on-chain or risk losing their deposit.

Between plasma and validiums:
– A Plasma system provides similar security guarantees as rollups, 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.

These intermediate options can be seen as points on a spectrum between rollups and validiums. However, what drives applications to choose a specific point on this spectrum instead of some point further to the left or right? There are two main factors:

1. The cost of Ethereum native data availability. With the development of technology, this cost will decrease over time. Ethereum’s upcoming hard fork, Dencun, introduces EIP-4844 (also known as “proto-danksharding”), which provides approximately 32 kB/s of on-chain data availability. It is expected that with the full implementation of danksharding in the coming years, this data availability will gradually increase, with the ultimate goal being about 1.3 MB/s. Improvements in data compression will also allow us to achieve more functionality with the same amount of data.

2. The specific requirements of the application itself. How severe is the loss for users in terms of high fees compared to issues with the application? Financial applications would suffer more from application failures, while games and social media involve a large amount of user activity with relatively lower value. Therefore, different security trade-offs make sense for them.

Another important type to mention is pre-confirmations. Pre-confirmations are messages signed by a set of participants in a rollup or validium, indicating “we attest that these transactions are included in this order and the post-state root is this.” These participants may sign a pre-confirmation that turns out to be incorrect, but if they do, their deposit will be destroyed. This is useful for low-value applications like consumer payments, while high-value applications like multimillion-dollar financial transfers may wait for “regular” confirmations supported by full system security.

Pre-confirmations can be seen as another example of a mixed system, similar to the “plasma/validium mixture” mentioned earlier, but this time mixing a rollup (or validium) with full security but high latency and a system with lower security but low latency. Low-latency applications can have lower security but coexist in the same ecosystem with applications that are willing to tolerate higher latency for maximum security.

Another less considered but still important type is the ability to read Ethereum blockchain. Specifically, this includes the ability for a system to roll back when Ethereum undergoes a rollback. To understand why this is valuable, consider the following scenario:

Assuming that Ethereum experiences a rollback as shown in the figure. This could be a temporary interruption within an epoch where the blockchain has not yet been finalized, or it could be due to too many validators going offline, causing the chain to fork. In this case, a system that can roll back can ensure that your assets are still valid and accessible on the correct chain.

In conclusion, as the ecosystem expands, we are witnessing the emergence of different types of layer 2 solutions. These solutions offer various trade-offs in terms of security, scalability, and connectivity with the Ethereum blockchain. Each application will need to assess its own requirements and choose the most suitable solution based on those factors.The non-activity leakage period that leads to the inability of the blockchain to reach a final determination for a longer period of time.
The worst-case scenario that may arise from this is as follows: suppose the first block of the top chain reads certain 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. As a result, the future blocks of the top chain correctly follow the new, correct blocks on the Ethereum blockchain, but the incorrect transaction (the deposit of 100 ETH) still exists in the top chain. This vulnerability can lead to currency issuance and transform the bridged ETH on the top chain into partial reserves.
There are two ways to solve this problem:
1. The top chain can only read Ethereum blocks that have been finally determined, so it never needs to roll back.
2. If Ethereum experiences a rollback, the top chain can also experience a rollback. Both can prevent this problem. The former is easier to implement, but if Ethereum enters a non-activity leakage period, it may result in the loss of functionality for a longer period of time. The latter is more difficult to implement, but it ensures that the optimal functionality is always available.
Please note that the first method does have a special case. If Ethereum experiences a 51% attack, resulting in the simultaneous presence of two new incompatible blocks, both of which appear to have been finally determined, then the top chain may choose the wrong block (i.e., a block not supported by Ethereum’s social consensus), and a rollback is required to switch to the correct block. It can be said that it is unnecessary to write code in advance to handle this situation; this problem can be addressed by conducting a hard fork on the top chain.
The ability of the blockchain to read Ethereum without trust has two important reasons:
First, this ability can reduce the security issues involved in bridging tokens issued on Ethereum (or other Layer 2 solutions) to that chain.
Second, this ability allows account-based abstract wallets that use shared key storage structures to securely hold assets on that chain.
Although there is controversy, the importance of the first method has been widely recognized. Similarly, the second method is also important because it means you can have a wallet that can easily change keys and hold assets on many different chains.
Assuming the top chain was originally launched as an independent chain, and then someone deployed a bridging contract on Ethereum. The bridging contract is simply a contract that accepts block headers from the top chain and verifies if any block header submitted to it comes with a valid certificate proving that the block header has been accepted by the consensus of the top chain, and adds that block header to the list.
Applications can build functionalities on top of this, such as token deposits and withdrawals. Once such bridging is established, does it provide any asset security guarantees as mentioned earlier?
So far, it does not! There are two reasons:
1. We are verifying the signature of the block but not verifying if the state transition is correct. Therefore, if you deposit assets issued on Ethereum into the top chain, and the validators of the top chain become dishonest, they can sign an invalid state transition, thereby stealing these assets.
2. The top chain still cannot read Ethereum. Therefore, you cannot deposit Ethereum-native assets into the top chain unless you rely on another (possibly insecure) third-party bridge.
Now, let’s construct the bridging contract as a verification bridge: it not only verifies consensus but also verifies if the state of any new block calculated using ZK-SNARK proofs is correct.
Once this step is completed, the validators of the top chain cannot steal your funds. They can publish a block containing unavailable data to prevent anyone from withdrawing funds, but they cannot steal the funds (unless they attempt to disclose the data that allows users to withdraw funds by demanding ransom). This has the same security model as validium.
However, we still haven’t solved the second problem: the top chain cannot read data from Ethereum. To achieve this, we need to take one of the following two approaches:
1. Place a bridging contract in the top chain that verifies Ethereum blocks that have been finally determined.
2. Include the hash of a recent Ethereum block in each block of the top chain and enforce hash linking using fork choice rules. In other words, linking the top chain blocks to Ethereum blocks that are initially on the main chain but later become non-main chain, the top chain blocks must also become non-main chain.
These purple links can be hash links or bridging contracts that verify Ethereum consensus.
Is that enough? In fact, it is not enough because there are some minor edge cases:
What happens if Ethereum suffers a 51% attack?
How to handle hard fork upgrades of Ethereum?
How to handle hard fork upgrades of your chain?
A 51% attack on Ethereum would have similar consequences to a 51% attack on the top chain, but in reverse. A hard fork on Ethereum may render the Ethereum bridging on the top chain ineffective. A social commitment, i.e., if Ethereum rolls back a block that has been finally determined, it will roll back; if Ethereum undergoes a hard fork, it will undergo a hard fork, is the cleanest way to address this issue.
Such a commitment may never need to be truly executed: if the governance entity of the top chain discovers evidence of a possible attack or hard fork, it can activate the governance entity and only hard fork the top chain if the governance entity fails.
For the third issue, the only viable answer is to set up some form of governance mechanism on Ethereum that allows the bridging contract on Ethereum to be aware of hard fork upgrades on the top chain.
In summary, bidirectional verification bridging is almost sufficient to make a blockchain a validium. The main remaining element is a social commitment that if Ethereum experiences abnormal conditions that cause the bridging contract to malfunction, another blockchain will undergo a hard fork in response.
“Connecting to Ethereum” has two key dimensions:
Security of withdrawals to Ethereum;
Security of reading Ethereum.
Both are very important and have different considerations. There is a continuous spectrum in both cases:
Please note that each dimension has two different metrics (in fact, there are four dimensions): the security of withdrawals can be measured by (i) the security level, and (ii) the number of users or use cases benefiting from the highest security level;
While the security of reading can be measured by (i) how quickly the chain can read Ethereum blocks, especially the difference between finally determined blocks and any other blocks, and (ii) the degree of social commitment when the chain is dealing with edge scenarios such as 51% attacks and hard forks.
There is value in many areas of this design space. For certain applications, high security and tight coupling are crucial. For other applications, it may be acceptable to have looser conditions in order to achieve greater scalability. In many cases, starting with looser conditions today and gradually transitioning to tighter coupling over the next decade may be the optimal choice.
Original article link:
This article is authorized to be reproduced by DooMing BlockBeats.