Title: Different Types of Layer 2s
The ecosystem has rapidly expanded over the past year. The ZK-EVM rollup ecosystem, represented by StarkNet, Arbitrum, Optimism, and Scroll, has made significant progress in improving security, with L2beat providing a comprehensive summary of each project’s status.
In addition, we are seeing teams building sidechains and starting to develop rollup solutions (such as Polygon). Some L1 projects are also moving towards validity verification (such as Celo), and there are new attempts (such as Linea, Zeth, etc.).
One inevitable result is that we are seeing L2 projects becoming more heterogeneous. I expect this trend to continue for several reasons:
1. Some independent L1 projects are seeking closer integration with the Ethereum ecosystem and may transition to L2 projects. These projects may prefer a phased transition as an immediate one could reduce availability due to technical readiness. A later transition could sacrifice momentum and lack practical significance.
2. Some centralized projects are exploring blockchain-based approaches to provide more security for their users. These projects may only need a level of “semi-centralization” and often have very high throughput, making rollup solutions less suitable in the short term.
3. Non-financial applications, such as games or social media, desire decentralization but only require a certain level of security. For example, rare and high-value activities like user registration and account recovery should be completed in a rollup solution, while frequent and low-value activities like posting and voting require less security. Losing a post due to blockchain failure is an acceptable cost, but losing an account is a bigger problem.
One important consideration is that while Ethereum L1 applications and users are willing to pay a visible but smaller rollup fee in the short term, users from outside the blockchain world are less inclined to do so. The acceptability of paying $0.10 after previously paying $1 is easier, but paying $0 after previously paying $0 is harder. This applies to both centralized applications and smaller L1 projects with low fees and a smaller user base.
A natural question arises: for a specific application, what is a reasonable choice among rollup solutions, validiums, and other systems in these complex trade-offs?
The first dimension of security and scalability we will explore can be described as follows: if you have an asset issued on L1, then deposit it on L2 and transfer it back to L1, how much assurance do you have that the asset can be retrieved on L1?
There is also the question of what technical choices lead to this level of assurance and what trade-offs are involved.
We can use a simple chart to illustrate this issue. It is worth noting that this is a simplified scenario with many intermediate options. For example:
– Between rollups and validiums: In a validium, anyone can make on-chain payments to pay for transaction fees, and operators are required to provide some data on-chain or risk losing their deposit.
– Between plasma and validium: A Plasma system provides similar security guarantees as rollup with off-chain data availability but supports a limited number of applications. A system can offer full EVM and provide Plasma-level guarantees for users who don’t use these more complex applications, and validium-level guarantees for users who do.
These intermediate options can be viewed as a spectrum between rollups and validiums. But what drives an application to choose a specific point on this spectrum rather than a point further left or right? There are two main factors:
1. The cost of Ethereum native data availability, which will decrease over time as technology advances.
2. The application’s own requirements: how severe are the losses for users in terms of high fees versus application issues? Financial applications would suffer more from application failures, while games and social media involve a large volume of low-value user activities, making different security trade-offs meaningful for them.
Another important type to consider is pre-confirmations. Pre-confirmations are messages signed by a group 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 deviates from reality, but if they do, their deposit will be destroyed. This is 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 mixed system, similar to the mentioned “plasma/validium mix,” but this time mixing a rollup (or validium) with full security but high latency with a system of lower security but low latency. Applications requiring low latency gain lower security but can coexist in the same ecosystem with applications that prioritize maximum security at the cost of higher latency.
Another important but less considered form of connection relates to the ability of systems to read the Ethereum blockchain. Specifically, this includes the ability for a system to roll back when Ethereum rolls back. To understand why this is valuable, consider the following scenario:
Suppose Ethereum experiences a rollback as shown in the diagram. This could be a temporary interruption within an epoch where the blockchain hasn’t finalized yet, or it could be due to too many validators being offline, leading to a fork.
In such cases, having the ability to roll back in sync with Ethereum can prevent users from losing funds or experiencing other issues. This is particularly valuable for applications that prioritize security above all else.
In conclusion, as the L2 ecosystem continues to expand, we are seeing a shift towards more heterogeneous L2 projects. The choice between rollup solutions, validiums, and other systems depends on a variety of factors, including the application’s requirements, the cost of Ethereum native data availability, and the need for pre-confirmations or the ability to roll back in sync with Ethereum.The non-activity leak period that leads to the inability of the blockchain to reach a final consensus for an extended period of time can result in the following worst-case scenario: 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 (i.e. the deposit of 100 ETH) still exists in the top chain. This vulnerability can lead to the inflation of currency, turning the bridged ETH on the top chain into partially reserved funds.
There are two methods to solve this problem:
1. The top chain can only read Ethereum blocks that have reached a final consensus, thus eliminating the need for rollbacks.
2. If Ethereum experiences a rollback, the top chain can also roll back. Both methods can prevent this issue. The former is easier to implement but may result in a loss of functionality for an extended period of time if Ethereum enters a non-activity leak period. The latter is more difficult to implement but ensures consistent optimal functionality.
Please note that the first method does have a special case. If Ethereum experiences a 51% attack, resulting in the simultaneous appearance of two new incompatible blocks, both of which appear to have reached a final consensus, the top chain may choose the wrong block (i.e. the block not supported by Ethereum’s social consensus) and would need to roll back to switch to the correct block. It can be said that it is unnecessary to pre-write code to handle this situation; this problem can be addressed by a hard fork of the top chain.
The ability of the blockchain to read Ethereum without the need for trust has two important reasons:
First, this ability reduces the security issues involved in bridging tokens issued on Ethereum (or other layer-two solutions) to the chain.
Second, this ability allows account-based abstract wallets that use shared key storage structures to securely hold assets on the chain.
Although there is debate, 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.
Suppose the top chain was initially 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 whether any block header submitted to it is accompanied by a valid certificate proving that the block header has been accepted by the consensus of the top chain and adds the block header to the list.
Applications can be built on this basis, such as token deposits and withdrawals. Once such a bridge is established, does it provide the asset security guarantees we mentioned earlier?
So far, it does not! There are two reasons:
1. We are verifying the signatures of the blocks, but we are not verifying if the 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 and steal 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 (potentially insecure) third-party bridge.
Now, let’s construct the bridge as a verifying bridge: it not only verifies consensus but also verifies the correctness of any new block’s state computed with ZK-SNARK proofs.
Once this step is completed, the validators of the top chain will not be able to steal your funds. They can publish a block with invalid data to prevent anyone from withdrawing funds, but they cannot steal the funds (unless they attempt to reveal the data that allows users to withdraw funds by demanding a ransom). This has the same security model as validium.
However, we still have not 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 bridging contract in the top chain that verifies Ethereum blocks that have reached a final consensus.
2. Include the hash of the most recent Ethereum block in each block of the top chain and enforce hash linking using forking selection rules. That is, the top chain block itself that links to an Ethereum block on a non-main chain is also a non-main chain. If the top chain block linked to an Ethereum block that was initially 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 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 in Ethereum?
How to handle hard fork upgrades in your own chain?
A 51% attack on Ethereum would have similar consequences to a 51% attack on the top chain, but the situation is reversed. A hard fork in Ethereum could render the Ethereum bridging in the top chain ineffective. A social commitment, that is, if Ethereum rolls back a block that has reached a final consensus, the top chain will roll back as well, and if Ethereum undergoes a hard fork, the top chain will undergo a hard fork, is the cleanest way to solve this problem.
Such a commitment may never need to be truly executed: if the governance mechanism of the top chain detects evidence of an impending attack or hard fork, the governance mechanism can be activated and a hard fork of the top chain would only occur if the governance mechanism fails.
For the third problem, the only viable solution is to set up some form of governance mechanism on Ethereum to allow the bridging contract on Ethereum to be aware of hard fork upgrades in the top chain.
In summary, bidirectional verifying bridges are almost sufficient to make the blockchain a validium. The main remaining element is a social commitment that responds to abnormal situations in Ethereum that render the bridging contract on the top chain unable to function properly by initiating a hard fork on another chain.
“Connected to Ethereum” has two key dimensions:
Security in withdrawing to Ethereum;
Security in reading Ethereum.
Both are very important and have different considerations. In both cases, there is a continuous spectrum:
Please note that each dimension has two different measures (in fact, there are four dimensions): security in withdrawal can be measured by (i) security level and (ii) the number of users or use cases benefiting from the highest security level;
And security in reading can be measured by (i) how quickly the chain can read Ethereum blocks, especially the difference between final confirmed blocks and any blocks, and (ii) the level of social commitment when dealing with edge scenarios such as 51% attacks and hard forks.
There is value in many areas of this design space for projects. For certain applications, high security and tight coupling are crucial. For other applications, accepting looser conditions in order to achieve greater scalability may be acceptable. 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
