BTC
ETH
HTX
SOL
BNB
View Market
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

What will be the maximum supply of ETH?

ECN以太坊中国
特邀专栏作者
This article is about 7417 words, reading the full article takes about 11 minutes
The Ethereum Foundation research team conducted the fifth AMA on the Reddit forum, with topics including Ethereum 2.0 genesis and roadmap, etc.
AI Summary
Expand
The Ethereum Foundation research team conducted the fifth AMA on the Reddit forum, with topics including Ethereum 2.0 genesis and roadmap, etc.

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, and 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

1. After phase 0 goes online, which part of the existing specification will undergo major changes?

Vitalik Buterin

A lot has evolved with regards to the roadmap over the past few months, and I thought it would be useful to summarize the changes here (which will affect the spec writing for the next two years).

1. Rollup-centric roadmap. Simplified "Phase 1" into data shards (for rollups), making it easier to implement.

2. Simplify the 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 process of merging, and the PoC phase is currently underway.

3. Phases run in parallel. This is the latest initiative, and perhaps (its importance) the most underestimated. 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. Running the stages in parallel further speeds up merging, possibly even before sharding is implemented.

As part of the rollup central strategy, "phase 2" (phase 2, that is, shard execution) is not that important at present. The main reason is that the ultimate goal of phase 2 (that is, achieving high TPS) can be achieved on the basis of data fragmentation (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 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 faster the merger of eth1 and eth2 comes, the faster PoS is realized, and the sooner everyone can see the 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 votes 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 (or use a more secure function if SHA256 is found to be insecure)

  • Adjustment of status

2. Based on the current parallel route of light clients, merging and sharding, what is the likely order of implementation? (which part is faster/easier to implement)

Vitalik Buterin

Light client support is easy to implement 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 test version by the end of 2021. It is not yet sure whether 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"

  • eth1 and eth2 merge—"phase 1.5"

  • Built-in VM—"phase 2"

Phase 0.5 is very likely to be achieved in 2021, and ideally phase 1 may also be achieved in 2021.

3. 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

I personally think that more than 100,000 ETH in the contract is enough for the first launch, and it is reasonable to lower this threshold to avoid the ETH in the contract being locked for too long. The rewards will be very high for early participants and may also attract later validators.

However, it would be a bit radical to modify this parameter on November 24 or December 1. 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.

4. How long does phase 0 need to run? Will the phases after phase 0 be implemented based on fixed time 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.

Vitalik Buterin

"Minimum running time before sharding" is not the same as "minimum running time before merging". Shards can go live after they are stable.

As for the merger, all I can say is that it was up to the community, not me, and it was 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 rest assured that this $50 billion holding The ecosystem is truly migrating to the beacon chain.

5. Will EF change the architecture of Ethereum 2.0 according to the proposal of the 52nd implementers meeting TXRX team on the executable beacon chain?

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 having native access to shard data also reduces consensus complexity. This is a very elegant design, and related prototype work is currently underway (maybe soon usher in the beacon chain merge testnet!)

Personally, I'm in favor of the design at the moment, but we'll have to wait a few months to see how it works.

Dankrad Feist added:

To add, this is the only possible design until we achieve stateless Eth1.

6. Among the different Ethereum 2.0 components, including light clients, sharding, merging, eWASM, execution environments, rollups, etc., which areas are being actively 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 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 a rigid eth1.

  • eWASM: Phase 2 (i.e. the built-in Eth2 VM) is not a 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: The Rollup VM is a good enough replacement for the execution environment in the medium (or even long) term.

  • Rollups: Rollups are not part of the eth2 consensus, but an urgent need for the second-layer infrastructure, so they are not part of the EF Eth2 team.

7. In the current development route, are there any 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. At present, it is mainly an engineering and coordination issue.

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 (SNARK friendly EVM alternative). There are still important open problems at the research and engineering intersection of Eth2 zkVM.

Dankrad Feist

From a research point of view, I don't think there are any insurmountable challenges for Phases 0, 1, and 2, which we already have concrete plans for. But in Phase 1 and Phase 2 we still have execution issues to be resolved, 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.

8. What is the current status of eWASM? Does eWASM or WebAssembly make sense in a rollup-centric roadmap?

Vitlaik Buterin

The main reasons are:

The main reasons are:

  • Changing from one virtual machine to two also doubles the 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 benefits originally envisioned by 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 some skills (such asweierstrudel)

at present,EVM 384Can help us eliminate a lot of precompilation needs.

Therefore, in the short term, the possibility of eWASM exists as a built-in execution engine for rollups (since within rollups you can use any state transition function, you only need to write a fraud proof for it). In the long run, I think it is still necessary and there are good reasons to upgrade the EVM. For example, in the long run, we need ZK-SNARK virtual machine execution. WASM is more efficient than EVM, and the SNARK-friendly WASM specially designed for Subsets are more efficient.

EIP-1559

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 on 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 is part of the fee market for sharded data in the ETH 2.0 specification. According to the plan, the transaction execution of ETH 1.0 will use a similar fee destruction 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, so most of the research and development efforts for 1559 on the eth1 mainnet today are applicable to the design and understanding of using this tool in the eth2 data market.

Justin Drake

Yes, a logical approximation to EIP-1559's fee and price mechanism (i.e. fee burning) will be part of Phase 1.

An 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 (e.g. driving education and integration with wallets) to take place on Eth1.

The fee burning mechanism of ETH 1.0 and ETH 2.0 will be slightly different, and they will coexist for a period of time. Our idea is that after the merger of ETH 1.0 and ETH 2.0, the fee burning mechanism of ETH 2.0 will replace EIP-1559.

Execution Environment & Rollup

Can all Execution Environments (EE) envisioned for Phase 2 be implemented on roll-up? From the perspective of innovation, what are the disadvantages of a roll-up-centric roadmap?

Vitalik Buterin 

Yes, all EEs will be rollups. I'd say 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 the current core The development process is not similar.

The main downside of this approach is that we risk losing the developer network effect because the internal enforcement rules of many different rollups are now 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.

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 rollup, entities become zero-knowledge proofs generated for correct execution (zkrollup cannot yet be applied in general execution) or fraud proofs (optimistic rollups).

no status

no status

1. 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, for two reasons: one is to prevent the resource usage from increasing significantly when the block cannot be finalized for a long time, and the other is because the people who run the geth node Will be very inclined to vote for the block header of ETH1.0.

Justin Drake

Both reasons are temporary and I expect to be resolved in 2021:

Explosion of resources required when blocks fail to finalize: It is a good idea for the client to find a way to resolve the failure to finalize. (Finality is now theoretically being used as a pivot point.) We now have some plans (cc /u/protolambda) where we will build a long-running testnet where the network cannot finalize blocks, thereby forcing The client is optimized.

Vote for Eth1: Building a 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, which is used to broadcast deposit certificates (that is, in the Eth1 block header. Deposit with corresponding Merkel certificate).

2. If nearly every validator node is running geth or at least has the ability to run geth, why not have every beacon block contain a new eth1 block, allowing beacon block producers to replace miners faster ?

Justin Drake

I am very disgusted with the idea of ​​requiring block proposers to run an Eth1 full node. This is completely against the design goal of allowing Eth2 validators to run nodes on Raspberry Pi.

The questioner replied:

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 is almost certain that the price of ETH will rise. In reality, people who hold 32 ETH are actually Intend to stake in a staking pool (decentralization is of course 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 amount of 32 ETH is irrelevant for two reasons:

  • If you hold far less than 32 ETH, you can pledge it in an m-of-n pool

  • We want to focus on rewards, not stake amounts. 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 return, and the return may even be negative, if you participate in the m-of-n pool (see point 1).

additional issue

1. What is the maximum supply of ETH?

Vitlaik 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, the hexary trie will be replaced by the binary trie, PoW will be eliminated and replaced by PoS, and we will add a new technology "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 deserves 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, subtract the destroyed ETH (the amount of destruction even exceeds the issuance) and the annual issuance 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 complete (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!

2. What will be the total issuance of ETH?

When Eth1 and Eth2 merge, the PoW chain will stop issuing ETH. In fact, the ETH issuance of the PoS chain will be limited to about 1 million per year. I hope that the fee destruction setting of EIP-1559 will more alleviate the problems caused by the additional issuance of PoS.testnet。

testnet

Are there any plans to launch another testnet? And according to the current Eth2 mainnet specification, there are the same number of verifiers, so that the community can understand the profitability of joining Genesis in real time?

Justin Drake

Pyrmont testnet launched yesterday :)

More information about Pyrmont can be read in "Eth2 Update Quick Facts #20"

https://pyrmont.launchpad.ethereum.org

https://pyrmont.beaconcha.in

https://pyrmont.eth2.wtf

questioner

I know, I have participated in the testnet. But the Pyrmont testnet can accommodate 100,000 validators, will there be plans to launch a public testnet with 16,000 validators?

Justin Drake

tooltoolto calculate:

https://www.stakingrewards.com/earn/ethereum-2-0/calculate 

branch line

Can we achieve transparent sharding with rollups? (i.e. developers and end users don't even know it's there)

Vitlaik Buterin

Website: ethereum.cn

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.

Official Account: ETH Chinese Station

Website: ethereum.cn

ETH
投资
Welcome to Join Odaily Official Community