Ethereum 2 and alternative POS implementations


#1

Now that the plans for Ethereum 2 has been announced, would that make it possible to experiment with both Vitalik’s and Vlad’s implementation?


#2

Reading Ethereum 2 makes me confused. Do you have a reference for the announcement? What do you mean by “Vitalik’s and Vlad’s implementation”? Please be more specific and give references, otherwise it’s hard to understand where you are coming from and what you are asking. I was under the impression that Ethereum 1.0 and 2.0 were used initially, but was later replaced with Frontier, Homestead, Metropolis (and consequently the sub-phases of Byzantium and Constantinople) and Serenity.


#3

Ethereum 2 was announced on the first day of Devcon3 by Vitalik. It is a plan on how to manage conflict between need for frequent hardforks and the high costs and risks with hardforks.

In short, if I understood it correctly, it is by using something similar to sidechains. It will be possible to create these without having to hardfork the main chain every time. Please see vide clip from DevCon3 for more details. I am not sure if there is a specific clip for this yet, otherwise you will find it as the last presentation on the first day.


#4

You can watch the announcement here: https://www.youtube.com/watch?v=Yo9o5nDTAAQ&feature=youtu.be&t=7h55m35s


#5

OK I will watch it. I had going through DEVCON on the to do list but I thought that focusing on Serenity was more important, but I will at least skim through to find parts that look most important for development of the core protocol. My understanding according to comments from Vlad on Twitter was that side channels weren’t worth it compared to sharding.


#6

The Ethereum 2 design will allow sharding be developed in parallel, before the POS.


#7

OK I just watched the talk. The talk highlighted that there are lots of good ideas being developed, and the validator manager contract on a sidechain of N shards looks like it’s well worth further development, as well as other future developments such as tight coupling (which I remember was originally presented earlier on sharding). The need to have deep changes is indeed critical for not only for rapid research and development, but also for quickly fixing vulnerabilities that are detected on operating software, as there have been the need to make such changes urgently in the event of vulnerabilities (e.g. DAO and Parity multisig wallets in July and this month).


#8

Yes. That’s what’s happening now:
Vitalik’s https://github.com/ethereum/casper
Vlad’s https://github.com/ethereum/cbc-casper