Vitalik: Ethereum Roadmap Centered on Rollups
source|ethereum-magicians.org
Author | Vitalik Buterin
Author | Vitalik ButerinreleaseOptimism team not long agoFuelreleaseArbitrumThe first phase of its testnet, and its roadmap to the mainnet. besides,Loopring、ZksyncIt is also advancing the testnet process,DeversifiIt has also landed on the test network. In the field of ZK rollup,OMG networkand based on Starkware technologyLaunched the beta version of its main network, and plasma has also made progress. At the same time, gas fees on the eth1 chain have reached new highs, so that，otherNon-financial dapps are forced to stop functioning
other
Apps can also only run on the testnet.
One of the development goals of Eth2 is to increase scalability. We are very close to the early stage of eth2, but to provide base layer scalability for applications, we still need to wait until the last major stage of eth2 in a few years (Translator's Note: Phase 2 ) implementation. Ironically, the availability of eth2 as a data availability layer for rollups will be available in Phase 1, long before eth2 can be truly used for "traditional" L1 applications. Combining these facts, we can draw a conclusion: to deal with the scalability needs in the near and mid-term, the entire Ethereum ecosystem needs to focus on rollups (as well as plasma and channel technology).
If this is the premise, we can learn about the priorities that should be given to the development of Ethereum Central and the development of the ecosystem, which is somewhat different from the current development path. So which issues should we prioritize?
Short-term: Advancing Eth1 infrastructure to support Rollups
EIP 2929In the short term, one of the main results of this is that the expansion work for the Ethereum base layer will mainly focus on expanding the data capacity of blocks, rather than optimizing the efficiency of on-chain calculations or IO operations. The decisive factor for the scalability of Rollups is how much data the chain can contain. If it can be improved on the basis of the current 60 kB/s, the scalability of Rollups can be further optimized.
EIP 1559At the base level, the following factors require continued attention:
: Guarantee that the Ethereum blockchain can resist DoS attacks under the current gas situation
: One is to promote the destruction of ETH, the other is to optimize transaction efficiency, and almost ensure that the transaction is packaged into the next block (rollups still need to wait for confirmation)
New elliptic curve precompilation for full support for programming ZK rollups
Related work on stateless clients, including converting from hex trees to binary trees, etc. (stateless clients make perfect sense no matter how we use the Ethereum blockchain)Account abstraction is less urgent because we can implement it on L2 whether it is supported by L1 or not. There are other "nice base layer features" that are relatively unimportant at the moment.Eth1 clients can be redefined as optimistic rollup clients. Optimistic rollups still require full nodes, and if the internal state transition rules of the rollups are still essentially Ethereum-style with some modifications (such as Optimism's goals), then we can use existing code to run full nodes. at present
eth1+eth2 merge work
Separation of the consensus engine from the state transition engine has already been achieved, and this work contributes to that goal. Note that this also means that projects like TurboGeth are still very important, and high-throughput rollup clients (rather than eth1 clients) will be the biggest beneficiaries.
ENS needs to support names being registered and transferred on L2; see here 54for one possible proposal of how to do this.
Currently, user accounts, ENS domain names, and applications are all on L1, and these need to be changed. We want to put the user's main account, balance, assets, etc. in L2. Then came the following requirements:hereENS needs to provide support for domain names registered and transferred on L2,
here
is a possible related proposal.
Layer 2 protocols should be integrated into wallets, not web-based dapps. At present, dapps or similar dapps integrated with L2 (such as Gitcoin integrated with zksync) require users to fully trust the dapp, which leads to greatly reduced security. To maintain the current trust model, it would be ideal for L2 to be part of the wallet itself (metamask, status, etc.). Such support should be standardized, so that applications that support zksync payments can immediately be compatible with wallets that have zksync built in.
Intensify efforts on cross-L2 transfers, with the goal of enabling instant and seamless asset transfers across L2 chains.
More explicit standardization of Yul or other intermediate compiled languages. The base layer EVM of Ethereum and the OVM used by Optimism rollup are slightly different as compilation targets, but both can be compiled by Solidity. In order for the ecosystem to exist with different compilation targets, but at the same time accept different languages, avoiding a monolithic use of Solidity, it might make sense to more explicitly standardize on an intermediate language (eg Yul) that all high-level languages can compile to of. We can also consider formal-verification-friendly intermediate languages, able to handle concepts such as variables, but also guarantee fundamental invariants, thus making formal verification easier for all compiled high-level languages.
Economic Sustainability Centered on RollupMEVThere is no getting around the fact that cryptocurrency projects must be economically sustainable, and in 2020 this means millions or even tens of millions in financing. Some of this can be provided by public goods funding platforms (such as Gitcoin Grants or the Ethereum Foundation), but these mechanisms are not large enough to cover this level of funding. But Layer 2 projects can solve this problem by issuing their own tokens, provided that their tokens have real economic value, that is, the value captured by L2 in the future.
If the roadmap is rollup-centric, another benefit that comes with it is that it leaves open space for L2 protocols that have the ability to pass fees or
form to obtain development funding, either directly or indirectly (i.e. token issuance). The base layer of Ethereum needs to be neutral, which makes it very difficult to conduct public good funding within the agreement, but L2 has its own public good funding mechanism, so that the controversy will be greatly reduced. So making space in this regard could be a good strategic move for the long-term economic sustainability of Ethereum as a whole.
Aside from fundraising issues, creative developers often prefer to have influence in their own field, rather than frivolously debate ethereum's overall protocol. Also, there are many existing projects that are trying to create various platforms. A rollup-centric roadmap gives all of these projects the opportunity to become part of the Ethereum ecosystem while still retaining a high degree of economic and technical autonomy.
long term horizon
In addition to the short-term considerations mentioned above, the rollup-centric roadmap may mean that we need to reimagine the long-term future of eth2: strong security single-execution shards that everyone can process, and scalable data availability layer.
To understand why this is the case, consider the following factors:
The current TPS of Ethereum is about 15
If everyone migrates to rollups, TPS can reach 3000 soon
Once phase 1 arrives, the data storage of rollups is migrated to the eth2 shard chain, and theoretically the highest TPS can reach about 100,000phase 1.5 and doneFinally, after the implementation of phase 2, local computing is provided for the eth2 shard chain, and the TPS reaches... 1000-5000
This means eth2's "
"Road, streamlining the base layer and focusing on work, namely consensus and data availability.In fact, this is a better development direction for eth2, because shard data availability is much safer than shard EVM calculations. While dishonest-majority-proof verification of sharded EVM computations requires fraud proofs, which requires a potentially risky and strict 2-epoch synchronization assumption, in the asynchronous case data availability sampling (if using ZKP or polynomial Promise) is safe.。
This will help Ethereum have a stronger security model than other sharded L2 chains that are all moving towards some form of sharded enforcement;
eth2 will be a powerful base layer, powerful enough to provide functionality escape velocity is enough
What are the priorities of eth2 in the long run?
Stagger the block generation time of different shards to ensure that a shard proposes a block every few hundred milliseconds. This allows rollups running on multiple shards to have extremely low latency without the risk of ultra-low latency on the chain itself
Optimize and consolidate the consensus algorithm
Changes to the EVM to make it more friendly to fraud proof verification (for example, this could mean some kind of "framework" feature that prevents code from being sandboxed, or allows SLOAD/SSTORE to be remapped so that it can use non-account storage other than data sources)
ZK-SNARK everything
If you are not convinced to accept the development direction of "phase 1.5 and done", there is a natural compromise: use a small number of shards as the execution layer (for example, 4-8), and the other shards as the data layer. The goal is to keep the number of shards performed low enough that in special cases a regular computer will be able to fully validate all shards, but still be significantly larger than the current base layer.
References:
The base layer space cannot be minimized too much, because users and applications still have needs, such as: switching between rollups, submitting fraud proofs, submitting zero-knowledge proofs in ZK rollups, issuing ERC20 token root contracts (ensure most Users will be active in rollups, but the underlying contract must have a place to sit). If the cost per transaction is $140, it greatly ruins the user experience. Therefore, using 4-8 execution shards can reduce the load significantly if necessary. A computer device can still verify all shards. Today, it takes about 200-500 milliseconds to verify an eth1 block produced every 13 seconds, so it is perfectly feasible to verify eight threads of this execution in a short period of time. We can imagine clients adopting these rules: if network latency is low, or committee size > 80%, then rely on fraud proofs and committees, while directly validating all shards in special cases.References:：
Vitalik Buterin on ETHOnline
Recommended reading in the past:
"How to Evaluate Six Ethereum Layer-2 Expansion Solutions"
Disclaimer: ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author. Reprints must indicate the source of the original text and ethereum.cn. For long-term reprints, please contact ethereumcn@gmail.com Authorize.
"Comparing zk-Rollup and Validium"
For more Ethereum information, please pay attention to:
Website: ethereum.cn
