EIP-233: Formal process of hard forks


#1

This topic is intended be the discussion for EIP-233. Any comment or feedback is very much appreciated!


EEP-5: Ethereum Hardfork Process - request for collaboration
#2

@axic, how do you think that this would appear in the process outlined in EIP-1?

Perhaps defining a separate EIP such as EIP-233 for actions taken by specified stakeholders in the community is an optimal approach, rather than aggregate all possible actions by non-Editors into EIP-1.

From EIP-1, this section in particular mentions the hard fork process:

Accepted (Core EIPs only) – This EIP is in the hands of the Ethereum client developers. Their process for deciding whether to encode it into their clients as part of a hard fork is not part of the EIP process.

  • :arrow_right:️ Final – Standards Track Core EIPs must be implemented in at least three viable Ethereum clients before it can be considered Final. When the implementation is complete and adopted by the community, the status will be changed to “Final”.

#3

I don’t think the EIP repo should be used for this, nor should the EIP process be used for this. The EIP process is a standards process. Hard forks are a deployment process. They are fundamentally different and IMO should be kept separate with separate processes.

For an analogy, W3C has a process for coming up with web standards and a place for hosting them and discussing them, but it doesn’t contain process for browser deployment/rollout or how web developers go about adopting new features.


#4

One of these days I’m just going to stake all my opinions with Micah.

BUT — we (with a definition of we needed) need to get better at hard forks. Who what where is that discussed.

Browsers are in competition and don’t need to coordinate to keep the Internet from breaking. In fact, they regularly break portions of it due to individual decisions.


#5

I think client developers can communicate among themselves however they like, including a GitHub repository where people propose things and a process for ratifying those proposals across teams. :slight_smile: I merely think that co-locating that decision making process with the standards process is not a good idea. I make no claims that the EIP process format shouldn’t be used. :slight_smile:


#6

I think EIP-1 is rather complex already and as @MicahZoltu reasons it may be a different process.

I think your reasoning is compelling, but I would say the situation is a bit more complex than that.

The meta “hard fork” EIPs I think are needed, because changes can be very interconnected/interdependent and there must be a way to a place to discuss how can they bundled.


#7

I’m really glad this discussion is back!

Creating a Meta HF EIP document should be a key part of the upgrade process. I would advocate for specifying that it is for a HF rather than just “Meta EIP”, and for using a code in referring to them along the lines of ERCs, e.g. HFM-1013 with the same numbering as EIP-1013.

I was recently looking at how the version of the protocol has advanced over time, and these HFMs were very helpful.


#8

Also related to EIP-233 discussion is this idea I’ve been working on about semantic versioning and release candidates.

Perhaps the HF Meta EIP document could have an event list, referring to all attempts to release the upgrade, and which network this happened on (i.e. 8.0.0-rc1 deployed to Ropsten).


#9

I agree that there needs to be a place to coordinate and discuss. I merely argue that we should have a separate place, not the standards repository. I would love it if ETH, ETC, EOS, etc. Could all use this repo for EIPs, and then each had a separate place for discussing which EIPs went into a hard fork, what block it was on, etc.