The Ethereum Foundation AMA discusses these focal points: ETH 2.0, Rollup, EIP-1559…
Original title: "Ethereum Foundation Fifth Reddit AMA"
Original compilation: ETH Chinese Station
Beijing time 11 At 9:00 p.m. on the 18th, the research team of the Ethereum Foundation conducted the fifth AMA on the reddit forum. The topics included the creation and roadmap of Ethereum 2.0. ECN screened and sorted out the questions and answers and compiled them into a document. It should be noted that the core developers have their own views and speculations on some topics. To avoid misinterpretation, please refer to the attached original post link.
Roadmap
Q: After phase 0 goes live, which part of the existing specification will happen Big change?
Vitalik Buterin: Over the past few months, there have been many things about the roadmap In evolution, I think it is very necessary to summarize these changes here (this will affect the specification writing in the next two years):
Roadmap centered on Rollup. Simplifies Phase 1 into data shards (for use by Rollups), making it easier to implement.
Simplifies merging of eth1 and eth2. It is roughly based on this roadmap, but now 1) eth1 transactions can be carried out 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 simplifies the incorporation process, which is currently in the PoC phase.
The stages run in parallel. This is the newest initiative, and perhaps (its importance) the most underrated. It can be divided into 1) light client support; 2) data fragmentation (that is, "phase 1"); 3) the merger of eth1 and eth2, these three processes will be advanced 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 actually using eth2. Light client support may be implemented before sharding, making the beacon chain available quickly (providing consensus for eth1). The simplified merge process means that eth1 and eth2 will merge faster than previously expected. Parallel stages can further speed up merging, possibly even before sharding is implemented.
As part of the Rollup Center strategy, Phase 2 ( phase 2, that is, shard execution) is not so important at present. The main reason is that the ultimate goal of phase 2 (that is, to achieve 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 a better choice to focus on this part at present. That said, we will not be taking any irreversible moves that would make it impossible to add local shard execution in the future. This roadmap can be compatible with the shard execution function at any time if there is a need in the future.
Too long to read: The faster the merger of eth1 and eth2 comes, the faster PoS is realized, and the sooner everyone can see 100,000 TPS Ethereum.
Justin Drake : In the long run, most of the logic of the beacon chain may undergo relatively large changes:
Light Client Support
Secret proposer election
Use VDF to provide unbiasable randomness(unbiasable randomness)
Improve eth1 voting for the merge process
letter Block data availability sampling
Upgrade BLS aggregate signature to post-quantum alternative
Casper FFG is upgraded to Casper CBC
Arithmetic-friendly hash function to replace SHA256 (or use a more secure function if SHA256 is found to be insecure)
Adjust state
Q: According to the current parallel route of light client, merging and sharding, the order of implementation How could it be? (Which part is faster/easier to implement)
Vitalik Buterin: Light client support is easy in 2021 Realization, early 2021 is not out of the question if we work hard. Merging and sharding I expect we should see a mature beta version by late 2021, not sure if merging and sharding will be possible on the mainnet in 2021.
Justin Drake : Possible order of delivery:
PoS—"phase 0"
Light client - "phase 0.5"
Data sharding - "phase 1"
Merge eth1 and eth2 - "phase 1.5"
Built-in VM - "phase 2"
Phase 0.5 is likely to be implemented in 2021, ideally phase 1 may also be in 2021 year to achieve.
Q: How long does stage 0 need to run? Will the phases after Phase 0 be implemented based on fixed intervals or go live as soon as they are ready?
Danny Ryan: Phase 1 (sharding) will go live as soon as it is ready, Including building, testing, testnet, etc.
As for the merge phase (phase 1.5), I would like to wait until the beacon chain has been running smoothly in production for at least 9 months. We really need a period of time to observe the performance of the beacon chain in the production environment before we can judge whether it is stable and safe enough to become the new home of Ethereum.
< span style="font-weight: bold;">Vitalik Buterin: "Minimum running time before sharding" and "Minimum running time before merging" are different. Shards can go live after they are stable.
As for the merge, all I can say is that it's up to the community, not me, and it's a very difficult decision. The vast Ethereum community, including eth1 core developers, block browsers, exchanges, etc., all need sufficient confirmation of the security of PoS before they can be completely migrated.
For the merger, I think it is unrealistic within a year. Even if it is fully achievable in February next year, I suggest that we wait until November or later to convince everyone of the security of PoS, so that everyone can safely carry this The $50 billion ecosystem is truly migrating to the beacon chain.
Q: According to the 52nd Implementers Meeting TXRX Team about Proposal for executable beacon chain, will EF change the architecture of Ethereum 2.0?
Danny Ryan: If we continue to use a single execution chain (eth1), then Integrating it natively into the Beacon Chain is the safest option, and being able to access shard data natively also reduces consensus complexity. This is a very elegant design, and related prototype work is currently underway (may soon usher in the beacon chain merge testnet!)
Currently I Personally, I am in favor of this design, but we will have to wait a few months to see the actual effect.
Dankrad Feist Supplement: Let me add that before we implement stateless Eth1, This is the only possible design.
Q: In the current development route, is there still a team Haven't clarified its implementation method and feasibility?
Justin Drake: data fragmentation and merging of eth1 and eth2, research work Completed and relatively low risk, mostly engineering and coordination issues at the moment.
I think we will eventually need a built-in virtual machine (also called phase 2) to replace the existing EVM. It would be nice if the built-in virtual machine was zkVM (a SNARK-friendly alternative to EVM). There are still important open problems at the research and engineering intersection of Eth2 zkVM.
Dankrad Feist: From a research perspective, I think we have specific Phases 0, 1, and 2 of the plan have no insurmountable challenges. But in Phase 1 and Phase 2 we still have execution issues to resolve, namely data availability (Phase 1), stateless execution, and whether new virtual machines like eWASM will be used (Phase 2).
In the long run, we also face quantum security challenges. But further research and exploration are needed.
Research and Development Status
Q: Among different Ethereum 2.0 components, including light client, sharding, merging, eWASM, execution environment and Rollups, etc., which areas are being Active R&D? How far is it from realizing it?
Justin Drake:
Light client:The research and specification work is basically completed, and it is relatively easy to implement.
Data sharding: The research work is basically completed, and the specification is being written. There are still engineering challenges around data availability sampling, but we have a simpler solution, sharding with only committees.
Merging of eth1 and eth2: I expect this part to be difficult to coordinate , especially in rigid eth1.
eWASM: Phase 2 (that is, the built-in Eth2 VM) is centered on Rollup It is not a top priority in China's medium-term strategy. 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:Rollup virtual machine is in the medium term (or even long term) A good enough alternative to the execution environment.
Rollups:Rollups are not part of the eth2 consensus, but the second layer foundation There is an urgent need for facilities and therefore outside the scope of the EF Eth2 team.
Creation & Pledge
Q: What if there are no 16,384 validators staking on November 24th? 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 about this issue in this issue:
https://github .com/ethereum/eth2.0-specs/issues/2134
Personally I think there are more than 100,000 in the contract for the first live It is reasonable to lower this threshold to avoid ETH locked in the contract for too long. The rewards will be very high for early participants and may also attract later validators.
But it would be a bit radical to modify this parameter on November 24th or December 1st. We don't know yet what the next few weeks will look like, so it's best to keep watching.
In the discussion linked above, the client team seems to be leaning toward holding back in December, with parameter changes in early January if necessary. This seems to be desirable.
virtual machine
Q: What is the current status of eWASM? Does eWASM or WebAssembly make sense in a Rollup-centric roadmap?
Vitlaik Buterin: I will give a hard but honest answer: short term By mid-term, eWASM has been de-emphasized in the current roadmap.
The main reason is:
The change from one virtual machine to two has also doubled consensus complexity.
There are already many things in our plan, and compared to the parts in the PoS+sharding roadmap, the benefits of switching virtual machines are quite low.
Many of the originally envisioned benefits of eWASM (i.e. execution at near-native speed, eliminating the need for precompilation) have yet to materialize. In particular, it has proven difficult to create compilers that are fast and safe at runtime.
It turns out that many things can be efficiently implemented in the existing EVM, it just requires certain skills (such as weierstrudel)
Currently, EVM 384 can help us eliminate a lot of precompilation needs.
Therefore, in the short term, the possibility of eWASM exists as Rollups' built-in execution engine (because you can use any state transition function in Rollups, you only need 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 ZK-SNARK virtual machine execution, WASM It is more efficient than EVM, and a subset of WASM specially designed for SNARKs will be more efficient.
EIP-1559
Q: I feel that EIP-1559 is part of the ETH 2.0 specification and will 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 the work of these two parts? Will they affect each other?
Danny Ryan: EIP-1559 belongs to the fee for sharding data in the ETH 2.0 specification market section. According to the plan, the transaction execution of ETH 1.0 will use a similar fee burning and gas price mechanism to price shard data. It would be great if 1559 can be launched on the mainnet. After the merger of ETH 1.0 and ETH 2.0, 1559-style transactions will be available in eth1 execution, and the 1559-style fee market for shard data will be built in eth2 data shards.
Theoretically, there is a lot of overlap between ETH 1.0 and ETH 2.0, so much of the R&D effort being done for 1559 on the eth1 mainnet today applies to The design and understanding of the use of this tool in the eth2 data marketplace.
Justin Drake : Yes, a logical approximation to EIP-1559's fee and price mechanism (i.e. fee burn) will be part of Phase 1.
The implementation of EIP-1559 on Eth1 may provide the community with a clearer picture of these mechanisms and reduce risk for fee burning in Eth2. I expect a lot of coordination work to be done on Eth1 (such as promoting education and integration with wallets).
The fee burning 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 fee burn mechanism of ETH 2.0 will replace EIP-1559.
Execution Environment & Rollups
Q: Can all Execution Environments (EE) envisioned for Phase 2 be implemented on Rollup? From an innovation standpoint, what are the downsides of a Rollup-centric roadmap?
Vitalik Buterin:Yes, all EE will be Rollup. I'd say that a Rollup-centric roadmap is better for innovation because it's more "permission-free" (anyone can create a Rollup with any rules), so it makes it possible for various teams to participate, including those with the current core The development process is not similar.
The main downside of this approach is that we risk losing developer network effects, since many different Rollups now have fundamentally different internal enforcement rules. That said, I expect that if this roadmap is to follow through, there will soon be a dominant set of standards, with others catering only to niche communities.
Dankrad Feist :Rollup essentially points to a question - who will ensure correct execution. In the absence of Rollup, the validators providing security on Layer1 and Eth2 are still the same entity. In Rollup, entities become zero-knowledge proofs generated for correct execution (zkRollup cannot yet be applied in general execution) or fraud proofs (optimistic Rollups).
Any function of the execution environment can be implemented by Rollup. zkRollups provide the same security as on-chain execution, but they require significant resources to generate proofs, which are censorship-resistant. Optimistic Rollup is mainly a compromise in finality: as a user, unless you execute all related transactions before the current transaction, you cannot know whether this transaction is finalized.
stateless
Q: A question about PoS: is stateless ETH 1.0 still a required prerequisite?
The current recommended validator configuration is at least 16gb of memory + at least 1tb of solid-state hard disk. Resource usage will increase significantly when it is finalized, and the second is because people running geth nodes will be very inclined to vote for ETH1.0 block headers.
Justin Drake: Both reasons are temporary and I expect Solved in 2021:
Surge of resources required when blocks fail to finalize: It's a good idea for clients to figure out how to solve the non-finalize problem. (Now finality would theoretically be used as a pivot). We have some plans right now (cc /u/protolambda) where we will be building a long-running testnet where the network is unable to finalize blocks, thereby forcing optimizations on the client side.
Vote for Eth1: Building a layer of data layer on the general Eth1 block header synchronization light client is enough to solve this problem. This layer of data layer is equivalent to A gossip network to broadcast deposit proofs (i.e. deposits in Eth1 block headers with corresponding Merkle proofs).
Q: If almost every validator node runs geth or at least has the ability to run geth, why doesn't every beacon block contain a new eth1 blocks for beacon block producers to replace miners faster?
Justin Drake: I would like to ask block proposers to run an Eth1 full node this Views are very disgusting. This is completely against the design goal of allowing Eth2 validators to run nodes on 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 full implementation of PoS, it can almost It is certain that the price of ETH will rise. In reality, those who hold 32 ETH actually intend to pledge in the pledge pool (decentralization is of course the best), and those who are capable of running multiple nodes will do it themselves.
How many validators would actually risk it with a node 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 stake of 32 ETH is irrelevant for a reason Two:
1. If you hold far less than 32 ETH, you can pledge it in an m-of-n pool
2. We need to focus on the rewards, not the pledged amount. In practice, we want to maximize the rate of return as much as possible to ensure validators are profitable. Asking to run an Eth1 node, they will definitely eat back the yield, and the yield may even be negative, if you participate in the m-of-n pool (see point 1).
Additional issue
Q: What is the maximum supply of ETH?
Vitalik Buterin: I think now is a good opportunity to make some less popular but important points here. In fact, over 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 phased out and replaced by PoS, and we will add a new technique "Data Availability Sampling" that has never been used before. In addition, Ethereum's economic model is undergoing a thorough reform in three aspects: (i) PoW -> PoS, (ii) the introduction of EIP 1559, ( iii) User activity shifted from L1 to L2
Ethereum ecosystem The system 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 maintaining 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, Ethereum’s participation rate confirmed our prediction: this roadmap is worthy of our support. Once the upgrade is complete, our network will eventually become more efficient, stable, robust, and serve as the foundation for a vital 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, Subtracting the destroyed ETH (destroyed even exceeds the issued amount), the annual issued amount is about 0-2 million. I don't see much point in giving any other different answer. That said, I do hope that the fact that the phase 0 code is already done (basically just waiting for people to deposit ETH into the deposit contract part) can largely de-risk the transfer process, not like it used to even six months So much risk before!
Q: What will be the total circulation of ETH?
Justin Drake: When Eth1 and Eth2 merge, the PoW chain will stop issuing more ETH. The ETH issuance of the PoS chain will actually be limited to about 1 million per year. I hope that EIP-1559’s fee burning setting will more alleviate the inflationary pressure brought about by the additional issuance of PoS.
Testnet
Q: Is there any plan to launch another testnet? And according to the current Eth2 mainnet specification, which has the same number of validators, so that the community can understand the profitability of joining Genesis in real time?
Justin Drake: Pyrmont testnet launched yesterday :)
< p>For more information about Pyrmont, please read "Eth2 Update Snapshot #20"
https://pyrmont.launchpad.ethereum.org
Q: I know, I have participated in the testnet. But the Pyrmont testnet can accommodate 100,000 validators, are there plans to launch a public testnet with 16,000 validators?
Justin Drake:I’m not sure about this, but staking rewards can use tools like this < /a> to calculate.
Branch
Q: Can we use Rollups to achieve transparent sharding? (That is to say, developers and end users don't even feel its existence)
Vitalik Buterin : Of course you can! One of the benefits of a Rollup-centric roadmap is that it gives more room for experimentation with Rollups that support synchronous communication across shards. There's not even a need for sharding, just a single mega-sequencer that single-threads everything. That is to say, you can have synchronous domains (synchronous domains) that process hundreds or even thousands of transactions per second (comparable to the function of Killer Ethereum) on Rollup, without causing the entire base layer chain to use this kind of Concentration risk of operating in the same way.
< a href="https://mp.weixin.qq.com/s?__biz=MzU2NDcyOTc2NA==&mid=2247486502&idx=1&sn=59d05c7752d264c67d79a357d25643f2&chksm=fc47ceedcb3047fbe4092aa 301b0a5ed89c0105e70f0729c3e790cae002485c42dd4b91525f7&scene=0&xtrack=1" target ="_blank">Original link
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
