eth2-research-ama-phase-0-genesis-edition

Ethereum Foundation co-founder Vitalik Buterin along with the research team answered a number of community's questions on reddit during 'Ask me anything' or AMA session on Reddit. The main focus was to answer any questions related to Phase 0 Genesis, though the team also cleared doubts on Eth1.0 and Eth2.0 merger and explained the roadmap. This article aims to share excerpts of some of the questions asked in the AMA.

Phase0

Is there a plan B if 16,384 validators are not reached by November 24?

A Redditor DistantView asked this question while citing the unavailability of pool funds like Rocket Pool to be able to send funds to the deposit contract until sometime in 2021 which excludes people with less than 32 ETH from participating in eth2 until contract interactions with the deposit contract are sorted.

In response, Danny Ryan mentioned a simple plan B is to change the min_genesis_active_validator_count to whatever validator number is present on November 24 to allow eth2 to start on 1st December. He further added that for initial launch, the 100k+ ETH in the contract is sufficient, and that adjusting the threshold down to not leave that ETH in limbo for too long makes sense. Rewards will be very high for these early adopters and the ETH validating will likely grow over time.There is a discussion about options available here -- https://github.com/ethereum/eth2.0-specs/issues/2134

Which piece of the current spec do you think will change the most after Phase0 launch?

This is one of the ice breaking questions asked by Protolambda, a lead Eth2 developer and very well responded by Vitalik that provides the overview of expected changes.

Vitalik said, ”Somewhat of a tangent, but there have been a lot of things moving around in the roadmap in the last few months, and I thought it's worth summarizing exactly what has changed (this is relevant to how spec code will evolve over the next ~2 years).

The three most important changes are:

The rollup-centric roadmap, streamlining "phase 1" into something that's just designed to shard data (for rollups to use), making it easier to implement.
The simplified merge. Roughly according to this roadmap, but now (i) eth1 transactions will live directly on the beacon chain instead of being in a shard and (ii) the execution pause during the merge can potentially be greatly shortened thanks to optimistic execution. This makes implementing the merge easier, and a PoC is already starting to be implemented.
Parallelization of phases. This is the newest of all, and perhaps the most underrated. Essentially, (i) light client support, (ii) data sharding (aka "phase 1") and (iii) the merge are all being specced in such a way as to be independent of each other, so each piece can be implemented "when ready" regardless of what stage the other pieces are at.
All of these changes are designed to decrease the time until eth2 becomes useful to people. Light client support will likely come well before sharding, making the beacon chain quickly useful even as a tool for getting consensus on the eth1 chain. The simplified merge means that the merge happens sooner. Parallelization of phases further opens the door to the merge being implemented even sooner than expected; there's even a chance it could happen before sharding.
As part of the rollup-centric strategy, "phase 2" (native sharded execution) is de-emphasized for the time being. This is because the ultimate goal of phase 2 (very high TPS) is achieved even better by data sharding (phase 1) plus rollups, which is expected to come sooner than phase 2, so it's better to just put all of our effort at the moment into making those pieces happen sooner. That said, we are not making any irreversible moves that prevent us adding native sharded execution in the future; the roadmap is fully compatible with that being added at any point if it is desired.

TLDR: merge happens faster, PoS happens faster, you get your juicy 100k TPS faster.

Realistically, it will be mostly additions (of light client stuff, sharding support, the merge), less changes of existing code, though he does have some ideas of how to further simplify rewards accounting.

Over the long term most of the beacon chain logic could change significantly, added Justin Drake. The changes can be:

light client support
secret proposer leader election
unbiasable randomness with VDFs
revamp of Eth1 voting for the Eth1 merge
data availability sampling for beacon chain blocks
upgrade of BLS aggregate signatures to a post-quantum alternative
upgrade of Casper FFG to Casper CBC
replacement of SHA256 with arithmetisation-friendly hash function (or a more secure function if SHA256 is found insecure)
tweaks to make state transition function friendly to fraud proofs, SNARKification, and/or formal verification

How to deal with the problem of reliable validators being punished during long periods of non finality?

To improve friendliness for honest-but-imperfect validators during an inactivity leak, Vitalik made this proposal: https://github.com/ethereum/eth2.0-specs/issues/2125

The Eth2.0 roadmap

The team gave much clarity on the order of delivery. Phase 0.5 will likely happen in 2021. Chances are phase 1 could also happen in 2021 if the order of delivery which is as follows is well- implemented as per the plan.

PoS—"phase 0"
light client—"phase 0.5"
data sharding—"phase 1"
merge—"phase 1.5"
enshrined VM—"phase 2"

Is there any point on the roadmap the team is uncertain about?

Talking about the roadmap and risks associated with the upcoming Eth2.0, Justin Drake said that the research is already been done and only low risks are suspected with data sharding. Eth1 and Eth2 are at the stage where developments in engineering and coordination are to be looked after. Justin further elaborated that they would be needing a new enshrined VM (virtual machine) similar to zkVM to replace EVM (Ethereum virtual machine). SNARK can be a friendly alternative to EVM. zkVM is a zero-knowledge virtual machine and is a blockchain transaction format with zero-knowledge smart contracts to simplify transactions. EVM are expensive and developed coding errors with time. There are still speculations upon using a new VM like eWASM.

What is the current state of Eth2.0?

Dankrad Feist explained the current situation of the eth2 roadmap and integration into the ecosystem. There are still execution problems with eth1 and eth2 that need a solution. By simplifying the merger means that the merger will take place sooner. He said, "On the longer term roadmap, we have quantum security. I think that is one where we still need some research to make it practical and performant (although some systems with tradeoffs could probably be built in any case).

On the roll-up centric roadmap, do ERC-20s simply live on each roll-up rather than on each shard? Also, how does ETH1 fit into the roll-up centric roadmap?

Vitalik responded that ERC20s would still have their base contract on the eth1 base layer (which will eventually be merged into eth2 and live as part of the beacon chain), and then individual coins can live on any rollup (or plasma). A rollup-centric Ethereum could be based on Fraud Proofs like Optimistic Rollup or Validity Proofs like ZK Rollup depending on what people build, he added.

Any piece of the roadmap that needs help or still has no idea how it is going to be done?

Responding to the question, Justin Drake said that it's mostly engineering and coordination now and that the research is done all the way to data sharding and the Eth1/Eth2 merge. However, there are still significant open problems at the intersection of research and engineering for Eth2 zkVMs.

Adding to this Vitalik expressed his desire of the state tree to eventually be replaced with some kind of clean and efficient arithmetic commitment with "all the nice properties". Extending the invitation to cryptographer & researchers he said, Eth2 research & development team are happy to engage with anyone who has ideas.

On the longer term roadmap, the R&D team has quantum security that may use further research to make it practical and performant, added Dankrad Feist

What is the max supply of ETH?

Eth2.0 and EIP-1559 relationship

EIP-1559 is part of ETH 2.0 spec and will be implemented in Phase 1. A lots of work is being done on the EIP for ETH 1.0. Will efforts on Eth1.0 and Eth2.0 overlap or invalidate each other?

The team also tried to eliminate doubts regarding EIP-1559 from the minds of the people as because EIP-1559 is the part of both Eth1 and Eth2 and confusions are around its overlap. To this Danny Ryan replied that assuming EIP-1559 goes live to mainnet will come with complimentary features. EIP-1559 is part of the eth2 spec in the fee market for shard data and that similar fee burn and gas-price mechanics are used to price shard data as is planned for TX execution in eth1. After both merges into one, 1559 style txs will be available inside of eth1 execution while 1559 style fee market for shard data can be found inside of the eth2 data shards.

The fee burning part of EIP-1559 will remain part of phase 1 and equivalent for ETH1 and 2.0. Although the fees burning mechanism will be a bit different and co-exist for some time but it will change after the merger. As soon as the merger happens, EIP-1559 burning fees will get replaced with Eth2 fee burning.

Members of the Ethereum Foundation's Eth 2.0 Research team have been organizing the AMA sessions from time to time to answer community questions. This was their 5th AMA in the series. Earlier AMAs can be found at

Click here to view the 4th EF Eth 2.0 AMA. [July 2020]

Click here to view the 3rd EF Eth 2.0 AMA. [Feb 2020]

Click here to view the 2nd EF Eth 2.0 AMA. [July 2019]

Click here to view the 1st EF Eth 2.0 AMA. [Jan 2019]

Vitalik hopes that once the testnet for eth1 merges with that of eth2, it can end up replacing the existing testnets. If happens, it would provide people with a suitable ethereum testing environment and would benefit in recognizing parts of the merge implementation.