L2 projects will become increasingly heterogeneous.
Original title: "Different types of layer 2s"
Original article by: Vitalik Buterin
Original compilation: BlockBeats
The ecosystem has expanded rapidly over the past year. The ZK-EVM rollup ecosystem, traditionally represented by StarkNet, Arbitrum, Optimism, and Scroll, has been progressing rapidly to continuously improve its security, and the L2beat page does a good job summarizing the status of each project.
In addition, we have also seen that some teams are building side chains and also starting to build rollup solutions (such as Polygon), some L1 projects are trying to develop in the direction of validity verification (such as Celo), and there are also new attempts (such as Linea, Zeth …).
One of the inevitable consequences of this is that we see L2 projects tending to become more heterogeneous (i.e. "isomerization"). Translator's Note: In the field of encryption, "isomerization" refers to the coexistence or coexistence of things of different kinds or properties. Mixed together. This term is often used to describe different blockchains, protocols, technologies, or assets that have different characteristics, rules, or properties). I expect this trend to continue and here’s why:
Currently, some independent L1 projects are seeking to engage more closely with the Ethereum ecosystem and potentially transform into L2 projects. These projects may wish to adopt a phased transition approach. Doing a wholesale transition immediately will reduce availability because the technology isn't ready to put everything into a rollup scenario. And in a later overall transition, momentum may be sacrificed and too late to be of practical significance.
Some centralized projects want to provide more security to their users and are exploring blockchain-based approaches. In many cases, these projects may have looked into “permissioned consortium chains” in the past. In fact, they may only need to reach a "semi-centralized" level. Additionally, they typically have very high throughput and are not suitable for rollup scenarios, at least in the short term.
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 app differently: rare and high-value activities like username registration and account recovery should be done in a rollup scenario, but frequent ones like posts and polls And low-value activities require less security. If the blockchain fails and your posts disappear, that's an acceptable price; but if the blockchain fails and you lose your account, that's a much higher price. Big question.
An important theme is that while applications and users currently on Ethereum L1 are willing to pay smaller 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 If you have paid $1 before, it will be more acceptable to pay $0.10, whereas if you paid $0 before, it will be less acceptable. This applies to applications that are still centralized today, as well as smaller L1 projects that often have extremely low fees despite their smaller user base.
A natural question is: Which of these complex trade-offs between rollup schemes, validitys, and other systems is justified for a given application?
Rollups vs Validiums vs Disconnected Systems
The first dimension of security and scalability we will explore can be described as follows: if you own an asset issued on L1, then deposit it into L2, and then transfer it to you, how much do you gain What is the guarantee that the assets can be retrieved back to L1?
There is also a related question: What technology choice leads to this level of assurance, and what are the trade-offs of that technology choice?
We can describe this problem with a simple diagram:
It's worth mentioning that this is a simplified scenario where many intermediate options exist. 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 information to the chain or 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 a full EVM with Plasma-level assurance for those who do not use these more complex applications, and validium-level assurance for those who do.
These intermediate options can be thought of as being on a spectrum between rollup and validium. But what motivates an application to choose a specific point on that spectrum, rather than some point further to the left or to the right? Here, there are two main factors:
The cost of native data availability on Ethereum will decrease over time as the technology develops. Ethereum’s next hard fork, Dencun, introduced EIP-4844 (aka “proto-danksharding”), which provides on-chain data availability of approximately 32 kB/sec. It is expected that this data availability will gradually increase over the next few years as full danksharding is rolled out, with an end goal of around 1.3 MB/sec data availability. At the same time, improvements in data compression will allow us to achieve more functionality with the same amount of data.
The application's own needs: How serious is the user's loss in terms of high fees relative to problems with the application? Financial applications stand to lose more from application failure; gaming and social media involve a lot of user activity and relatively low-value activities, so for them different security tradeoffs make sense.
This trade-off roughly looks like this:
Another type worth mentioning is pre-confirmations. A pre-confirmation is a message signed by a group of participants in a rollup or validation that says "we prove 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 it does, their deposits will be destroyed. This is 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 backed by the complete security of the system.
Prevalidation can be seen as another example of a hybrid system, similar to the "plasma/validium hybrid" mentioned above, but this time between a rollup (or validation) with full security but high latency and a lower security Mix between high-level but low-latency systems. Apps that require lower latency gain lower security, but can coexist in the same ecosystem with apps that are willing to tolerate higher latency for maximum security.
Read Ethereum without trust
Another less considered, but still very important, form of connectivity relates to the system’s ability to read the Ethereum blockchain. Specifically, this includes the system’s ability to roll back should a rollback occur on Ethereum. To understand why this is valuable, consider the following scenario:
Suppose a rollback occurs on the Ethereum blockchain as shown in the figure. This could be a temporary outage during an epoch when the blockchain is not yet finalized, or it could be a period of inactive leakage where the blockchain is not finalized for an extended period of time because too many validators are offline.
The worst possible scenario that can 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 on Ethereum deposits 100 ETH into the top chain. Then Ethereum rolled back, however the top chain did not roll back. The result is that future blocks on the top chain correctly follow blocks on the new, correct Ethereum blockchain, but the wrong transaction (i.e. the deposit of 100 ETH) still exists in the top chain. Such a vulnerability could lead to additional issuance of the currency, turning bridged ETH on the top chain into fractional reserves.
There are two ways to solve this problem:
1. The top chain can only read blocks that have been finalized by Ethereum, so it never needs to be rolled back;
2. If Ethereum rolls back, the top chain may also roll back. Both can prevent this problem. The former is easier to implement, but could result in a loss of functionality for an extended period of time if Ethereum enters a period of inactive leakage. The latter is more difficult to implement, but ensures optimal functionality at all times.
Note that the first approach does have a special case. If a 51% attack occurs on Ethereum, causing two new incompatible blocks to appear at the same time, both of which appear to be finalized, then the top chain may choose the wrong block (i.e. a zone that is not ultimately supported by the Ethereum social consensus) block), and a rollback is required to switch to the correct block. Arguably, it is not necessary to write code in advance to handle this situation; this problem can be handled by hard forking the top chain.
There are two important reasons for the blockchain’s ability to read Ethereum without trust:
First, this ability could reduce the security concerns involved in bridging tokens issued on Ethereum (or other second-layer solutions) to that chain;
Secondly, this capability enables account abstraction wallets that use a shared key storage structure to securely hold assets on the chain.
Although controversial, the importance of the first approach is widely recognized. Again, the second approach is important because it means you can have a wallet that can easily change keys and hold assets on many different chains.
Does owning a bridge make it validium?
Let's say the top chain was initially launched as a standalone chain, and then someone deployed a bridge contract on Ethereum. A bridge contract is simply a contract that accepts block headers from the top chain, verifies that 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 build functionality on top of this, such as deposits and withdrawals of tokens. Once such a bridge is established, does it provide any of the asset security we mentioned earlier?
So far, not yet! There are two reasons:
1. We are verifying the signature of the block, but not verifying whether the state transition is correct. So if you deposit assets issued on Ethereum to the top chain, and the validators of the top chain become dishonest, they can sign an invalid state transition and thereby steal those assets;
2. The top chain still cannot read Ethereum. Therefore, you cannot deposit Ethereum-native assets to the top chain without relying on other (possibly unsafe) third-party bridges.
Now, let's construct the bridge as a validating bridge: it not only verifies consensus, but also verifies that the state of any new block calculated 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 with unavailable data, preventing everyone from withdrawing funds, but they cannot steal funds (without trying to reveal the data that allows them to withdraw funds by demanding a ransom from the user). This has the same security model as validium.
However, we still haven’t solved the second problem: the top chain cannot read Ethereum’s data. To achieve this we need to do one of two things:
1. Place a bridge contract in the top chain that verifies the finalized Ethereum block;
2. Include a hash of the most recent Ethereum block in each block of the top chain and use fork-choice rules to force hash chaining. In other words, the top chain block that will be linked to the Ethereum block on the non-main chain is itself non-main chain. If a top chain block links to an Ethereum block that was originally on the main chain but later became non-main chain, the top chain block must also become non-main chain.
These purple links can be hash links or bridge contracts that verify the Ethereum consensus.
Is this enough? Actually, not enough, because there are some small edge cases:
What would happen if Ethereum suffered a 51% attack?
How to handle Ethereum hard fork upgrades?
How to handle hard fork upgrades of your chain?
A 51% attack on Ethereum would result in similar consequences to a 51% attack on the top chain, but in reverse. A hard fork of Ethereum could disable the Ethereum bridge within the top chain. A social commitment, that is, if Ethereum restores a finalized block, it will restore it. If Ethereum performs a hard fork, it will perform a hard fork. This is the cleanest way to solve this problem. .
Such a promise may never actually need to be implemented: if the governance body of the top chain discovers evidence that an attack or hard fork may have occurred, the governance body can be activated, and the top chain will be hard forked only if the governance body fails.
The only feasible answer to the third question is to have some form of governance on Ethereum that would make the bridge contract on Ethereum aware of hard fork upgrades to the top chain.
Summary: Two-way verification bridging is almost enough to make a blockchain validium. The main remaining element is a social commitment that if something unusual happens to Ethereum that prevents the bridge contract from working properly, the other blockchain will respond with a hard fork.
in conclusion
"Connecting to Ethereum" has two key dimensions:
Security of withdrawals to Ethereum;
Read the security of Ethereum.
Both are very important and have different considerations. In both cases a continuum exists:
Note that each dimension is measured in two different ways (there are actually four dimensions): Extraction security can be measured by (i) security level, and (ii) how many users or usage cases benefit from the highest security level ;
And read security can be measured by (i) how fast the link can read Ethereum's blocks, especially the difference between a finalized block and any block, and (ii) how fast the link is handling things like 51% attacks and Measured by the degree of social commitment in edge situations such as hard forks.
The value of the project exists in many areas of this design space. For some applications, a high degree of security and tight connectivity are critical. For other applications, more relaxed conditions may be accepted for greater scalability. In many cases, it may be optimal to start using looser conditions today and gradually transition to tighter coupling over the next decade as technology improves.
Original link
This article is reprinted with permission from BlockBeats
This article, Ethereum founder Vitalik Buterin sorts out the differences between various types of Layer 2, first appeared on Zombit.
