Title: Different types of layer 2s
Author: Vitalik Buterin
Translator: BlockBeats
The ecosystem has rapidly expanded over the past year. The ZK-EVM rollup ecosystem, traditionally represented by StarkNet, Arbitrum, Optimism, and Scroll, has progressed rapidly, continuously improving its security. The L2beat page provides a good summary of the status of each project.
In addition, we also see some teams building sidechains while starting to construct rollup solutions (such as Polygon). Some L1 projects are trying to move towards validity verification (such as Celo), and there are brand new attempts (such as Linea, Zeth…).
One inevitable result is that we see L2 projects tending towards more heterogeneity. I expect this trend to continue for the following reasons:
Currently, some independent L1 projects are seeking closer contact with the Ethereum ecosystem and may potentially transition to L2 projects. These projects may wish to take a phased transition approach. Immediate overall transitions will reduce usability as the technology is not yet ready to put all content into rollup solutions. Delayed overall transitions may sacrifice momentum and lack practical significance.
Some centralized projects aim to provide more security for their users and are exploring blockchain-based approaches. In many cases, these projects may have previously researched “permissioned consortium chains.” In reality, they may only need to reach a “semi-centralized” level. Additionally, they often have very high throughput, making them unsuitable for use with rollup solutions at least in the short term.
Non-financial applications, such as games or social media, aim to decentralize but only require a certain level of security. In the case of social media, it involves handling different parts of applications in different ways: rare and high-value activities like user name registration and account recovery should be completed in rollup solutions, but frequent and low-value activities like posts and votes require less security. If a blockchain failure leads to the loss of your post, it is an acceptable cost; but if it leads to the loss of your account, it is a bigger issue.
An important theme is that while applications and users currently on Ethereum L1 are willing to pay relatively small but still noticeable rollup fees in the short term, users from the non-blockchain world are less willing to do so. If you have previously paid 1 dollar, paying 0.10 dollars is more acceptable, but if you have not paid anything before, it is difficult to accept. This applies to today’s still centralized applications and smaller L1 projects with very low fees in their user base.
A natural question is: in the complex trade-offs between rollup solutions, validiums, and other systems for specific applications, which one is reasonable?
Rollups vs Validiums vs Disconnected Systems
Read Ethereum without Trust
Can Bridges Become Validiums?
Conclusion
We will explore the first dimension of security and scalability described as follows: if you have an asset issued on L1, then deposit it into L2, and then transfer it back to your hands, how much assurance do you have that you can retrieve the asset back to L1?
There is also a related question: what technology choices lead to this level of assurance, and what are the trade-offs of these technology choices?
We can describe this issue with a simple chart:
It is worth noting that this is a simplified scenario with many intermediate options. 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 forced to provide some data on-chain, otherwise risking deposit loss.
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 complete EVM and offer Plasma-level guarantees for users not using these more complex applications and provide validium-level guarantees for users using these applications.
These intermediate options can be seen as a spectrum between rollup and validium. However, what drives applications to choose a specific point on this spectrum rather than a more left or more right point? Here, there are two main factors:
The cost of Ethereum’s native data availability will decrease over time with technological advancements.
The next Ethereum hard fork, Dencun, introduces EIP-4844 (also known as “proto-danksharding”), which provides approximately 32 kB/second of on-chain data availability. With the rollout of full danksharding expected in the coming years, this data availability will gradually increase, with the ultimate goal of around 1.3 MB/second of data availability. Additionally, improvements in data compression will allow us to achieve more with the same data volume.
Applications’ own requirements: how severe are the losses for users in terms of high fees compared to application issues? Financial applications will incur greater losses due to application failures; games and social media involve a large amount of user activity and relatively low-value activities, making different security trade-offs meaningful for them.
These trade-offs generally look 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 confirm that these transactions are included in this order, and the post-state root is this.” These participants may sign a pre-confirmation that is not in line with reality, but if so, their deposit will be destroyed. This is particularly useful for low-value applications (such as consumer payments), while high-value applications (such as multimillion-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 mixed system, similar to the “plasma/validium hybrid” mentioned earlier, but this time mixing a system with full security but high latency like rollup (or validium) with a system with lower security level but low latency. Applications that require lower latency will have lower security but can coexist in the same ecosystem with applications willing to accept higher latency for maximum security.
Another less considered but still very important form of connection is related to the system’s ability to read Ethereum’s blockchain. Specifically, this includes the system’s ability to rollback when Ethereum experiences a rollback. To understand why this is valuable, consider the following scenario:
Assume Ethereum blockchain undergoes a rollback as shown in the diagram. This may be a temporary interruption within an epoch, where the blockchain has not been finalized yet, or it may be due to excessive validators going offline, leading to a rollback.The non-activity leakage period that causes the blockchain to be unable to finalize 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 some data from the leftmost block of the Ethereum chain. For example, someone deposits 100 ETH on Ethereum to the top chain. 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 incorrect transaction (i.e. the deposit of 100 ETH) still exists on the top chain. This vulnerability may lead to the issuance of currency, turning the bridged ETH on the top chain into partial reserves.
There are two methods to solve this problem:
1. The top chain can only read blocks that have been finalized on Ethereum, so it never needs to roll back;
2. If Ethereum undergoes a rollback, the top chain may also undergo 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. The latter is harder to implement, but can ensure optimal functionality at all times.
Please note that the first method does have a special case. If Ethereum undergoes 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 need to roll back to switch to the correct block. It is unnecessary to write code to handle this situation in advance; it can be addressed by hard forking the top chain.
The ability of the blockchain to read Ethereum without trust has two important reasons:
First, this ability reduces security issues related to bridging tokens issued on Ethereum (or other layer-two solutions) to that chain;
Second, this ability allows for the creation of account abstract wallets that use shared key storage structures to securely hold assets on that chain.
Although controversial, the importance of the first method has been widely recognized. Similarly, the second method is also important, as it means you can have a wallet that can easily change keys and hold assets on many different chains.
Suppose 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, verifies if any block headers submitted to it come with valid certificates 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 be built on this foundation, such as token deposits and withdrawals. Once such a bridge is established, does it provide any asset security guarantees we mentioned earlier?
So far, not yet! There are two reasons:
1. We are verifying block signatures, but not verifying if state transitions are 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 those assets;
2. The top chain still cannot read Ethereum. Therefore, you cannot deposit Ethereum’s local assets into the top chain without relying on other (potentially insecure) third-party bridges.
Now, let’s build the bridge as a verification bridge: it not only verifies consensus, but also verifies if the state of any new block computed with ZK-SNARK proof is correct.
Once this step is completed, 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 reveal data that allows users to withdraw funds by demanding ransom). 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 bridging contract in the top chain that verifies finalized Ethereum blocks;
2. Include a recent Ethereum block hash in each block of the top chain, and use fork selection rules to enforce hash linking. In other words, the top chain block itself linking to an Ethereum block off the main chain is a non-main chain. If the Ethereum block linked to by the top chain block initially was on the main chain but later became off the main chain, the top chain block must also become off the main chain.
These purple links can be hash links or bridging contracts that verify Ethereum consensus
Is this enough? In fact, it is not enough, as there are some small edge cases:
What happens if Ethereum suffers a 51% attack?
How to handle Ethereum hard fork upgrades?
How to handle hard fork upgrades for your chain?
A 51% attack on Ethereum will have similar consequences to a 51% attack on the top chain, but in reverse. A hard fork of Ethereum may render the Ethereum bridge in the top chain ineffective. A social commitment, i.e. if Ethereum reverts a finalized block, the top chain will revert as well, and if Ethereum undergoes a hard fork, the top chain will also undergo a hard fork, is the cleanest way to address this issue.
Such a commitment may never need to be actually executed: if the governance mechanism of the top chain detects evidence of a potential attack or hard fork, it can activate the governance mechanism and only hard fork the top chain if the governance mechanism fails.
For the third issue, the only viable answer is to set up some form of governance mechanism on Ethereum to allow bridging contracts on Ethereum to be aware of hard fork upgrades on the top chain.
In summary, bidirectional verification bridges almost make the blockchain a validium. The main remaining element is a social commitment, i.e. if Ethereum experiences anomalies that cause the bridging contract to malfunction, another blockchain will hard fork in response.
“Connecting to Ethereum” has two key dimensions:
Security of withdrawals to Ethereum;
Security of reading from Ethereum.
Both are very important and have different considerations. There is a continuum in both cases:
Please note, each dimension has two different metrics (in fact, there are four dimensions): security of withdrawals can be measured by (i) security level, and (ii) how many users or use cases benefit from the highest security level;
While security of reading can be measured by (i) how fast the chain can read Ethereum blocks, especially the difference between finalized blocks and any block, and (ii) the level of social commitment when the chain is dealing with edge scenarios like 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 crucial. For other applications, accepting looser conditions for greater scalability may be acceptable. In many cases, starting with looser conditions today and transitioning gradually to tighter coupling over the next decade as technology improves may be the optimal choice.
Source: BlockBeats.