Translator’s Note: Since this year, rollup has received widespread attention as a very potential expansion solution. Many second-tier projects using rollup technology are online on the main network or test network. Vitalik himself has repeatedly called the community to pay attention and Use rollup. Earlier this month, Vitalik wrote an article on the Ethereum Magicians Forum in detail. If rollup is used as the future development center of Ethereum, what adjustments should be made to the roadmap of Ethereum?
It should be noted that the Ethereum community adopts a market-type development model-in this model, there is no centralized center, instead transparent and open discussions. In other words, after Vitalik himself posted this post, it does not mean that Ethereum’s roadmap will be changed accordingly. The market model greatly enhances the inclusiveness of Ethereum and the possibility of group wisdom emerging in the evolution process. Therefore, when rollup gradually shows its potential in the evolution of the blockchain world, the discussion initiated by Vitalik is bound to meet Make rollup play a more important role in the evolution of Ethereum.
In order to better explain the background of the views in his article, Vitalik has made more detailed supplementary explanations on multiple occasions. We put Vitalik’s social media speeches at the beginning of this article as background introduction and abstract; Vitalik in the ether The post on the Magician Forum is placed in the middle as the main text; at the end, we also selected Vitalik’s Q&A at the ETHGlobal event at the beginning of the month for readers’ reference.
Fragmentation is not cancelled, but superimposed
The current ETH2.0 roadmap consists of 3 stages:
- Phase 0: PoS (this phase is being implemented and will be implemented soon)
- Phase 1: Data fragmentation, but does not include computational fragmentation (that is, the fragmentation chain will “include” data with a capacity of 2 MB/sec, but the data are all dummy data objects, not transactions)
- Phase 2: Transaction fragmentation (fragmented transaction processing function)
- Ethereum’s current TPS is about 15-45, and using Rollup can increase throughput by 100 times. Fragmentation can increase throughput by 64 times. The throughput achieved by these two technologies is superimposed, which means that rollup is superimposed on the basis of shards, and a throughput increase of 6400 times can be achieved.
- But the current roadmap will give rise to an interesting surprise: the vision of realizing sharding applications will not be realized until Phase 2, but the shard rollup can be realized in Phase 1, because rollup only needs to store data on the main chain The function does not require the main chain to realize the calculation function. Therefore, before the complete realization of ETH 2.0, Ethereum has the conditions to expand by 6,400 times.
- Therefore, instead of replacing slices with rollup, rollup is superimposed on slices. In other words, before the implementation of sharding, rollup can achieve a 100-fold increase in throughput, so use rollup as soon as possible!
Ethereum roadmap centered on Rollup
Last week, the Optimism team announced the launch of the first phase of Optimism’s testnet (Chinese translation), and at the same time announced the roadmap to the mainnet. Optimism is not the only team that is implementing optimisitic rollup. Fuel’s rollup is also moving towards the testnet, and Arbitrum is also doing a rollup. The rollup solution based on zk-rollup implemented by Loopring and zkSync has been launched, and the Deversifi based on Starkware technology has also been launched, and users have already used these products on the mainnet. The launch of OMG’s mainnet test version shows that plasma is also moving forward.
At the same time, the gas price on eth1 is climbing to a new high, so that some non-financial dapps are forced to close, and some dapps can only be run on the testnet and miss the mainnet.
The scalability of the system is the meaning of Eth2, and the early stage of Eth2 is also advancing rapidly. But for applications that use the base layer, scalability will not appear until the last major phase of Eth2 (Phase 2), which will take several years. Ironically, in Phase 1 of Eth2, Eth2 can be used as the data availability layer of rollup, which is much earlier than Eth2 can be used by the “traditional” layer of applications (Translator’s Note: That is currently running on eth1 Application).
A summary of these factors leads to a special conclusion: the Ethereum ecosystem is likely to devote itself to rollup (plus some plasma and state channel solutions) as a strategy to achieve scalability in the short and medium term. If this conclusion is used as a premise, we will draw some conclusions regarding the priorities of Ethereum’s core development and ecological development, suggesting a different direction from the current roadmap in a sense. Specifically, what conclusions can we draw?
Short-term roadmap: Promoting ETH1 around rollup
Regarding the short-term direction, a main conclusion is that the scalability of the Ethereum base layer will mainly focus on expanding the amount of data that each block can hold, rather than the efficiency of on-chain computing or IO operations. Because for rollup, the only decisive factor for its scalability is how much data can fit on the chain. Any expansion method that exceeds the current data capacity (about 60 kB/sec) will help further improve the scalability of rollup.
From this perspective, the following basic layer improvements are still meaningful (helping to improve the scalability of rollup): EIP 2929, to ensure that the Ethereum main chain can resist DoS attacks under the current Gas settings. EIP 1559 and EIP 1559 are both OK Realizing the burning of ETH can also make a transaction easier to be packaged in the next block (rollup system needs to rely on the transaction to be confirmed on the main chain) New elliptic curve pre-compilation, which can more fully explore the potential performance of ZK rollup Hexadecimal -> Binary tree changes, and other changes that promote better support for stateless clients (no matter how the main chain is used, stateless clients are very valuable) The importance of account abstraction is slightly weaker, because regardless of L1 Whether to support account abstraction, it can be implemented on L2. Other similar “smart base layer features” will also become relatively less important.
The Eth1 client can be reused by the optimistic rollup client. An optimistic rollup still needs a full node. If the internal state transition rules of the rollup are similar to those of Ethereum, with some modifications (this is the goal of Optimism), then the existing code can be reused to run the full node of the rollup . The work of separating the consensus engine and the state transition engine has been carried out in the context of the merger of eth1+Eth2, and this work can also help achieve the above goals.
It is important to note that projects like TurboGeth are still very important, but the high-throughput rollup client will benefit the most from the eth1 client at the base layer.
Short-term roadmap: Adjust the corresponding infrastructure around Rollup
Currently, the user’s account is on L1, the ENS domain name is on L1, and all applications are running on L1. Everything needs to change. We need to adapt to such a world: the user’s main account, balance, assets, etc. are completely in L2. This will lead to these situations: ENS needs to support the registration and transfer of domain names on L2; see here for a possible proposal on how to achieve this.
The L2 layer protocol should be built into the wallet, not on the web like a dapp. At present, the integration of L2 into dapp/like dapp (for example, Gitcoin’s integration of zksync) requires users to fully trust the dapp, which is much less secure than the status quo. The ideal situation is to make L2 part of the wallet (metamask, status, etc.) itself, so that we can maintain the current trust model. This support should be standardized, so that an application that supports zksync payment will immediately support zksync-inide-Metamask, zksync-inide-Status, etc.
We need to do more work on cross-L2 transfers, so that when assets are transferred between different L2s, the user experience is as instant and seamless as possible. More clearly standardize Yul or something like an intermediate compiled language.
The underlying EVM of Ethereum and the OVM launched by Optimism use slightly different compilation targets, but both can be compiled by Solidity. In order to support an ecosystem with different compilation goals, but at the same time avoiding Solidity’s single culture and accepting multiple languages, it may make sense to more clearly standardize things like Yul as an intermediate language, so that all high-level languages can ( By compiling to intermediate language) is compiled to EVM or OVM.
We can also consider a more explicit intermediate language that is friendly to formal verification, which can handle concepts like variables and ensure basic invariants, thus making formal verification easier.
Economic sustainability advantages of Rollup Centrism
An unavoidable fact is: a cryptocurrency project must achieve financial sustainability. In 2020, this means that a project requires millions or even tens of millions of dollars in funding. Some of them can be provided by common public welfare funding entities (such as Gitcoin Grants or the Ethereum Foundation), but their scale is not enough to reach the above-mentioned funding level. Second-tier projects can raise funds by launching their own tokens-of course, provided that the tokens have real economic value support (that is, the L2 is expected to capture future processing fees).
The second important benefit of the rollup-centric roadmap is that it leaves open space for L2 protocols. These L2 protocols can either directly collect fees/MEV or indirectly issue tokens to obtain development needs. Of funds. An important requirement of the Ethereum base layer is credibility and neutrality, which makes it difficult for public welfare funding within the agreement (imagine how difficult it is to agree on who should get how much money), but L2 establishes its own public welfare funding mechanism (you can also (Conducted on Gitcoin Grants) is much less controversial. Therefore, leaving this space is a good strategic move for the long-term economic sustainability of the entire Ethereum.
In addition to funding issues, the most creative researchers and developers often want to create influence on their own turf, rather than arguing with others about the future of the Ethereum protocol in an influential position. In addition, there are already many existing projects trying to create various platforms. The rollup-centric roadmap provides a clear opportunity for all these projects to enable them to become part of the Ethereum ecosystem while still maintaining a high degree of economic and technological autonomy.
Long-term roadmap
In addition to the above short-term roadmap considerations, a rollup-centric roadmap may also mean reimagining the long-term future of Eth2: a highly secure execution shard that everyone can handle, plus an Scalable data availability layer. To understand why this can be said, consider the following data: Ethereum’s current TPS is about 15.
If everyone transfers to rollup, TPS will reach 3000. Once Phase 1 of Eth2 is implemented, rollup is transferred to the Eth2 shard chain for data storage, and the theoretical maximum TPS can reach 100,000. Eventually, Phase 2 of Eth2 will be implemented, and calculations will be implemented on a fragmented basis. At this time, the TPS is about 1000-5000 TPS. In my opinion, when Eth2 Phase 2 is finally implemented, no one cares anymore. By then, whether we like it or not, everyone has adapted to a world centered on rollup. At that time, it is much easier to continue along the previous path than trying to get everyone to migrate to the basic chain after Eth2 is completed, because there is no obvious benefit of migrating to the basic chain after Eth2 is completed, scalability It will be reduced by 20-100 times. This means that from Eth2 to “Phase 1.5 is complete”, the base layer will shrink again, and only need to focus on doing a few things-namely consensus and data availability.
This may be a more suitable goal for Eth2, because sharding for data availability is much safer than sharding for EVM computing. If you want to verify the dishonest-majority-proof of the fragmented EVM calculation, you need a fraud proof, which requires a strict and potentially risky synchronization assumption of two epochs, but data availability sampling (If you use zero-knowledge proof or polynomial promise completion) it is safe under the asynchronous assumption. This will help distinguish Ethereum from the security model of other sharded Layer 2 chains, which are all sharded at the execution level. The function of Eth2 as the basic layer only needs to be just right (Chinese translation), not very powerful.
In the long run, what should Eth2 do? Stagger the block times on different shards, so that at any time there will always be some shards that will block within a few hundred milliseconds. This allows rollups that run across multiple shards to have ultra-low latency without exposing the chain itself to the risk of ultra-low latency. Improve and consolidate its consensus algorithm to adjust the EVM to make it more friendly to the verification of fraud proofs (for example, this may mean some kind of “framework” feature to prevent the code from leaving the sandbox, or allow SLOAD/SSTORE instructions to be remapped to the account Things other than storage as its data source).
A more compromise proposal
If you don’t agree that the above-mentioned “all the way” is going to the development direction of “Phase 1.5 is complete”, then there is a natural compromise: make Eth2 have a small number of execution shards (for example, 4-8) and more data Fragmentation. Our goal is that the number of execution shards is still small enough. Under special circumstances, ordinary computers can fully verify all execution shards, but the base layer space will still be much larger than the current roadmap.
The basic layer space cannot be too small, because users and applications still need to use the basic layer to perform a series of operations, such as moving between different rollups, submitting fraud proofs, submitting ZK proofs in ZK rollups, and issuing root ERC20 token contracts (of course , Most users will use rollup most of the time, but the base layer contract must be stored somewhere in the base layer…) and so on. And if the cost of each transaction involved in these operations is $140, the user experience is still very poor.
Therefore, if necessary, setting 4-8 execution fragments instead of one can greatly alleviate this problem. And one computer can still verify all the slices. Today, a block can be mined every 13 seconds on Ethereum, and it takes about 200-500 milliseconds to verify a block, so it is completely feasible to verify 8 threads in a short time. It is conceivable that the client will have such a countermeasure: “As long as the network delay is very low, or the number of committees reaches 80% of the full number, relying on fraud proofs and committees, all shards can be directly verified under special circumstances.”
Questions and answers on this article on ETHGLOBAL
Q: L2 is committed to solving the expansion problem. It has been studied and discussed in the community for many years, but the previous attempts seem to be unsuccessful. How much confidence do you have in rollup? How is this expansion attempt different from before ?
A: I have a more detailed discussion on this issue in my blog post (Chinese translation). My main point is that rollup is different from state channels and plasma. For expansion, there are two things to expand: expansion calculation and expansion data availability.
My point is that neither state channels nor plasma solve the data availability problem. They use a special kind of technique related to the application scenario to try to solve this problem. The difference from the previous two is that rollup does not put everything off-chain, but puts calculations off-chain, but stores a certain amount of data (such as 10, 16, 50 bytes) on the chain. This is the reason why the expansion performance of rollup is limited. In other words, Rollup is more compromised, sacrificing some scalability in order to support arbitrary state machines.
For plasma, at first we thought that we could solve the problem of running arbitrary state machines in plasma, but in the end we realized that this was impossible. But for rollup, there is some mathematical and technical evidence to prove that rollup can achieve these functions-any state machine, that is, a certain Turing completeness. In practice, rollup has been running successfully for some time. For example, there are already 3 DEXs that use rollup. You can also use rollup when donating gitcoin. Sythentix and other projects are tested in the testnet that supports evm.
It can be said that the unsolved problems in the state channel and plasma have been gradually solved in rollup.
Q: Currently L1 has composability/interoperability, do you think it will still have it in the future? From another perspective, do you think there will be multiple rollups coexisting in the future, or a winner takes all?
A: This is a good question. I think some rollups will dominate at the end. I think rollup has both network effects and anti-network effects. The main anti-network effect is: the larger the TPS, the more difficult it is to run a rollup full node, which will reduce its availability to a certain extent. On the other hand, there are currently several different technical routes for rollup. I hope that these technical routes and the corresponding technical features will be tested in the short to medium term. In the long run, maybe a certain rollup will be winner-takes-all, but I’m not sure yet🙂
Q: You described a possible vision in your article. When do you think the Ethereum base layer will stabilize? Or will it continue to improve iteratively?
A: In the roadmap I proposed, I hope that Ethereum 2.0 will reach a basically stable state at the 1.5 stage, which is why I mentioned “complete at 1.5 stage” in my article. However, there will be continuous technical iterations after this. These technical iterations mainly include adding more zero-knowledge proofs to improve security and efficiency, changing the consensus mechanism from FFG to CBC, and switching cryptographic primitives to post-quantum cryptography Learn primitives. These improvements will basically not affect the economic system and basic security features of Ethereum. I definitely look forward to continuous iterative optimization of technology for a long time, of course these optimizations are more close to the operation and maintenance level.
