Vitalik's latest long article: Sorting out the differences between various L2s

Original Title: “Different types of layer 2s”

Original Author: Vitalik Buterin

Original Compilation: 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 significant progress, continuously improving its security. The L2beat page summarizes the status of each project well.

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

One inevitable outcome is that we see L2 projects tending to become more heterogeneous. I expect this trend to continue for the following reasons:

Currently, some independent L1 projects are seeking closer ties with the Ethereum ecosystem and may potentially transition into L2 projects. These projects may wish to adopt a phased transition approach. An immediate overall transition would reduce usability since the technology is not yet ready to incorporate everything into a rollup solution. A later overall transition may sacrifice momentum and may not be timely enough to be meaningful.

Some centralized projects wish to provide more security assurances for their users and are exploring blockchain-based avenues. In many cases, these projects may have previously considered "permissioned consortium chains." In reality, they may only need to achieve a level of "semi-centralization." Additionally, they often have very high throughput, making rollup solutions unsuitable at least in the short term.

Non-financial applications, such as games or social media, wish to decentralize 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 within a rollup solution, but frequent and low-value activities like posting and voting require less security. If a blockchain failure causes your post to disappear, that is an acceptable cost; however, if a blockchain failure results in the loss of your account, that would be a much bigger issue.

An important theme is that while 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 more acceptable, while if you previously paid $0, it becomes difficult to accept.

This applies to applications that are still centralized today, as well as smaller L1 projects that typically have very low fees in cases where their user base is relatively small.

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

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 back to yourself, how much assurance do you have that you can retrieve the asset back to L1?

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

We can illustrate this issue with a simple chart:

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

Between rollup and validium: In validium, anyone can make on-chain payments to cover transaction fees, at which point the operator will be forced to provide some data on-chain, or else they will lose 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 do not use these more complex applications, while providing validium-level guarantees for users who do.

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

1. The cost of Ethereum's 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 approximately 32 kB/sec of on-chain data availability.

It is expected that in the coming years, as full danksharding is rolled out, this data availability will gradually increase, with a final target of around 1.3 MB/sec of data availability. Meanwhile, improvements in data compression will allow us to achieve more functionality with the same amount of data.

2. The application's own needs: how severe are the losses for users in terms of high fees compared to issues arising from the application? Financial applications will incur greater losses 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:

Another type worth mentioning is pre-confirmations. Pre-confirmations are messages signed by a group of participants in a rollup or validium, indicating "we certify 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 align with reality, but if they do, their deposits will be forfeited.

This is very useful for low-value applications (like consumer payments), while high-value applications (like 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 rollups (or validiums) with full security but high latency and systems with lower security levels but low latency. Applications requiring lower latency will receive lower security but can coexist with those willing to endure higher latency for maximum security within the same ecosystem.

Trustlessly Reading 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 when Ethereum undergoes a rollback. To understand why this is valuable, consider the following scenario:

Assume, as shown in the diagram, that the Ethereum blockchain undergoes a rollback. This could be a temporary interruption within an epoch, during which the blockchain has not yet been finalized; or it could be due to too many validators being offline, leading to a prolonged period of inactivity where the blockchain cannot finalize.

The worst-case scenario that could arise 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 deposited 100 ETH into the top chain on Ethereum. Then Ethereum undergoes 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 erroneous transaction (i.e., the deposit of 100 ETH) still exists on the top chain. This vulnerability could lead to currency inflation, turning the bridged ETH on the top chain into a partially backed asset.

There are two ways to address this issue:

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

2. If Ethereum undergoes a rollback, the top chain may also roll back. Both can prevent this issue. The first is easier to implement, but if Ethereum enters a period of inactivity, it may lead to functionality being lost for an extended time. The latter is more difficult to implement but can ensure optimal functionality at all times.

Note that the first method does have a special case. If Ethereum suffers a 51% attack, resulting in two new incompatible blocks appearing simultaneously, both of which appear to have been finalized, then the top chain may choose the wrong block (i.e., a block not supported by Ethereum's social consensus) and will need to roll back to switch to the correct block. It could be argued that it is unnecessary to pre-write code to handle this situation; it can be addressed by hard forking the top chain.

The ability of a 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 second-layer 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 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 across many different chains.

Can Having a Bridge Become Validium?

Assume the top chain was initially launched as an independent chain, and then someone deployed a bridge contract on Ethereum. The bridge contract is simply a contract that accepts top chain block headers, which verifies whether any submitted block header 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 a list.

Applications can build functionalities on this basis, such as deposits and withdrawals of tokens. Once such a bridge is established, does it provide any asset security assurances we mentioned earlier?

So far, no! There are two reasons:

1. We are verifying the signatures of the blocks but not verifying whether the state transitions are correct. Therefore, if you deposit an asset issued on Ethereum into the top chain, and the validators of the top chain become dishonest, they can sign an invalid state transition to 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 (potentially unsafe) third-party bridges.

Now, let’s build the bridge as a validating bridge: it not only verifies consensus but also verifies whether the state of any new blocks computed using ZK-SNARK proofs is correct.

Once this step is completed, the validators of the top chain will not be able to steal your funds. They can publish a block containing unavailable data, preventing everyone from withdrawing funds, but they cannot steal funds (unless they attempt to extort users for the data that allows them to withdraw funds). This has the same security model as validium.

However, we still have not solved the second problem: the top chain cannot read Ethereum's 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 a hash of a recent Ethereum block in each block of the top chain and adopt a fork selection rule to enforce hash linking. That is, a block of the top chain linked to an Ethereum block that is not on the main chain is itself not on the main chain. If the Ethereum block linked to by the top chain block initially was on the main chain but later became a non-main chain, the top chain block must also become a non-main chain.

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

Is that enough? In fact, it is not enough, as there are some small edge cases:

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

2. How to handle Ethereum's hard fork upgrades?

3. How to handle hard fork upgrades of your chain?

A 51% attack on Ethereum would lead to consequences similar to a 51% attack on the top chain, but in reverse. A hard fork of Ethereum could render the Ethereum bridging within the top chain ineffective. A social commitment that if Ethereum reverts a finalized block, it will revert, and if Ethereum undergoes a hard fork, it will hard fork, is the cleanest way to solve this problem.

Such a commitment may never need to be truly executed: if the governance body of the top chain finds evidence that an attack or hard fork may occur, it can activate the governance body and only hard fork the top chain if the governance body fails.

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

Conclusion: A bidirectional validating bridge is almost sufficient to make a blockchain validium. The main remaining element is a social commitment that if Ethereum experiences an anomaly causing the bridge contract to malfunction, another blockchain will hard fork in response.

Conclusion

"Connecting to Ethereum" has two key dimensions:

1. Security of withdrawals to Ethereum;

2. Security of reading Ethereum.

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

Note that each dimension has two different measures (actually 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;

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

There is value in many areas of this design space. For some applications, high security and tight connections are crucial. For other applications, looser conditions can be accepted 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.