A Train Station Model for Network Upgrades

Process Improvement
1

@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

5 Likes
2

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.

1 Like
3

Agreed, but that’s already the case with our current process :sweat_smile:! 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 :slight_smile:

2 Likes
4

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.
5

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.

1 Like
6

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

3 Likes
7

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.

1 Like
8

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.

1 Like
9

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

10

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

2 Likes
11

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.

1 Like