Title: A_Train_Station_Model_for_Network_Upgrades
Category: Magicians

Author: timbeiko
Date: 2019-10-23T18:43:41.279Z

@shemnon and I gave a talk at devcon proposing a way to do network upgrades that combined a lot of the ideas discussed by the community over the past year (including the recently discussed EIP-centric forking).
I wanted to share it here so that we can try and use EthMagicians as the official discussion forum for it.
Here is the proposal: https://medium.com/@timbeiko/train-planes-network-upgrades-6edfc9f6b7dd

Author: antonydenyer
Date: 2019-10-24T11:05:43.659Z

It’s worth noting that a number of large software projects follow this kind of process Software_release_train. I think the main risk with a 6-month release cycle is that everyone panics and tries to pile on so as not to miss the train! It’s a definite improvement on the current process.

Author: timbeiko
Date: 2019-10-24T13:29:13.055Z

antonydenyer:

I think the main risk with a 6-month release cycle is that everyone panics and tries to pile on so as not to miss the train! It’s a definite improvement on the current process.


Agreed, but that’s already the case with our current process ! Everyone piled in on May 17th when it was the deadline for Istanbul. I think that not knowing when the next upgrade is accentuates this problem, though.
Also, we sort of did this already, by moving a lot of EIPs that weren’t ready for Istanbul to a “Tentatively Accepted” state for what was first called “Istanbul 2” and now is “Berlin”, see: EIP-2070: Hardfork Meta: Berlin
This framework makes that process more explicit

Author: souptacular
Date: 2019-10-24T20:02:54.412Z

I think the article was great! My initial thoughts are the following:

I think having 2 forks a year in a schedule is a good first step since we are currently at 1 fork a year. We don’t want to move too fast.
On the other hand, we have important 1x tasks ahead if we want to control state growth and I worry that 2 HF’s a year may be too little for that to progress effectively. Maybe @AlexeyAkhunov can chime in.

Author: timbeiko
Date: 2019-10-24T20:15:02.787Z

souptacular:

On the other hand, we have important 1x tasks ahead if we want to control state growth and I worry that 2 HF’s a year may be too little for that to progress effectively. Maybe @AlexeyAkhunov can chime in.


Agreed! I’d like to know of specific cases requiring >2 HFs per year.
We could keep everything else in the proposal and have HFs every quarter instead of every six months, but that just seems unrealistic for now given our prior cadence.

Author: AlexeyAkhunov
Date: 2019-10-24T21:34:50.031Z

Although it is a bit too early to say how many hard forks are required for the introduction of Stateless Ethereum (because we have various options along the way), I currently think 2 per year should be enough. I am hoping to start publishing more details of the proposed transitions soon, as we are getting close to releasing Turbo-Geth and verifying some assumptions about block witnesses

Author: rumkin
Date: 2019-10-25T06:14:11.636Z

As addition to this proposal. I want suggest to replace hardfork names with version numbers pointed to year and month fork originated to like Node.js and Ubuntu have. Current naming model is highly confusing and it’s just impossible to say which hardfork is the latest.

Author: timbeiko
Date: 2019-10-25T13:36:32.529Z

While I agree with the idea of using numbers instead of names (at least in the code — names are fun from a marketing/community perspective!), I think it’s a sufficiently disjoint idea to consider it independently from this proposal.

Author: tvanepps
Date: 2019-10-25T14:09:39.663Z

why not both - fun names for the community and #'s for developers

Author: timbeiko
Date: 2019-10-25T14:21:32.740Z

Yep, that’s what I was saying. Use numbers in the code, and “marketing names” with the community.

Author: rumkin
Date: 2019-10-27T10:10:01.477Z

Trains and schedules are tightly coupled, and it seams logical to me to append this item. With such addition your proposal looks completed to me. So maybe you’ll change your decision. And, if it will be decided by core members, disjoin it into separate proposal after discussion.