Vitalik Buterin said that after the beacon chain is online, the three processes of light client support, data fragmentation, and the merger of eth1 and eth2 will be advanced in parallel.
Original Title: “The Fifth Reddit AMA of the Ethereum Foundation”
Compile: ETH Chinese Station
At 9 pm on November 18th, Beijing time, the Ethereum Foundation research team conducted the fifth AMA on the reddit forum. The topics included the creation of Ethereum 2.0 and the roadmap. ECN sorted out the questions and answers and compiled them into documents. It should be noted that the core developers have their own opinions and speculations on certain topics. To avoid misinterpretation, please refer to the attached original post link.
route map
Q: After Phase 0 goes live, which parts of the existing specifications will undergo major changes?
Vitalik Buterin: In the past few months, many things about the roadmap have evolved. I think it is necessary to summarize these changes here (this will affect the specification of the next two years):
A road map centered on Rollup. Reduce “Phase 1” to data sharding (for use by Rollups) to make it easier to implement.
Simplify the merging of eth1 and eth2. Roughly based on this roadmap, but now 1) eth1 transactions can be performed directly on the beacon chain instead of sharding; 2) Thanks to optimistic execution, the execution interruption time during the merge may be greatly shortened. This has simplified the merger process, and the PoC phase has already begun.
The stages are carried out in parallel. This is the latest plan, and perhaps (its importance) is also the most underestimated. It can be divided into 1) light client support; 2) data fragmentation (also known as “phase 1”); 3) the merging of eth1 and eth2. These three processes will advance independently, so that each part can be implemented independently, and There is no need to consider the development progress of other parts.
The original intention of all these changes is to speed up the process of making eth2 truly usable. The support of light clients may be implemented before sharding, so that the beacon chain can be quickly available (providing consensus for eth1). The simplified merging process means that the merging of eth1 and eth2 will be faster than previously preset. All stages are carried out in parallel, which can further accelerate the merge, and it may even be possible to merge before the sharding is realized.
As part of Rollup’s central strategy, “phase 2” (phase 2, that is, fragmented execution) is currently not so important. Mainly because the ultimate goal of Phase 2 (that is, achieving high TPS) can be achieved on the basis of data sharding (Phase 1) + Rollups, and the effect is even better. Sharding + Rollups will be implemented before Phase 2, so it is better to focus on this part at present. In other words, we will not take any irreversible actions, making it impossible to add local sharding execution functions in the future. If needed in the future, this roadmap can be compatible with fragmented execution at any time.
Too long to read: the sooner the merger of eth1 and eth2 comes, the faster the PoS is realized, and everyone will be able to see the 100,000 TPS Ethereum sooner.
Justin Drake: In the long run, most of the logic of the beacon chain may undergo major changes:
- Light client support
- Secret proposer election
- Use VDF to provide unbiasable randomness
- Vote for eth1 improvements to the merge process
- Sampling of beacon block data availability
- Upgrade BLS aggregation signature to post-quantum alternative
- Casper FFG is upgraded to Casper CBC
- Replace SHA256 with an arithmetic-friendly hash function (if SHA256 is found to be insecure, use a more secure function)
- Adjustment of status
Q: According to the current parallel routes of light client, merge and sharding, what is the order of implementation possible? (Which part is faster / easier to implement)
Vitalik Buterin: Light client support is easy to achieve in 2021, and if we work hard, early 2021 is not impossible. Merging and sharding I expect that we should see a mature test version at the end of 2021, and it is not yet certain whether we can merge and shard on the mainnet in 2021.
Justin Drake: Possible delivery sequence:
- PoS—”phase 0″
- Light client-“phase 0.5”
- Data fragmentation-“phase 1”
- eth1 and eth2 merged-“phase 1.5”
- Built-in VM—”phase 2″
Phase 0.5 is likely to be achieved in 2021, and ideally Phase 1 may also be achieved in 2021.
Q: How long does it take to run the shortest phase 0? Are the stages after stage 0 implemented according to a fixed time interval or go online as soon as they are ready?
Danny Ryan: Phase 1 (sharding) will be launched once it is ready, including construction, testing, testnet, etc.
As for the merger phase (phase 1.5), I hope to wait until the beacon chain runs smoothly in the production environment for at least 9 months. We really need a period of time to observe the performance of the beacon chain in the product environment to determine whether it is stable and safe enough to become the new home of Ethereum.
Vitalik Buterin: “The shortest running time before fragmentation” is not the same as the “shortest running time before merging”. After the shard is stable, it can go online.
As for the merger, I can only say that it depends on the community and not me. This is a very difficult decision. The vast Ethereum community, including eth1 core developers, block explorers, exchanges, etc., need to have sufficient proof of the security of PoS in order to fully migrate.
Regarding the merger, I think it is unrealistic within a year. Even if it can be fully realized in February next year, I suggest that we take care of it and observe November or later to convince everyone of the security of PoS, so that everyone can safely carry this $50 billion land The ecosystem is truly migrating to the beacon chain.
Q: According to the proposal of the TXRX team on the executable beacon chain at the 52nd Implementers Meeting, will EF change the architecture of Ethereum 2.0?
Danny Ryan: If we continue to use a single execution chain (eth1), then integrating it locally into the beacon chain is the safest choice, and being able to access sharded data locally will also reduce the complexity of consensus. This is a very elegant design, and related prototype work is currently in progress (may soon usher in the beacon chain merger test network!)
At present, I personally agree with this design, but it will take a few months to see the actual effect.
Dankrad Feist added: To add, this is the only possible design before we achieve stateless Eth1.
Q: In the current development path, are there areas where the team has not yet clarified its implementation and feasibility?
Justin Drake: In terms of data sharding and the merger of eth1 and eth2, the research work has been completed, and the risk is relatively low. Currently, it is mainly engineering and coordination issues.
I think we finally need a built-in virtual machine (also known as phase 2) to replace the existing EVM. If the built-in virtual machine is zkVM (SNARK friendly EVM alternative), it is very good. There are still important open issues in the intersection of research and engineering of Eth2 zkVM.
Dankrad Feist: From a research point of view, I think we have specific plans for phases 0, 1, and 2 without insurmountable challenges. However, in phase 1 and phase 2, we still have implementation issues to be solved, namely data availability (phase 1), stateless execution, and whether a new virtual machine like eWASM will be used (phase 2).
From a long-term perspective, we also face quantum security challenges. But further research and exploration are needed.
R & D status
Q: Among the different Ethereum 2.0 components, including light client, sharding, merging, eWASM, execution environment, Rollups, etc., which areas are actively researched and developed? How far is it from realization?
Justin Drake:
Light client: The research and specification work is basically completed, and it is relatively easy to implement.
Data fragmentation: The research work is basically completed, and the specification is being written. There are still engineering challenges in data availability sampling, but we have a simpler solution that only has committee data shards.
Merger of eth1 and eth2: I expect this part of coordination will be very difficult, especially in the rigid eth1.
eWASM: Phase 2 (ie, the built-in Eth2 VM) is not a priority in the mid-term strategy centered on Rollup. From a longer-term perspective, I think we will have a built-in virtual machine, and WASM, which is becoming a blockchain standard, is one of the candidates.
Execution environment: The Rollup virtual machine is a good enough alternative to the execution environment in the medium term (or even long term).
Rollups: Rollups is not part of the eth2 consensus, but an urgent need for the second layer of infrastructure, so it does not belong to the EF Eth2 team.
Creation & Pledge
Q: What if 16,384 verifiers are not pledged on November 24? Can the parameter of the minimum number of validators be changed to ensure that eth2 can be created on December 1st?
Danny Ryan: There are some discussions on this issue in this issue:
https://github.com/ethereum/eth2.0-specs/issues/2134
I personally think that for the first launch, more than 100,000 ETH in the contract is sufficient, and it is reasonable to lower this threshold to avoid the ETH in the contract being locked for too long. For early participants, the reward will be very high and may also attract later validators.
However, it would seem a bit radical to modify this parameter on November 24 or December 1. We don’t know what will happen in the next few weeks, so it’s best to keep watch.
In the discussion linked above, the client team seems to prefer to stay on hold in December, and modify the parameters in early January if necessary. This seems desirable.
virtual machine
Q: What is the current status of eWASM? Does eWASM or WebAssembly make sense in the Rollup-centric roadmap?
Vitlaik Buterin: I will give a difficult but honest answer: from the short to medium term, eWASM is no longer emphasized in the current roadmap.
The main reasons are:
- Changing from one virtual machine to two also doubles the complexity of consensus.
- There are already many things in our plan, and compared to the PoS+sharding roadmap, the benefits of switching virtual machines are quite low.
- Many of the benefits originally envisaged by eWASM (ie, execution at near-native speed, eliminating the need for precompilation) have not yet been realized. In particular, it turns out to be a fast and safe compiler at runtime.
- It turns out that many things can be efficiently implemented in the existing EVM, but it requires certain skills (such as weierstrudel)
Currently, EVM 384 can help us eliminate a lot of pre-compilation requirements.
Therefore, in the short term, the possibility of eWASM is to serve as the built-in execution engine of Rollups (because you can use any state transition function in Rollups, you only need to write a fraud proof for it).
In the long run, I think it is necessary and there are good reasons to upgrade the EVM. For example, in the long run, we need the ZK-SNARK virtual machine to execute. WASM is more efficient than EVM and is specifically designed for SNARK-friendly WASM Sub-assembly will be more efficient.
EIP-1559
Q: I feel that EIP-1559 is part of the ETH 2.0 specification and will it be implemented in phase 1?
A lot of work has been done to implement EIP-1559 in ETH 1.0. Is there any overlap between ETH 1.0 and ETH 2.0? Is it possible to clarify these two parts of work? Will they affect each other?
Danny Ryan: EIP-1559 belongs to the cost market part of fragmented data in the ETH 2.0 specification. According to the plan, the transaction execution of ETH 1.0 will use similar cost destruction and gas price mechanisms to price shard data. It would be great if 1559 could go online on the mainnet. After the merger of ETH 1.0 and ETH 2.0, 1559-style transactions will be available in the execution of eth1, and the 1559-style fee market for sharded data will be built in the data shard of eth2.
In theory, there is a lot of overlap between ETH 1.0 and ETH 2.0. Therefore, most of the research and development efforts made for 1559 on the eth1 mainnet today are applicable to the design and understanding of the use of this tool in the eth2 data market.
Justin Drake: Yes, the cost and price mechanism that is logically similar to EIP-1559 (ie, cost destruction) will become part of Phase 1.
The implementation of EIP-1559 on Eth1 may provide the community with a clearer picture of these mechanisms and reduce the risk of cost destruction in Eth2. I hope that a lot of coordination work can be done in Eth1 (such as promoting education and integration with wallet).
The cost destruction mechanism of ETH 1.0 and ETH 2.0 will be slightly different and will coexist for a period of time. Our vision is that after the merger of ETH 1.0 and ETH 2.0, the cost destruction mechanism of ETH 2.0 will replace EIP-1559.
Execution environment & Rollups
Q: Can all the Execution Environments (EE) envisaged for Phase 2 be implemented on Rollup? In terms of innovation, what are the disadvantages of the Rollup-centric roadmap?
Vitalik Buterin: Yes, all EE will become Rollup. I would say that the Rollup-centric roadmap is more conducive to innovation because it is more “permission-free” (anyone can create a Rollup with any rules), so it allows various teams to participate, including those that are related to the current core The development process is not similar.
The main disadvantage of this method is that we risk losing the developer’s network effect, because many different Rollup internal execution rules are fundamentally different. In other words, I expect that if this roadmap is to be implemented, there will soon be a set of dominant standards, while other standards can only cater to the needs of some niche communities.
Dankrad Feist: Rollup essentially points to a question-who will ensure correct execution. Without Rollup, the verifier on Layer1 and Eth2 that provide security is still the same entity. In Rollup, the entity becomes a zero-knowledge proof (zkRollup is currently not applicable to general execution) or fraud proof (optimistic Rollups) generated for correct execution.
Any function of the execution environment can be implemented through Rollup. zkRollup provides the same security as on-chain execution, but they require a lot of resources when generating proofs, and proofs are censorship-resistant. Optimistic Rollup is mainly a compromise on finality: as a user, unless you execute all related transactions before the current transaction, you cannot know whether the transaction has been finalized.
no status
Q: A question about PoS: Is stateless ETH 1.0 still a necessary prerequisite?
The current recommended validator configuration is at least 16gb of memory + at least 1tb of solid state drive, for two reasons: one is to prevent
When the block cannot be finalized for a long time, resource usage will increase significantly. Second, because people running geth nodes are very inclined to vote for the block header of ETH1.0.
Justin Drake: These two reasons are temporary and I expect to be resolved in 2021:
The surge in resources required when the block cannot be finalized: It is a good way for the client to find a way to solve the problem that cannot be finalized. (Now the final certainty will theoretically be used as a fulcrum). We now have some plans (cc /u/protolambda), we will build a long-running test network, which is set to the network can not finalize the block, so as to force the client to optimize.
Vote for Eth1: It is enough to build a data layer on the general Eth1 block header synchronization light client to solve this problem. This data layer is equivalent to a gossip network, which is used to broadcast the certificate of deposit (that is, the Eth1 block header in the Deposit and corresponding Merkel certificate).
Q: If almost every validator node runs geth or at least has the ability to run geth, why not let every beacon block contain a new eth1 block so that the beacon block generator can replace miners more quickly ?
Justin Drake: I am very disgusted with the idea of requiring block proposers to run an Eth1 full node. This is completely contrary to the design goal of allowing Eth2 verifiers to run nodes on the Raspberry Pi.
Q: I don’t think this goal is reasonable, because now 32 ETH is the minimum pledge amount, which is a huge amount, and after the PoS is fully implemented, it is almost certain that the price of ETH will rise. In reality, people who hold 32 ETH In fact, it is intended to be pledged in the pledge pool (decentralization is of course the best), and talents who have the ability to run multiple nodes will do it themselves.
How many validators will actually use nodes to risk, just to save $200 or basic nuc space? Personally, I would not stake my ETH on the mainnet with a Raspberry Pi.
Justin Drake: The minimum deposit of 32 ETH has nothing to do with this, for two reasons:
1. If you hold much less than 32 ETH, you can pledge it in an m-of-n pool
2. We should focus on rewards, not on the amount of pledge. In fact, we want to increase the rate of return as much as possible to ensure that the verifier is profitable. If you are required to run an Eth1 node, they will definitely backtrack the income, and the income may even be negative, if you participate in the m-of-n pool (refer to point 1).
Additional issuance
Q: What is the maximum supply of ETH?
Vitalik Buterin: I think now is a good opportunity to make some unpopular but important points here. In fact, in the next two years, the Ethereum ecosystem will be in a state of rapid transformation. For example, hexary trie will be replaced by binary trie, PoW will be eliminated and replaced by PoS, we will add a new technology “data availability sampling” that has never been used. In addition, the economic model of Ethereum is undergoing a thorough reform from three aspects: (i) PoW -> PoS, (ii) the introduction of EIP 1559, (iii) the transfer of user activities from L1 to L2
The Ethereum ecosystem has a long-term and firm goal: to become a stable and reliable system. But everyone supports and supports Ethereum, not because we firmly believe that the existing rules (economic or technical) are worth our maintenance at all costs, but because we believe in what direction the Ethereum ecosystem will develop in the future. . In the next two years, the main task is to stabilize and cherish what we will build. Until then, the participation rate of Ethereum has confirmed our prediction: this roadmap is worthy of our support. Once the upgrade is completed, our network will eventually become more efficient, stable, and powerful, and become the foundation of an important part of the global economy.
In the next 1-2 years or until the merger of Eth1->Eth2, the issuance plan is about 4.7 million per year; after the PoS mechanism is fully operational, the annual issuance of the destroyed ETH (the burned amount even exceeds the issuance) is subtracted About 0-200 million. I don’t think it makes much sense to give any other different answers. In other words, I do hope that the fact that the phase 0 code has been completed (basically only waiting for people to deposit ETH into the deposit contract) can largely resolve the risks in the transfer process, unlike the previous six months. The former risk is so big!
Q: What will the total issuance of ETH be?
Justin Drake: When Eth1 and Eth2 merge, the PoW chain will stop issuing additional ETH. The additional issuance of ETH on the PoS chain will actually be limited to about 1 million per year. I hope that EIP-1559’s handling fee destruction setting will alleviate the inflationary pressure caused by the additional issuance of PoS.
Testnet
Q: Are there any plans to launch another testnet? And according to the current Eth2 mainnet specifications, there are the same number of validators, so that the community can understand the profitability of joining Genesis in real time?
Justin Drake: The Pyrmont testnet was released yesterday 🙂
For more information about Pyrmont, please read “Eth2 Update Quick Overview #20”
https://pyrmont.launchpad.ethereum.org
Q: I know, I participate in the testnet. But the Pyrmont testnet can accommodate 100,000 verifiers. Will there be plans to launch a public testnet of 16,000 verifiers?
Justin Drake: I’m not sure about this, but the pledge reward can be calculated with tools like this.
Branch line
Q: Can we use Rollups to achieve transparent sharding? (In other words, developers and end users don’t even feel it exists)
Vitalik Buterin: Of course! One of the benefits of the Rollup-centric roadmap is that it gives Rollup more experimental space that supports synchronous communication across shards. No sharding is even needed, only a single mega-sequencer handles everything in a single thread. That is to say, you can have synchronous domains on Rollup that can process hundreds or even thousands of transactions per second (equivalent to the function of killer Ethereum), without causing the entire basic layer chain to use such synchronous domains. Centralization risk of mode operation.
Source link: mp.weixin.qq.com
