Original author -Vitalik.eth
Compile - Odaily 0xAyA
The Ethereum Layer 2 ecosystem has been expanding rapidly over the past year. The ZK-EVM Rollup ecosystem, represented by Starknet, Arbitrum, Optimism and Scroll, has made great progress in improving security.L2beatThe page provides a good summary of the status of each project. In addition, we have also seen some teams building sidechains also starting to build Rollup (Polygon), some Layer 1 projects trying to migrate to Validium (Celo) and making new efforts (Linea, Zeth, etc.).
As a result, Layer 2 projects tend to become more heterogeneous. I expect this trend to continue and here’s why:
Some currently independent Layer 1 projects are looking to get closer to the Ethereum ecosystem，And may become Layer 2.These projects may require a gradual transition. Switching now will result in reduced usability because the technology isnt ready to put everything on Rollup, but switching too late may sacrifice momentum and be too late to make any sense.
Some centralized projects want to provide users with more security guarantees and are exploring blockchain-based approaches.In many cases, these projects may have previously explored “permissioned consortium chains.” In fact, they may only need a “middle layer” level of decentralization. Additionally, they typically have very high throughput, making them not even suitable for rollups, at least in the short term.
Non-financial applications, such as gaming or social media, want to be decentralized but only need a middle layer of security.Social media, for example, actually involves treating different parts of the application differently: low-frequency, high-value activities like username registration and account recovery, which should be done on Rollup; high-frequency, low-value activities like posting and voting. activities require lower security. If your posts disappear because of a chain failure, thats an acceptable price; but if a chain failure causes you to lose your account, thats a big problem.
An important question is that paying smaller but still visible rollup fees will be acceptable in the short term for current Ethereum Layer 1 applications and users, but not for users outside the blockchain world. Acceptance: If your previous fee was $1, then paying $0.10 is more acceptable; but if your previous fee was $0, then paying $0.10 is less acceptable. This applies both to current centralized applications and to smaller Layer 1 projects, which often have very low fees indeed given their smaller user bases.
The question that arises is: Which of these complex trade-offs between Rollup, Validium, and other systems is reasonable for a given application?
Rollups、Validiums、Disconnected
The first dimension of security and scale we will explore can be described as follows:If you own an asset issued on Layer 1, then deposit it into Layer 2, and then transfer it to your account, are you sure you can get that asset back to Layer 1?
There is also a similar question:What are the technology choices that lead to this guarantee, and what are the trade-offs behind this technology choice?
We can simply use a table to describe this problem:
It is worth mentioning that,This is a simplified architecture, and there are many intermediate options. For example:
Somewhere between Rollup and Validium: A Validium allows anyone to make on-chain payments to cover transaction fees, at which point the operator will be forced to provide some data to the chain or lose their deposit.
Between Plasma and Validium: The Plasma system provides security guarantees and off-chain data availability (DA) similar to Rollup, but only supports a limited number of applications. A system can provide a complete EVM and provide Plasma-level assurance to users who do not use those more complex applications, and provide Validium-level assurance to users who use those applications.
These intermediate options can be viewed as a technology spectrum between Rollup and Validium. But what motivates an app to choose a particular point on the spectrum, rather than the far left or far right? There are two main factors here:
Ethereum’s own data availability costs will gradually decrease as the technology improves. Ethereum’s next hard fork, Dencun, introduced EIP-4844 (also known as"proto-danksharding"), providing approximately 32 kB/sec of on-chain DA. Over the next few years, this number is expected to gradually increase as full danksharding is rolled out, ultimately reaching a DA target of approximately 1.3 MB/sec. At the same time, improvements in data compression will allow us to do more with the same amount of data.
The needs of the application itself: How much do users lose from high fees relative to problems with the application?Financial applications stand to lose more from application failures; gaming and social media involve a lot of activity per user and the value of the activity is relatively low, so the security trade-offs are different for them.
The trade-off roughly looks like this:
Another partial guarantee worth mentioning isPre-confirmations. A pre-confirmation is a message signed by some participant in Rollup or Validium that says we prove that these transactions are included in this order and that the post-state root is this. These participants may sign a pre-confirmation that is inconsistent with what actually happens later; but if they do, they will burn a deposit. This is useful for low-value applications such as consumer payments, while high-value applications like multi-million dollar financial transfers may wait for regular confirmations backed by the full security of the system.
Pre-confirmation can be seen as another example of a hybrid system, similar to the Plasma/Validium hybrid system mentioned above, but this time between a Rollup (or Validium) with full security but higher latency and a higher Mix between systems with lower security levels but lower latency. Applications that require lower latency receive lower security, but can coexist in the same ecosystem with applications that require higher latency in exchange for maximum security.
Reading Ethereum without permission
Another less considered but still very important form of connection is withRelated to the system’s ability to read the Ethereum blockchain.In particular, this includes being able to rollback Ethereum if it needs to. To understand why this is valuable, consider the following scenario:
Suppose, as shown in the figure, that the Ethereum chain rolls back. This may be a temporary failure within an epoch and the chain is not finalized, or it may be that the network verification is inactive and too many validators are offline causing the chain to not be finalized for a long period of time.
The worst case scenario this could lead to 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 is not rolled back. As a result, future blocks of the top chain correctly follow new blocks of the new correct Ethereum chain, but now the results of the wrong old chain (i.e. the deposit of 100 ETH) still exist in the top chain. Such a vulnerability could allow the creation of currency, turning bridged ETH on the top chain into a fractional reserve.
There are two ways to solve this problem:
The top chain can only read the Ethereum blocks that have been finalized, so there is no need to perform rollback operations.
If Ethereum rolls back, the top chain can also roll back.
Both can prevent this problem from happening. The former is easier to implement, but may result in a prolonged loss of functionality if Ethereum enters a period of inactivity. The latter is more difficult to achieve, but always ensures optimal functionality.
It should be noted that there is a special case in the first method (1). If a 51% attack creates two incompatible blocks on Ethereum, and both blocks are finalized at the same time, the top chain may choose the wrong block (i.e., a block that is not ultimately supported by the Ethereum community consensus). block) and must do a rollback to switch to the correct block. Arguably, there is no need to write code to handle this situation in advance; it can be handled by hard forking the top chain.
The ability of a chain to read data on Ethereum without permission is extremely valuable for the following reasons:
Reduce the security issues involved when moving tokens issued on Ethereum (or other Layer 2) across chains to that chain.
Account abstraction wallets are allowed to securely hold assets on the chain using a shared key storage structure.
The first reason is important, although this importance may be widely recognized; but the second reason is equally important because it means that you can have a wallet that can easily change the key and maintain it on many different chains. Have assets.
Would having a bridge make the chain Validium?
Suppose the top chain started as a separate chain, and then someone put a cross-chain contract on Ethereum. A cross-chain contract is simply a contract that accepts block headers from the top chain, verifies that any header submitted to it comes with a valid certificate indicating that it was accepted by the consensus of the top chain, and adds that header to the list. Applications can be built on top of this to enable functions such as depositing and withdrawing coins. Once such a bridge is in place, does it provide any of the asset security we mentioned earlier?
So far, not yet! There are two reasons:
We are verifying whether the blockSigned, but the unverified state transition iscorrect or not. So if you have assets issued on Ethereum that are deposited into the top chain, and a validator on the top chain goes rogue, they can sign an invalid state transition and steal those assets.
The top chain still has no way to read Ethereum data. So you cant even deposit Ethereum-native assets to the top chain without relying on other (possibly unsafe) third-party bridges.
Now, lets make this bridge a validating bridge: it not only checks consensus, but also checks a ZK-SNARK, proving that the state of any new block was calculated correctly.
Once completed, the validators of the top chain can no longer steal your funds. They can publish a block containing unusable data, preventing everyone from exiting, but they cannot steal (other than trying to extract a ransom for the user in exchange for leaking data that would allow them to exit). This is the same security model as Validium.
However, we still havent solved the second problem: the top chain cannot read Ethereum.
To do this we need to do one of two things:
Place the cross-chain contract that verifies the final Ethereum block within the top chain.
Let every block in the top chain contain the hash of the most recent Ethereum block, and have a fork-choice rule that enforces hash chaining. That is, a top-chain block that links to an Ethereum block that is not in the canonical chain is itself non-canonical, and if a top-chain block links to an Ethereum block that was originally canonical but later became If it becomes non-canonical, then the top chain block must also become non-canonical.
The purple link in the picture can be a hash link or a bridge contract that verifies the Ethereum consensus.
Is this enough? It turns out thats not enough, because there are some small special cases:
What would happen if Ethereum was subject to a 51% attack?
How to handle Ethereum hard fork upgrade?
How to handle hard fork upgrade of top chain?
A 51% attack on Ethereum would have similar consequences to a 51% attack on the top chain, but in the opposite direction. A hard fork of Ethereum may render the Ethereum bridge within the top chain no longer valid. The cleanest solution to this problem is to promise that if Ethereum rolls back a finalized block, the top chain will also roll back, and if Ethereum undergoes a hard fork, the top chain will also undergo a hard fork. Such a promise may never need to be actually enforced: you could activate a governance mechanism on the top chain if it sees evidence of a possible attack or hard fork, and only hard fork the top chain if the governance mechanism fails.
The only feasible answer to question (3) is to have some form of governance mechanism 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 chain Validium. The main remaining issue is the social commitment that the other chain will hard fork in the event something unusual happens to Ethereum that prevents the bridge from working.
in conclusion
There are two key dimensions to “connection to Ethereum”:
Security of Withdrawing to Ethereum
Security of reading Ethereum data
Both dimensions are important and have different considerations. In both cases a lineage exists:
Note that each dimension is measured in two different ways (so there are actually four dimensions?): Extract security by (i) security level and (ii) users or use cases that benefit from the highest security level Read security can be measured as a percentage of Ethereums blocks, and read security can be measured by (i) the links ability to quickly read Ethereums blocks, especially blocks that have been finalized, and (ii) the links ability to process The strength of social commitment during edge cases such as 51% attacks and hard forks.
There are many items of value in this design space. For some applications, high security and tight connectivity are important. For other applications, some looser connectivity may be acceptable for greater scalability. In many cases, starting with some looser approach today and gradually transitioning to tighter connections as technology improves over the next decade may be the best option.
