The Ethereum ecosystem needs to focus its efforts on Rollup to meet short- and medium-term expansion needs.
Original title: “Vitalik: Rollup-centered Ethereum Roadmap”
Written by: Vitalik Buterin
Source: ETH Chinese Network
The Optimism team recently released the first phase of its testnet and its roadmap to the mainnet. In addition, Fuel is also advancing the testnet process, and Arbitrum has also landed on the testnet. In the ZK Rollup field, Loopring, Zksync, and Deversifi based on Starkware technology have officially launched on the mainnet, and a certain number of users have gathered. As OMG network launched its mainnet bata version, plasma has also made progress.
At the same time, the gas fee on the Eth1 chain has reached a new high, so that non-financial DApps have been forced to stop running, and other applications can only be run on the testnet.
One of the development goals of Eth2 is to enhance 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 a few years later (Translator’s Note: Phase 2 ) Implementation. The irony is that the availability of Eth2 as the data availability layer of Rollups can be achieved in Phase 1, and Eth2 can be used for “traditional” L1 applications a long time later.
Combining these facts, we can come to a conclusion: in order to meet the short-term and medium-term expansion needs, the entire Ethereum ecosystem needs to focus on Rollups (as well as plasma and channel technologies).
If this is the premise, we can know the issues that should be prioritized in the development of the Ethereum center and the ecosystem, which are more or less different from the current development path. So what issues should we prioritize?
Short-term: Promote Eth1 infrastructure to support Rollups
In the short term, one of the main results of this is that the expansion of the Ethereum base layer will mainly focus on expanding the data capacity of the block, rather than optimizing the efficiency of on-chain calculations or IO operations. The decisive factor for the scalability of Rollup is how much data the chain can contain. If it can be improved from the current 60 kB/sec, the scalability of Rollups can be further optimized.
At the basic level, the following factors need to be continuously emphasized:
- EIP 2929: Ensure that the Ethereum blockchain can resist DoS attacks under the current gas situation
- EIP 1559: One is to promote the destruction of ETH, and the other is to optimize transaction efficiency and almost ensure that the transaction is packaged in the next block (Rollups still needs to wait for confirmation)
- New elliptic curve pre-compilation to achieve full support for ZK Rollups programming
- Stateless client related work, including conversion from hexadecimal tree to binary tree, etc. (no matter how we use the Ethereum blockchain, the stateless client is very meaningful)
Account abstraction is not too urgent, because we can implement it on L2 regardless of whether L1 supports it or not. There are other “smart basic layer functions” that are relatively unimportant at present.
Eth1 client can be redefined as Optimistic Rollup client. Optimistic Rollups still requires a full node, and if the internal state transition rules of Rollup are still Ethereum-style in nature, with some modifications (such as the goal of Optimism), then we can use the existing code to run the full node.
At present, the eth1+eth2 merger has achieved the separation of the consensus engine from the state transition engine, and this work also helps to achieve this goal. Please note that this also means that projects like TurboGeth are still very important, and the high-throughput Rollup client (not the Eth1 client) will be the biggest beneficiary.
Short term: adjust infrastructure to support Rollups
Currently, user accounts, ENS domain names, and applications are all on L1, and these need to be changed. We need to put the user’s main account, balance, assets, etc. in L2. The following requirements follow:
- ENS needs to provide support for domain names registered and transferred on L2. Here is a possible related proposal.
- The Layer 2 protocol should be integrated into the wallet, not the web version of the dapp. Currently, L2 integrated dapps or similar dapps (such as Gitcoin integrated with zksync) require users to fully trust the dapp, which leads to a great compromise in security.
To maintain the current trust model, L2 becomes a part of the wallet itself (metamask, status, etc.) is the ideal situation. This type of support should be standardized, so applications that support zksync payments can also be immediately compatible with wallets with built-in zksync.
- Intensify the work of cross-L2 transfer, and the goal is to be able to transfer assets across the L2 chain instantly and seamlessly.
- More explicit standardization of Yul or other intermediate compiled languages. The EVM of Ethereum’s base layer and the OVM used by Optimism Rollup as the compilation target are slightly different, but both can be compiled by Solidity. In order for the ecosystem to have different compilation goals, but at the same time, it must accept different languages and avoid the single use of Solidity. Therefore, it may make sense to standardize the intermediate languages that can be compiled by all high-level languages (such as Yul) more clearly of.
We can also consider an intermediate language that is friendly to formal verification, capable of handling concepts such as variables, and ensuring basic invariants, so that all compiled high-level languages can be more easily formalized.
Economic sustainability centered on Rollup
Cryptocurrency projects must be economically sustainable. This is an unavoidable fact. In 2020, this means millions or even tens of millions of financing. Some of these can be provided by public goods fundraising platforms (such as Gitcoin Grants or the Ethereum Foundation), but the scale of these mechanisms is not sufficient to cover this level of financing.
But the Layer 2 project can solve this problem by issuing its own token, provided that its token has real economic value, that is, the value captured by L2 in the future.
If the roadmap is centered on Rollup, another benefit that follows is to leave open space for L2 agreements. These L2 agreements have the ability to obtain development funds through fees or MEV, whether directly or indirectly ( Issuance of tokens).
The Ethereum base layer needs to be neutral, which makes it very difficult to fund public goods within the agreement (public good funding), but L2 has its own public goods fundraising mechanism, so that disputes will be greatly reduced. Therefore, leaving room in this area may be a good strategic move for the long-term economic sustainability of the entire Ethereum.
In addition to fundraising issues, creative developers generally tend to have influence in their own fields, rather than making insignificant arguments about the overall agreement of Ethereum. In addition, there are many existing projects that are trying to create various platforms. The Rollup-centric roadmap gives all these projects the opportunity to become part of the Ethereum ecosystem while still retaining a high degree of economic and technological autonomy.
Long-term vision
In addition to the short-term considerations mentioned above, the rollup-centric roadmap may also mean that we have to reimagine the long-term future of eth2: strong security single execution sharding that everyone can process, and scalable data availability Floor.
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, Rollups’ data storage is migrated to the eth2 shard chain, theoretically TPS can reach up to about 100,000
- Finally, after phase 2 is implemented, local calculations are provided for the eth2 shard chain, and the TPS reaches…1000-5000
In my opinion, when Phase 2 finally comes, basically no one will care. Whether we want it or not, everyone has adapted to the world centered on Rollup. By then, instead of recalling everyone to the basic chain that has no strengths and has 20-100 times lower scalability, continue to follow this path. It will be easier to go down.
This means that the “phase 1.5 and done” path of eth2 is to streamline the basic layer and focus on work, that is, consensus and data availability.
In fact, this is a better development direction for eth2, because the availability of fragmented data is much safer than fragmented EVM computing. Although the dishonest-majority-proof verification of the sharding EVM calculation requires fraud proof, which requires potentially risky and strict 2-epoch synchronization assumptions, 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, and these sharded L2 chains are all moving towards some form of sharding execution; eth2 will be a powerful base layer, It is enough to be powerful enough to provide functionality escape velocity.
In the long run, what are the priorities of eth2’s work?
- Stagger the block generation times of different shards to ensure that a certain shard block is proposed every few hundred milliseconds. This makes Rollups running on multiple shards have extremely low latency, and the chain itself does not have the risk of ultra-low latency
- Optimize and consolidate the consensus algorithm
- Make changes to the EVM to make it more friendly to fraud proof verification (for example, this may mean some kind of “framework” function that prevents the code from leaving the sandbox, or allows SLOAD / SSTORE to be remapped so that it can use other than account storage Other data sources)
- ZK-SNARK for everything
Compromise
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 other shards as the data layer. The goal is to make the number of execution shards low enough that under special circumstances, a regular computer will be able to fully verify all shards, but compared with the current base layer, its space is still much larger.
The base layer space cannot be minimized too much, because users and applications still have requirements, such as: switching between Rollups, submitting fraud proofs, submitting zero-knowledge proofs in ZK Rollups, issuing ERC20 token root contracts (to ensure that most Users will be active in Rollups, but the basic contract must have a place). If the cost of each transaction is $140, it will greatly destroy the user experience. Therefore, if necessary, using 4-8 execution shards can significantly reduce the burden. One computer device can still verify all slices.
Nowadays, it takes about 200-500 milliseconds to verify the eth1 block generated every 13 seconds, so it is completely feasible to verify the eight threads of such execution in a short time. We can imagine that the client adopts these rules: if the network latency is very low, or the number of committees is> 80%, it can rely on fraud proofs and committees, and in special cases directly verify all shards.
Reference materials:
Related speeches by Vitalik Buterin on ETHOnline:
https://www.youtube.com/watch?v=r0jtV9mxdI0&list=PLXzKMXK2aHh4sF0ZlCE49Frl4VJq3ME_V&index=12
Source link: mp.weixin.qq.com
