Editor's Note: This article comes fromBabbitt Information (ID: bitcoin8btc), translated by Free and Easy; The original text comes fromredditEditor's Note: This article comes from
Babbitt Information (ID: bitcoin8btc)reddit, translated by Free and Easy; The original text comes from
, by Hudson Jameson , reprinted with permission by Odaily.
On January 24th, researchers and developers of Ethereum 2.0 presented at ethereum
Before reading these questions and answers, I suggest that you first understand the content about Ethereum 2.0:
Justin Drake ：
Evolution of Ethereum: A Guide to ETH 2.0 Engineering
Ethereum 2.0 Phase 0 Specification
Justin Drake：
Question 1: When do you think Ethereum will be able to solve the scalability problem?
In phase one (I estimate around 2020), we will have sharded data. These shards can be used as a data availability layer for TrueBit (and other optional execution engines) even without an EVM. In phase two (around 2021), we will have a scalable L1 layer.
Vitalik Buterin ：
Question 2: What is the latest timetable for launching PoS?
I expect the beacon chain (the core PoS chain) to launch by the end of 2019. Ideally, the specification should be nearing completion in the first quarter, the cross-client testnet launch in the second quarter, the security audit in the third quarter, and the mainnet launch in the fourth quarter. As a rule of thumb, a December launch is hard to come by because of the holidays. So November 2019 and January 2020 are the most likely times I think it will happen.
Question 3: Have you consulted economists about the issuance rate of the complete PoS system? More broadly, who is helping or advising the Ethereum 2.0 team on certain issuance decisions, and what impact (short and long term) will such decisions have on the network and community?
Vitalik Buterin：
Personally, the feedback I'm most interested in is actually that of potential investors. The main question is whether we can make any other adjustments to the economy and give it a fixed level of rewards that would (1) encourage more people to participate in validating, (2) encourage many small individual validators or smaller pools, Rather than several large pools.
Justin Drake：
(Translator's Note: In other words, the Ethereum team has not yet determined the issuance rate of the full PoS system, and Vitalik prefers fixed rewards)
Question 4: If a developer is hesitant to build on the Ethereum platform, what is the best response given that it will be "replaced" by Ethereum 2.0 in the next few years?
Vitalik Buterin：
I hope that once Serenity's state and execution model is solidified (see https://etresearch.ch/t/a-minimal-state-execution-proposal/4445 for a minimal proposal), we will start working with the developer community Modify high-level languages (solidity, Vyper, etc.) and best practices. Hopefully by that time, it will become clearer about how to build the app. At least, that would be my expectation.
Justin Drake：
Building applications on top of Ethereum 1.0 today is great for learning and prototyping. It's also good for building a team with a culture that fits the philosophy of the Ethereum community (which may differ from the philosophy of the Bitcoin, Ripple, Bitcoin Cash, EOS, Tether, etc. communities).
Question 5: Assuming we have multiple deposits of 32 Eth, can we run multiple validator clients on one machine?
Yes! There is nothing stopping you from using one machine to run multiple validators. The only hard limitation you will face is that the number of shards you are assigned to validate scales linearly with the number of validator slots you have, so if you have thousands of ETH a laptop is not enough and you More powerful machines are needed.
Short answer: yes. Longer answer: you need to register a validator for every 32 ETH. In phase 0 (just the beacon chain, no sharding), you can handle thousands of validators on a single machine.
Justin Drake：
After phase 1, the number of validators you can operate on a machine depends on how powerful your machine is. A mainstream laptop should easily handle one validator and max out at 2-10 validators.
Computational resources scale linearly with the number of validators until around 1000 validators are reached. At this point, there are scalability advantages to being a supernode (i.e. a full node for each shard).Question 6: Given that Yoichi has left the Ethereum Foundation, what are your plans regarding formal proofs for the Ethereum 2.0 specification?
I'd say formal proofs of the spec make sense when the spec is more mature and stable, probably in mid-2019. Anyone interested in a formal proof of the Ethereum 2.0 specification within a few months, please send a grant proposal.
Question 7:
Vitalik Buterin ：
From my limited understanding of the Ethereum 2.0 spec, I think shards will be mostly independent, and cross-shard communication will be slow and require multiple steps. Therefore, smart contracts can only actively interact with assets within the deployment shard, and must interact with external assets through slow cross-shard communication.
Given this topology, aren't we planning to increase scalability at the expense of user experience (slowly responding to smart contracts in unobtrusive ways)?
Justin Drake：
For example, if I want to play a game of CryptoKitties, I need to make sure I'm interacting with the contract deployed on the shard my eth address resides in, and not any other contracts residing on other shards. Then, if I want to interact with another kitten that resides on a different shard user, my experience is much slower and more cumbersome than the other side's (at least that's how I understand the system to work, if I Wrong, please correct me). Considering that the ultimate goal is to scale to a large number of shards, the possibility of cross-shards will increase exponentially over time, so the user experience will become worse and worse.
Cross-shard communication will definitely be slow at the base layer, but there are more advanced mechanisms that can be used at the base layer and enable fast cross-shard communication, allowing any cross-shard communication even if it is slow. See https://ethresear.ch/t/a-layer-2-computing-model-using-optimistic-state-roots/4481 for how to do it.
Question 8: After switching to Ethereum 2.0, what will happen to all currently running Ethereum contracts?
My best guess is that Ethereum 1.0 contracts will remain the same for a long time (eg, 10+ years) and they will not migrate to Ethereum 2.0. This can be achieved by doing two things:
Reduce inflation (e.g. reduce it by 20x, bring PoW computing power to other blockchains, such as ETC). It is also possible to eliminate inflation entirely (relying only on transaction fees) (see safety argument below).
Justin Drake：
Regularly finalize Ethereum 1.0 with Ethereum 2.0 to counterbalance reduced security against long-term 51% attacks. This requires Ethereum 1.0 nodes to become beacon chain light clients, which will take years to achieve.
If the community gets tired of Ethereum 1.0, a bomb mechanism (e.g. difficulty bomb, issuance bomb, gas bomb, etc.) can kill it gracefully. Another possibility is that Ethereum 1.0 becomes a contract for Ethereum 2.0. I don't think this is a practical solution, but I'd love to see others try to convince me.
Question 9: Is there any technology from any competitor (such as dfnity or any other competitor) that is worth incorporating into Ethereum 2.0, or whether all other dapp/smart contract platform work, is not related to Ethereum 2.0, or Said they are not good enough?
Danny Ryan：
Part of the job of a research team is to take good ideas from research papers and other blockchain projects. I'm very concerned about technically interesting projects like Dfinity, Coda, Zcash, etc. Competitors certainly have good ideas too, and learning from each other is part of the game.
Question 10: The Ethereum Constantinople upgrade has experienced successive delays due to bugs discovered during a relatively low-risk/simple upgrade.
And in phase 0 and phase 1 of Ethereum 2.0, what will you do to alleviate this problem, after all, these implementations will be more complicated? (i.e., what testing, third-party audits, and other considerations are you taking to ensure a seamless implementation?)
