What will be the total issuance of ETH?
Original title: "Ethereum Foundation Fifth Reddit AMA"
Original source: ETH Chinese website
Translator’s note: At 9:00 pm on November 18th, Beijing time, the research team of the Ethereum Foundation conducted the fifth AMA on the reddit forum, with topics including Ethereum Workshop 2.0 creation and roadmap, etc. 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 undergo major changes?
Vitalik Buterin: Over the past few months, there have been Many things are evolving, and I think it's worth summarizing the changes here (which will affect the specification writing for the next two years):
;
➤ Roadmap centered on Rollup. Simplify Phase 1 into data shards (for rollups), making it easier to implement.
➤ Simplifies merging eth1 and eth2. Roughly based on this roadmap, but now 1) eth1 transactions can be done 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.
➤ Stages run in parallel. This is the latest 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 making eth2 really usable . 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. Running the stages in parallel further speeds up merging, possibly even before sharding is implemented.
As part of the rollup centric strategy, "Phase 2" , that is, shard execution) is not that important at present. Mainly because the ultimate goal of phase 2 (i.e. achieving high TPS) can be achieved on the basis of data sharding (phase 1) + rollups, and even better. Sharding + rollups will be implemented before phase 2, so it is a better choice to focus on this part for now. 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 sooner the merger of eth1 and eth2 comes , the faster PoS is realized, the sooner everyone can see the 100,000 TPS Ethereum.
Source:
Justin Drake: In the long run, most of the logic of the beacon chain may compare Big changes:
➤ light client support
➤ Secret proposer election
➤ Use VDF to provide unbiasable randomness randomness)
➤ vote for eth1 improvement for the merge process
➤ beacon Block data availability sampling
➤ Upgrade BLS aggregate signature to post-quantum alternative
➤ Casper FFG upgrade to Casper CBC
➤ replace SHA256 with an arithmetic-friendly hash function (if found SHA256 is not safe, then use a safer function)
➤ adjust state
Source:
Q: Based on the current parallel route of light clients, merging and sharding, what might be the order of implementation? (Which part is faster/easier to implement)
Vitalik Buterin: light Client support is easy to come by in 2021, and 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.
Source:
Justin Drake: Possible Delivery Sequence:
➤ PoS—"phase 0"
➤ light client—"phase 0.5"
➤ data fragmentation—"phase 1"
➤ Merge eth1 and eth2—"phase 1.5"
➤ Built-in VM—"phase 2"
Phase 0.5 is likely to happen in 2021, ideally phase 1 It could also happen in 2021.
Source:
Q: How long does Phase 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) as soon as it is ready Going online, including building, testing, testnet, etc.
As for the merge phase (phase 1.5), I hope to wait until the beacon chain After running smoothly in a production environment 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.
Source:
Vitalik Buterin: "Minimum run time before sharding" and "Before merging The minimum run time" is not the same. Shards can go live after they are stable.
As far as merging, I can only say that it is up to the community and not Me, this is 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.
As 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 $50 billion The ecosystem is truly migrating to the beacon chain.
Source:
Q: According to the TXRX team's 52nd implementers meeting on the executable beacon chain Proposal, 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 option, and being able to access shard data locally also reduces the complexity of consensus. This is a very elegant design, and related prototype work is currently underway (may soon usher in the beacon chain merge testnet!)
At present, I personally agree with this design, but I will wait until a few months to see the actual effect.
Dankrad Feist added: just to add, before we get stateless Eth1 , which is the only possible design.
Source:
Q: In the current development route, is there any area that the team has not yet clarified? Implementation method and feasibility?
Justin Drake: In terms of data sharding and merging of eth1 and eth2, The research work has been done, and the risk is relatively low, mainly engineering and coordination issues.
I think we will eventually need a built-in virtual machine (aka 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 standpoint, I think we’ve Phases 0, 1, and 2 with specific plans 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 still face quantum security challenges . But further research and exploration are needed.
Source:
R&D Status
Q: Among the different Ethereum 2.0 components, including light clients, sharding, merging, eWASM, execution environments, rollups, etc., which areas are actively being researched and developed? 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 in progress Specification writing. There are still engineering challenges around data availability sampling, but we have a simpler solution, sharding with only committees.
➤ Consolidation of eth1 and eth2: I expect the Coordination can be difficult, especially in a rigid eth1.
➤ eWASM: Phase 2 (i.e. built-in Eth2 VM) is not a top priority in a medium-term rollup-centric 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 in the medium term (even long term) is a good enough alternative to the execution environment.
➤ Rollups: Rollups are not part of the eth2 consensus, but is an urgent need for layer 2 infrastructure and thus falls outside the scope of the EF Eth2 team.
Source:
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:< /p>
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 enough, and it is reasonable to lower this threshold to avoid ETH in the contract being locked for too long of. The rewards will be very high for early participants and may also attract later validators.
But on November 24th or December 1st If the parameters are modified, it seems a bit radical. 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 favor 12 The month will not move, and if necessary, the parameters will be modified in early January. This seems to be desirable.
Source:
https://www. reddit.com/r/ethereum/comments/jvkoat/ama_we_are_the_efs_eth_20_research_team_pt_5_18/
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 tough but honest answer: In the short to medium term, eWASM has been de-emphasized in the current roadmap.
The main reason is:
➤ Changing from one virtual machine to two also doubles the consensus complexity.
➤There are already many things in our plan, but compared to the parts in the PoS+sharding roadmap, the benefits of switching virtual machines are quite low.
➤ Many of the benefits originally envisioned by eWASM (i.e. execution at near-native speed, eliminating the need for precompilation) have not yet been realized. 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, just need certain skills (such as weierstrudel)
At present, EVM 384 can help us eliminate a lot of precompilation needs.
So, in the short term, the possibility of eWASM exists as rollups (since you can use any state transition function inside rollups, you just need to write a fraud proof for it).
In the long run, I think it is necessary and for good reason to EVM is upgraded. For example, in the long run, we need ZK-SNARK virtual machine execution. WASM is more efficient than EVM, and a subset of WASM specially designed for SNARK will be more efficient.
Source:
EIP-1559
< p align="justify" line="JuNp">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 fragmented data in the ETH 2.0 specification The fee market part of . 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.
In theory, there is a lot of overlap between ETH 1.0 and ETH 2.0 Partially, so most of the R&D effort for 1559 on the eth1 mainnet today is applicable to the design and understanding of using this tool in the eth2 data market.
Source:
Justin Drake: Yes, the logic approximates the fee and price mechanism of EIP-1559 (ie fee burn) will be part of Phase 1.
The implementation of EIP-1559 on Eth1 may provide the community with these mechanisms more Clear picture and de-risked 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 while. 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.
Source:
Execution environment&rollups
Q: Can all Execution Environments (EE) envisioned for Phase 2 be implemented on roll-up? From an innovation perspective, what are the disadvantages of a roll-up-centric roadmap?
Vitalik Buterin: Yes, all EEs will be rollups. I would say that a rollup-centric roadmap is better for innovation because it's more "permissionless" (anyone can create a rollup with any rules), so it enables participation by various teams, including those with current core The development process is not similar.
The main disadvantage of this approach is that we risk losing the developer network effect Risk, because the internal execution rules of many different rollups are fundamentally different. 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.
Source:
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 on Eth2 are still the same entity. In rollups, entities become zero-knowledge proofs (zkrollups are not currently available for general-purpose executions) or fraud proofs (optimistic rollups) generated for correct execution.
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 when generating 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.
Source:
No state
< p align="justify" line="iNHW">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 There are two reasons: one is to prevent resource usage from greatly increasing when blocks cannot be finalized for a long time, and the other is because people running geth nodes are very inclined to vote for ETH1.0 block headers.
Justin Drake: Both reasons are temporary and I expect Will be resolved in 2021:
What happens when blocks fail to finalize Explosion of resources required: It is a good idea for the client to find a way to solve the problem that cannot be finalized. (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: Synchronize light clients on general Eth1 block headers Building a layer of data on top of it is enough to solve this problem. This data layer is equivalent to a gossip network for broadcasting deposit certificates (that is, deposits in the Eth1 block header and corresponding Merkel certificates).
Q: If almost every validator node runs geth or at least With the ability to run geth, why not have every beacon block contain a new eth1 block, allowing beacon block producers to replace miners more quickly?
Justin Drake: I am very concerned about requiring block proposers to run an Eth1 full This view of nodes is 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 One ETH is the minimum pledge amount, which is a huge amount, and after the full realization of PoS, it is almost certain that the price of ETH will rise. In reality, people who hold 32 ETH actually plan to pledge in the pledge pool (decentralization is of course best), and those who can afford to run multiple nodes will do it themselves.
How many verifiers will really risk their nodes 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, There are two reasons:
1. If holding much less than 32 ETH can be pledged 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).
Source:
Additional issue
Q: What is the maximum supply of ETH?
Vitalik Buterin: I think now is a great opportunity to Here are some less popular but important points to make. 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, the economic model of Ethereum is undergoing a complete reform in three aspects: (i) PoW -> PoS, (ii) the introduction of EIP 1559, (iii) the transfer of user activity 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 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 Eth1-> Eth2 is merged, and the issuance plan is about 4.7 million per year; after the PoS mechanism is fully operational, minus the destroyed ETH (the amount of destruction even exceeds the issuance), the annual issuance 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!
Source:
Q: What will be the total circulation of ETH?
Justin Drake: When Eth1 and Eth2 merge, the PoW chain will Stop issuing additional 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.
Source:
;
Test network
Q: Is there any Planning 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 :)
For more information about Pyrmont, please read "Eth2 Update Quick Facts #20"
https://pyrmont.launchpad.ethereum.org
< a href="https://pyrmont.beaconcha.in" target="_blank" rel="noopener noreferrer nofollow">https://pyrmont.beaconcha.in
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 be calculated with tools like this:
https://www.stakingrewards.com/earn/ethereum-2-0/calculate
Source:
Branch line
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! One of the benefits of a rollup-centric roadmap is that it leaves 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.
Source:
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
