Source | Ethereum Enthusiasts

Author: Vitalik

Translator's note: This year, rollup has received widespread attention as a very promising expansion solution. Several second-layer projects using rollup technology have been launched on the mainnet or testnet, and Vitalik himself has repeatedly called on the community to pay attention to and use rollup. Earlier this month, Vitalik wrote an article on the Ethereum Magician Forum to explain in detail how Ethereum's roadmap should be adjusted if rollup is used as the center of Ethereum's future development.

It is important to note that the Ethereum community adopts a market-based development model, in which there is no centralized center, but instead a transparent and open discussion. That is to say, after Vitalik himself posted this post, it does not mean that the Ethereum roadmap will be changed immediately. The market model greatly enhances the inclusiveness of Ethereum and the possibility of collective wisdom emerging during its evolution. Therefore, when rollup gradually shows its potential in the evolution of the blockchain world, the discussion initiated by Vitalik will inevitably make rollup play a more important role in the evolution of Ethereum.

In order to better illustrate the background of the views in his article, Vitalik made more detailed supplementary explanations on multiple occasions. We put Vitalik’s relevant remarks on social media at the beginning of this article as a background introduction and summary; Vitalik’s post on the Ethereum Magician Forum is placed in the middle as the main text; finally, we also excerpted Vitalik’s Q&A at the ETHGlobal event at the beginning of the month for readers’ reference.

The fragments are not cancelled, they are just superimposed.

The current ETH2.0 roadmap consists of 3 phases:

Phase 0: PoS (this phase is being implemented and will be implemented soon)

Phase 1: Data sharding, but not computational sharding (i.e., the shard chain will “contain” up to 2 MB/sec of data, but the data will be dummy data objects, not transactions)

Phase 2: Transaction Sharding (Sharded Transaction Processing Function)

Ethereum's current TPS is about 15-45. Using Rollup can increase throughput by 100 times. Sharding can increase throughput by 64 times. Superimposing the throughput achieved by these two technologies, that is, superimposing rollup on sharding, can achieve a 6400-fold increase in throughput.

However, the current roadmap will lead to an interesting surprise: the vision of sharded applications will not be realized until Phase 2, but sharded rollup can be realized in Phase 1, because rollup only needs to use the function of storing data on the main chain, and does not require the main chain to realize computing functions. Therefore, before ETH 2.0 is fully implemented, Ethereum has the conditions for expansion 6,400 times.

Therefore, rollup is not used to replace sharding, but to superimpose rollup on sharding. In other words, before sharding is implemented, rollup can already 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 announced a roadmap towards the mainnet launch. Optimism is not the only team that is implementing optimisitic rollups. Fuel's rollup is also moving towards the testnet, and Arbitrum is also working on a rollup. The zk-rollup-based rollup solutions implemented by Loopring and zkSync are already online, and Deversifi based on Starkware technology is also online, and users have already used these products on the mainnet. The launch of OMG's mainnet beta version shows that plasma is also moving forward. At the same time, the price of gas on eth1 is climbing to new highs, so that some non-financial dapps are forced to close, and some dapps can only run on the testnet and miss the mainnet.

Scalability of the system is inherent in Eth2, and the early stages of Eth2 are advancing rapidly. But for applications using the base layer, scalability will not appear until the last major phase of Eth2 (Phase 2), which is still a few years away. Somewhat ironically, Eth2 can be used as a data availability layer for rollups in Phase 1, long before Eth2 can be used by "traditional" layer 1 applications (translator's note: applications currently running on eth1). Putting these factors together leads to a unique conclusion: the Ethereum ecosystem is likely to go all-in on rollups (plus some plasma and state channel solutions) as a strategy for achieving scalability in the near and medium term.

If we take this conclusion as a premise, we will draw some conclusions about the priorities of Ethereum core development and ecosystem development, which implies a direction that is different from the current roadmap in some sense. Specifically, what conclusions can we draw?

Short-term roadmap: Advancing ETH1 around rollups

Regarding the direction in the short term, one main conclusion is that the scalability of Ethereum’s base layer will focus primarily on expanding the amount of data that can be accommodated in each block, rather than the efficiency of on-chain computation or IO operations. Because for rollup, the only determining factor for its scalability is how much data can be accommodated on the chain. Any expansion method that exceeds the current data capacity (about 60 kB/second) will help further improve the scalability of rollup.

From this perspective, the following base layer improvements still make sense (to help improve the scalability of rollups):

EIP 2929, ensuring that the Ethereum main chain can resist DoS attacks under the current Gas settings

EIP 1559, EIP 1559 can both achieve the burning of ETH and make it easier for a transaction to be included in the next block (the rollup system needs to rely on the transaction to be confirmed on the main chain)

New elliptic curve precompilation to more fully explore the potential performance of ZK rollup

Hex -> binary trie changes, and other changes to enable better support for stateless clients (which are valuable regardless of how the main chain is used)

Account abstraction is less important because it can be implemented on L2 regardless of whether L1 supports it. Other similar "clever base layer features" will also become relatively less important.

Eth1 clients can be reused by optimistic rollup clients. Optimistic rollup still requires a full node, and if the state transition rules within the rollup are similar to those of Ethereum with just some modifications (which is the goal of Optimism), then the existing code can be reused to run the rollup full node. The work of separating the consensus engine from the state transition engine is already underway in the context of the eth1+Eth2 merger, 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 ones that will benefit the most from them will be high-throughput rollup clients, not the base-layer eth1 clients.

Short-term roadmap: Adjust the infrastructure around Rollup

Currently, user accounts are on L1, ENS domains are on L1, and applications are also running on L1. Everything needs to change. We need to adapt to a world where users’ main accounts, balances, assets, etc. are completely in L2. This will lead to the following situations:

ENS needs to support registering and transferring names on L2; a possible proposal on how to accomplish this is here.

L2 layer protocols should be built into wallets, rather than being put on a web page like a dapp. Currently, L2 integration into dapps/dapp-likes (such as Gitcoin's integration of zksync) requires the user to fully trust the dapp, which is much less secure than the status quo. The ideal situation would be to have L2 be 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 payments will immediately support zksync-inide-Metamask, zksync-inide-Status, etc.

We need to do more work on cross-L2 transfers to make the transfer of assets between different L2s as instant and seamless as possible.

More explicitly standardize Yul or something similar as an intermediate compilation language. Ethereum's underlying EVM and Optimism's OVM use slightly different compilation targets, but can both be compiled by Solidity. In order to support an ecosystem with different compilation targets, but at the same time avoid Solidity's monoculture and accommodate multiple languages, it might make sense to more explicitly standardize something like Yul as an intermediate language, so that all high-level languages ​​can be compiled to EVM or OVM. We can also consider a more explicitly formal verification-friendly intermediate language that can handle concepts like variables and ensure basic invariants, making formal verification easier.

The Economic Sustainability Advantages of Rollup-Centrism

There is no getting around the fact that a cryptocurrency project must be financially sustainable. In 2020, this means that a project needs millions or even tens of millions of dollars in funding. Some of this can be provided by common public funding entities (such as Gitcoin Grants or the Ethereum Foundation), but their scale is not large enough to reach the above funding levels. Second-layer projects can raise funds by launching their own tokens - of course, the premise is that the token is backed by real economic value (i.e., the expectation that the L2 can capture future transaction fees).

The second important benefit of a rollup-centric roadmap is that it leaves open space for L2 protocols to collect fees/MEV directly or indirectly through token issuance to fund their development. An important requirement of Ethereum’s base layer is credible neutrality, which makes in-protocol public funding difficult (imagine the difficulty of agreeing on who should get how much money), but it is much less controversial for L2 to set up their own public funding mechanism (which can also be done on Gitcoin Grants). Therefore, leaving this space is a good strategic move for the long-term economic sustainability of Ethereum as a whole.

Beyond funding issues, the most creative researchers and developers often want to create influence on their own turf rather than argue with others about the future of the Ethereum protocol from a position of little influence. In addition, there are already many existing projects trying to create various platforms. A rollup-centric roadmap provides a clear opportunity for all of these projects to become part of the Ethereum ecosystem while still maintaining a high degree of economic and technical autonomy.

Long-term roadmap

In addition to these short-term roadmap considerations, a rollup-centric roadmap could also mean reimagining the long-term future of Eth2: a single, highly secure execution shard that anyone can process, coupled with a scalable data availability layer.

To understand why this is true, consider the following data:

Ethereum's current TPS is about 15.

If everyone moves to rollup, TPS will reach 3000.

Once Phase 1 of Eth2 is implemented, the rollup will be 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 realized, implementing computing on a sharded basis, with TPS of about 1000-5000 TPS.

In my opinion, when Eth2 Phase 2 is finally implemented, no one will care. By then, whether we like it or not, everyone will have adapted to a world centered around rollups. By then, it will be much easier to continue on the previous path than to try to get everyone to migrate to the base chain after Eth2 is completed, because migrating to the base chain after Eth2 is completed will have no obvious benefits and scalability will be reduced by 20-100 times.

This means that Eth2 will be “completed by Phase 1.5,” when the base layer shrinks again and only needs to focus on doing a few things well — namely consensus and data availability.

This may be a more appropriate goal for Eth2, as data availability sharding is much safer than EVM computation sharding. Verifying dishonest-majority-proofs for sharded EVM computation requires fraud proofs, which require a strict and potentially risky two-epoch synchrony assumption, but data availability sampling (if done using zero-knowledge proofs or polynomial commitments) is safe under the asynchronous assumption.

This will help differentiate Ethereum’s security model from other sharded layer-2 chains, which are all sharded at the execution level. Eth2’s functionality as a base layer only needs to be good enough, not powerful.

What should Eth2 do in the long run?

Stagger the block times on different shards so that at any given time there are always some shards producing blocks within a few hundred milliseconds of each other. This allows rollups running across multiple shards to have ultra-low latency without exposing the chain itself to the risks of ultra-low latency.

Improve and consolidate its consensus algorithm

Tweak the EVM to make it more friendly to fraud proof verification (e.g. this could mean some kind of “framework” feature to prevent code from escaping the sandbox, or allowing SLOAD/SSTORE instructions to be remapped to something other than account storage as their data source).

All about ZK-SNARKs

A more compromise proposal

If you don’t agree with the above “all the way” to “Phase 1.5 is complete” direction, then there is a natural compromise: make Eth2 have a small number of execution shards (e.g. 4-8) and more data shards. Our goal is that the number of execution shards is still small enough that ordinary computers can fully verify all execution shards in special cases, but the base layer space is still much larger than the current roadmap.

The base layer space cannot be too small, because users and applications still need to use the base layer for a series of operations, such as moving between different rollups, submitting fraud proofs, submitting ZK proofs in ZK rollups, publishing root ERC20 token contracts (of course, most users will use rollups most of the time, but the base layer contract must be stored somewhere in the base layer...), etc. 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 shards instead of 1 can greatly alleviate this problem. And a computer can still verify all shards. Today, a block can be mined every 13 seconds on Ethereum, and it takes an average of about 200-500 milliseconds to verify a block, so it is completely feasible to verify 8 threads in a short period of time. It is conceivable that the client will have such a countermeasure: "As long as the network latency is low, or the number of committee members reaches 80% of the full number, relying on fraud proofs and committees, all shards can be directly verified in special cases."

Q&A on this article on ETHGLOBAL

Q: L2 is committed to solving the scalability problem and has been studied and discussed in the community for many years, but previous attempts seem to be less successful. How confident are you in rollup? How is this expansion attempt different from previous ones?

A: I discuss this in more detail in my blog post (Chinese translation). My main point is that rollup is different from both state channels and plasma. For scaling, there are two things to scale: scaling computation and scaling data availability. My point is that neither state channels nor plasma solve the data availability problem, they use a special class of techniques related to the application scenario to try to solve this problem. Unlike the first two, rollup does not put everything off-chain, but puts the computation off-chain, but stores a certain amount of data (such as 10, 16, 50 bytes) on-chain, which is why rollup's scalability is somewhat limited. In other words, Rollup is more compromised, sacrificing some scalability to support arbitrary state machines. For plasma, at first we thought we could solve the problem of running arbitrary state machines in plasma, but eventually we realized that this was not possible. But for rollup, there is some mathematical and technical evidence that rollup can achieve these functions - arbitrary state machines, that is, some kind of Turing completeness. In practice, rollup has been running successfully for some time. For example, there are already 3 DEXs using rollup. You can also use rollup when donating to gitcoin. Projects such as sythentix are testing in a testnet that supports evm. It can be said that the problems that have not been solved in state channels and plasma have been gradually solved in rollup.

Q: Currently L1 has composability/interoperability. Do you think it will still be available in the future? From another perspective, do you think there will be multiple rollups coexisting in the future, or will it be a winner-takes-all situation?

A: This is a good question. I think some rollups will dominate in the end. I think rollups have both network effects and anti-network effects. The main anti-network effect is: the larger the TPS, the harder 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 rollups, and I hope that these technical routes and corresponding technical features will be tested in the short and medium term. In the long run, maybe one rollup will win, but I'm not sure yet :)

Q: You described a possible vision in the article. When do you think the Ethereum base layer will stabilize? Or will it continue to be iteratively improved?

A: In the roadmap I proposed, I hope that Ethereum 2.0 will reach a basically stable state in phase 1.5, which is why I mentioned "phase 1.5 is completed" in the article. However, there will still be continuous technical iterations after that, which 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 cryptographic primitives. These improvements will basically not affect Ethereum's economic system and basic security features. I absolutely expect that the technology will continue to be iterated and optimized for a long time, and of course these optimizations are more close to the operation and maintenance level.

(over)

Original link:

https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698

https://twitter.com/VitalikButerin/status/1312905882330521600