EIP-2982: Serenity Phase 0

Discussions for Serenity (eth2) Phase 0.
In addition to the EIP, see the eth2 specs repo for technical content and discussion.

3 Likes

I disagree with committing to using Serenity as a sharded PoS chain to transition Ethereum to at this nascent stage. It has yet to be proven theoretically (analysis of phase 0 alone is insufficent), and has certainly not been demonstrated to be viable in practice. There are a number of alternatives, some of which are on mainnet today, that would fulfil the same goal.

The EIP should also make it clear that Serenity is not inherently eth2 (i.e. the future of Ethereum), but rather a separate and Independent layer-1 that is planning to hard spoon the Ethereum state at a future time. And that the EIP suggests this new chain to be eth2, rather than starting from the assumption that Serenity is eth2.

It has yet to be proven theoretically (analysis of phase 0 alone is insufficent)

So this (especially the parenthetical) is actually not true! The reason is that if fundamental flaws are discovered in sharding for whatever reason, it’s always possible to instead just do the eth1 -> eth2 merge after phase 0. Phase 0 by itself is equally open to both of these future paths, so it’s not strictly speaking a hard commitment to anything but PoS itself.

And to be clear, the PoS part of eth2 is precisely the part that’s gone through quite heavy analysis and review. The Medalla testnet has been running for ~6 weeks, of which 4 weeks have been nonstop without issue (that was the original release condition for the eth1 frontier launch), and will run for considerably longer before phase 0 mainnet. Basically the main remaining uncertainty in the PoS is the economics, which by definition cannot be tested except on a live value-bearing network in any case…

The EIP should also make it clear that Serenity is not inherently eth2

Not sure what this is trying to say. Of course a proposed change to ethereum is not part of ethereum until it’s actually fully implemented and rolled out; that’s part of the definition of “proposal”. The fact that this particular proposal involves changing the ethereum system to temporarily be made up of two chains with one linking to the other (with a goal of later changing to yet another hub-and-spoke architecture of 64 shard chains that all link into a beacon chain) is a technical detail, not really any fundamental philosophical difference.

I would argue that EIP-2982 should include the entire specification of Serenity Phase 0, rather than summarizing and linking to external specifications. One key reason is that ACCEPT and FINAL status need to precisely indicate what is accepted, what is deployed.

Perhaps such a complete, single-page specification can be built from a tagged release of the Eth2 specification repo, and subsequent, forking changes later submitted as new EIPs.

Serenity Phases 1 and 2 could work the same way when they are ready to be submitted as proposals.

More thoughts on this are further elaborated in this PR comment.

1 Like

Does a specific release/commit of the spec repo not “precisely indicate what is accepted, what is deployed”?

Releases can easily be downloaded as a single zip file and that included or if we must, we could write a script to compile all markdown files into a single markdown file. That said, I’m not sure if this provides any additional value to the process than a release reference would

It does not as it points to an external resource; the URL may eventually break, repo deleted, or legal restrictions imposed for example. And I probably should have used the term concise rather than precise!

From EIP-1: “The EIP should provide a concise technical specification of the feature and a rationale for the feature.”

Perhaps a zip file is actually best, this would be the least work while fulfilling the requirement of fully specifying.

The additional value is providing all that is needed to develop an implementation from within the content of the EIP.

I agree with this, however, I don’t know if this needs to be done for EIP-2982, as nothing on mainnet changes with it. I would think this consolidation would happen whenever PoW is retired and replaced with PoS.