Vitalik: Sorting Out the Differences Among Various L2s

L2 projects will increasingly tend towards heterogeneity.

Original Title: Different types of layer 2s

Written by: Vitalik Buterin

Translated by: BlockBeats

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

In addition, we have seen some teams building sidechains while also starting to develop rollup solutions (such as Polygon), some L1 projects attempting to move towards validity proofs (such as Celo), and entirely new attempts (such as Linea, Zeth…).

One inevitable result of this is that we are seeing L2 projects become increasingly heterogeneous. (Translator’s note: In the crypto space, “heterogeneous” refers to the coexistence or mixing of different types or natures of things. This term is often used to describe different blockchains, protocols, technologies, or assets that have different characteristics, rules, or attributes.) I expect this trend to continue for the following reasons:

Currently, some independent L1 projects are seeking closer integration with the Ethereum ecosystem and may transition into L2 projects. These projects may wish to adopt a phased transition approach. An immediate full transition would reduce usability, as the technology is not yet ready to move everything into rollup solutions. On the other hand, a much later full transition may sacrifice momentum and miss the opportunity to have practical significance.

Some centralized projects want to provide more security guarantees for their users and are exploring blockchain-based approaches. In many cases, these projects might have previously considered “permissioned consortium chains.” In reality, they may only need to reach a “semi-centralized” level. Furthermore, they often have very high throughput, making them unsuitable for rollup solutions, at least in the short term.

Non-financial applications, such as games or social media, want decentralization 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 like username registration and account recovery should be done in rollup solutions, but frequent and low-value activities like posts and votes require less security. If a blockchain failure causes your post to disappear, that’s an acceptable cost; but if a blockchain failure causes you to lose your account, that’s a much bigger problem.

An important theme is that, although applications and users currently on Ethereum L1 are willing to pay small but still visible rollup fees in the short term, users from the non-blockchain world are less willing to do so: if you previously paid $1, then paying $0.10 is easier to accept, but if you previously paid $0, it’s hard to accept.

This applies to applications that are still centralized today, as well as smaller L1 projects that typically have extremely low fees when their user base is small.

A natural question is: for a specific application, which of these complex trade-offs between rollup solutions, validiums (validity proofs), and other systems is reasonable?

Rollups vs Validiums vs Disconnected Systems

The first dimension of security versus scalability that we will explore can be described as follows: If you have an asset issued on L1, then deposit it into L2, and then transfer it into your hands, how much guarantee do you have that you can withdraw the asset back to L1?

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

We can describe this issue with a simple chart:

It’s worth mentioning that this is a simplified scheme, and there are many intermediate options. For example:

Between rollup and validium: In validium, anyone can make an on-chain payment to pay transaction fees, at which point the operator is forced to provide some data on-chain, or else lose their deposit.

Between plasma and validium: A Plasma system provides rollup-like security guarantees with off-chain data availability, but it only supports a limited number of applications. A system can provide full EVM, and for users who do not use these more complex applications, offer Plasma-level guarantees, and for users who do, offer validium-level guarantees.

These intermediate options can be seen as points on a spectrum between rollup and validium. But what motivates applications to choose a specific point on this spectrum, rather than a point further to the left or right? Here, there are two main factors:

1. The cost of Ethereum native data availability, which will decrease over time as technology advances. Ethereum’s next hard fork, Dencun, introduces EIP-4844 (also known as “proto-danksharding”), which provides about 32 kB/sec of on-chain data availability.

It is expected that in the next few years, as full danksharding is launched, this data availability will gradually increase, with the ultimate goal of about 1.3 MB/sec of data availability. At the same time, improvements in data compression will allow us to do more with the same amount of data.

2. The application’s own needs: How severe is the user’s loss from high fees compared to the loss from application failure? Financial applications lose more from application failures; games and social media involve a large number of user activities, which are relatively low-value, so different security trade-offs make sense for them.

This trade-off roughly looks like the following chart:

Another type worth mentioning is pre-confirmations. Pre-confirmations are messages signed by a group of participants in a rollup or validium, stating “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 does not match reality, but if they do, their deposits 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 full security.

Pre-confirmations can be seen as another example of a hybrid system, similar to the “plasma/validium hybrid” mentioned above, but this time mixing between a rollup (or validium) with full security but high latency, and a system with lower security but low latency. Applications that require lower latency get lower security, but can coexist in the same ecosystem with those willing to accept higher latency for maximum security.

Trustless Reading of Ethereum

Another less considered but still very important form of connection relates to the system’s ability to read the Ethereum blockchain. Specifically, this includes the system’s ability to roll back if Ethereum rolls back. To understand why this is valuable, consider the following scenario:

Suppose, as shown in the diagram, the Ethereum blockchain rolls back. This could be a temporary interruption within an epoch, where the blockchain has not yet finalized; or it could be a longer inactivity leak period caused by too many validators going offline, making finalization impossible for an extended period.

The worst-case scenario that may result 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 rolls back, but the top chain does not roll back. As a result, future blocks of the top chain correctly follow the new, correct Ethereum blockchain, but the erroneous transaction (the 100 ETH deposit) still exists on the top chain. This vulnerability could lead to currency inflation, turning bridged ETH on the top chain into a fractional reserve.

There are two ways to solve this problem:

1. The top chain can only read finalized Ethereum blocks, so it never needs to roll back;

2. If Ethereum rolls back, the top chain may also roll back. Both approaches prevent this problem. The former is easier to implement, but if Ethereum enters an inactivity leak period, it may result in loss of functionality for a longer time. The latter is harder to implement but ensures optimal functionality at all times.

Note that the first approach does have a special case. If Ethereum suffers a 51% attack, resulting in two new incompatible blocks that both appear finalized, the top chain may choose the wrong block (i.e., the block not ultimately supported by Ethereum’s social consensus) and need to roll back to switch to the correct block. It can be argued that it is unnecessary to pre-write code to handle this; the issue can be handled by hard forking the top chain.

The ability for a blockchain to read Ethereum trustlessly is important for two 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 abstraction wallets using shared key storage structures to securely hold assets on that chain.

Despite some controversy, the importance of the first approach has been widely recognized. Similarly, the second approach is also important because it means you can have a wallet that can easily change keys and hold assets on many different chains.

Does Having a Bridge Make You a Validium?

Suppose the top chain was originally launched as an independent chain, and then someone deployed a bridge contract on Ethereum. The bridge contract is simply a contract that accepts block headers from the top chain and verifies that any block header submitted to it comes with a valid certificate proving that the block header has been accepted by the top chain’s consensus, and adds the block header to a list.

Applications can build functionality on top of this, such as token deposits and withdrawals. Once such a bridge is established, does it provide any of the asset security guarantees we mentioned earlier?

So far, not yet! There are two reasons:

1. We are verifying the signatures of blocks, but not whether the state transitions are correct. Therefore, if you deposit assets issued on Ethereum into the top chain and the top chain’s validators become dishonest, they can sign an invalid state transition and steal those assets;

2. The top chain still cannot read Ethereum. Therefore, you cannot deposit Ethereum-native assets into the top chain unless you rely on other (possibly insecure) third-party bridges.

Now, let’s build the bridge as a validity bridge: it not only verifies consensus but also verifies that any new block computed with a ZK-SNARK proof has the correct state.

Once this step is completed, the top chain’s validators cannot steal your funds. They can publish a block with unavailable data, preventing anyone from withdrawing funds, but they cannot steal funds (unless they try to extort users by revealing the data needed to withdraw funds). This has the same security model as validium.

However, we still haven’t solved the second problem: the top chain cannot read Ethereum data. To achieve this, we need to take one of the following two approaches:

1. Place a bridge contract in the top chain that verifies finalized Ethereum blocks;

2. Include the hash of a recent Ethereum block in every block of the top chain, and use a fork choice rule to enforce hash linking. That is, a top chain block that links to an Ethereum block not on the main chain is itself not on the main chain. If the Ethereum block that a top chain block links to was initially on the main chain but later becomes non-canonical, the top chain block must also become non-canonical.

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

Is this enough? Actually, not quite, because there are some minor edge cases:

1. What happens if Ethereum suffers a 51% attack?

2. How do you handle Ethereum hard fork upgrades?

3. How do you handle hard fork upgrades of your own chain?

A 51% attack on Ethereum would have similar consequences to a 51% attack on the top chain, but in reverse. An Ethereum hard fork could break the Ethereum bridge inside the top chain. A social commitment—that if Ethereum reverts a finalized block, you revert, and if Ethereum hard forks, you hard fork—is the cleanest way to solve this problem.

Such a commitment may never actually need to be executed: if the top chain’s governance body detects evidence of a possible attack or hard fork, it can activate the governance body, and only hard fork the top chain if the governance body fails.

For the third issue, the only viable answer is to set up some form of governance body on Ethereum that allows the bridge contract on Ethereum to be aware of hard fork upgrades of the top chain.

In summary: Two-way validity bridges are almost enough to make a blockchain a validium. The main remaining element is a social commitment that if Ethereum experiences an abnormal event causing the bridge contract to fail, the other blockchain will hard fork in response.

Conclusion

There are two key dimensions to “connecting with Ethereum”:

1. Security of withdrawal to Ethereum;

2. Security of reading from Ethereum.

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

Note that each dimension has two different metrics (in fact, there are four dimensions): withdrawal security can be measured by (i) the level of security, and (ii) how many users or use cases benefit from the highest level of security;

While reading security can be measured by (i) how quickly the link can read Ethereum blocks, especially the distinction between finalized blocks and any blocks, and (ii) the degree of social commitment in handling edge cases such as 51% attacks and hard forks.

There is value for projects in many areas of this design space. For some applications, high security and tight coupling are critical. For others, looser conditions can be accepted in exchange for 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.