Title: More_frequent__smaller_hardforks_vs__less_frequent
Category: Magicians

Author: timbeiko
Date: 2019-03-15T18:22:04.513Z

In today’s AllCoreDevs call there was discussion about potentially moving from large hard forks containing several EIPs to smaller ones with less (or potentially only a single) EIPs.
The goal of this thread is to start a discussion around the Pros and Cons of each approach. I’ll begin by listing a few, but I don’t feel like I have the full picture, so it would be valuable for others to chime in. Namely, @AlexeyAkhunov, as you had advocated for smaller hard forks in the past and brought it up again in today’s call .
I will keep editing the argument lists below as people comment on the thread.
Arguments for Smaller, More Frequent Hard Forks

More frequent updates to the protocol;
Can separate concerns better / isolate changes;
Multi-hard-fork initiatives, such as State Rent, can drastically reduce their deployment time;
“Unless we make serious improvements in the way the EIPs are put it, there is little hope that Ethereum 1x will deliver what it is supposed to.”
Simplifies testing due to a more steady flow of less EIPs to test and less cross-EIP interactions to test.

Arguments for Larger, Less Frequent Hard Forks

Less frequent need for users to update clients;
There is a coordination cost to each HF, so more frequent ones involve more coordination work across major stakeholders running clients (e.g. miners, exchanges, block explorers, etc.);
Allows ample time for security evaluation
If hard forks are too close to each other, bugs found in a given hard fork may delay/push back subsequent hard forks

Other Considerations

Ad-hoc vs. fixed schedule for hard forks
Smaller hard forks may result in multiple hard forks happening in parallel (where various forks are at different deployment stages)

Author: sneg55
Date: 2019-03-15T18:27:33.102Z

We have to define that Users who need to update clients - it’s mining pools, exchanges, light wallets and infrastructure providers such as Infura.
They all benefiting from Ethereum ecosystem, and I think they will support more frequent updates.

Author: shemnon
Date: 2019-03-15T18:36:20.263Z

For users also consider that exchanges tend to shut down trading in the hours before and after a hard fork.
So is the question about smaller vs. larger hard forks or for ad hoc vs. scheduled hard forks?  If we want smaller more frequent hard forks we can still do that on a fixed schedule, perhaps every three months.  But if we do we will almost certainly have to pipeline and layer the process so that we may have three hard forks in flight: one is in the testing/deployment, one is in client implementation, and one is in EIP review.
I think a predictable and short schedule will result in smaller forks.  A quarterly/semi-annual mandatory update is what would result from a fixed schedule, vs a random and unpredictable mandatory update schedule.

Author: sneg55
Date: 2019-03-15T18:44:47.671Z

shemnon:

I think a predictable and short schedule will result in smaller forks. A quarterly/semi-annual mandatory update is what would result from a fixed schedule, vs a random and unpredictable mandatory update schedule.


We could set a quarterly schedule for network updates so that everyone will benefit from predictable timelines. For exchanges, pools and other users it’s easier to allocate resources for HFs when exact schedule is known.
And in case if something goes wrong as it was with Constantinople, EIPs from such hardfork just moving to next scheduled date, instead of creating new hardfork in between.

Author: timbeiko
Date: 2019-03-15T18:48:08.187Z

shemnon:

So is the question about smaller vs. larger hard forks or for ad hoc vs. scheduled hard forks?


Agreed, these two seem to be orthogonal. Will update the initial post.

Author: AlexeyAkhunov
Date: 2019-03-15T20:06:07.414Z

shemnon:

But if we do we will almost certainly have to pipeline and layer the process so that we may have three hard forks in flight: one is in the testing/deployment, one is in client implementation, and one is in EIP review.


Yes, and I think this is absolutely fine. However, it does require to change the ways the changes are done. First and foremost, if we pipeline the changes, we cannot rely on a single testing team to do all the test generation - that would need to happen while EIP is prepared.
Having more frequent upgrades (scheduled or not - it is orthogonal s @timbeiko noted) will help avoid half-baked changed that would need to be “squeezed through” before the deadline. Postponing something by 3 months is not as bad as postponing it by 9 months.
Also, it looks like Ethereum 1x has invigorated the appetite for more changes in Ethereum, which is good, but I do not want it to have to create too much tension when changes compete for the limited space in the large releases.

Author: timbeiko
Date: 2019-03-15T20:19:57.427Z

AlexeyAkhunov:

Also, it looks like Ethereum 1x has invigorated the appetite for more changes in Ethereum, which is good, but I do not want it to have to create too much tension when changes compete for the limited space in the large releases.


Good point. I think a related issue is that changes compete for limited client implementer resources. Whether hard forks happen every 3, 6, or 9 months, the amount of developers working on clients is more or less constant and if more time is spent implementing/testing/deploying EIPs, because of an overall growth in changes to the protocol, then less time is spent on non-EIP work.

Author: AlexeyAkhunov
Date: 2019-03-15T20:27:42.334Z

timbeiko:

Whether hard forks happen every 3, 6, or 9 months, the amount of developers working on clients is more or less constant and if more time is spent implementing/testing/deploying EIPs


So far it looks to me that the actual time spent on implementing EIPs in the clients is not that large - especially if EIPs are well-prepared. It is only when EIPs are not well specified, missing tests, there are more iterations to figure things out. As much work as possible needs to be done pre-EIP, so that the client implementers aren’t the bottleneck - and I don’t think they usually are.

Author: xazax310
Date: 2019-03-18T12:48:55.785Z

I think the problem with more frequent HF could be more problems if something like EIP1283 happens again. A 3 month schedule is tight one to make, should something happen, that will then cascade down and possibly delay the rest. I know I may be the only one arguing for this, but I think one year release schedule where EIPs are chosen the previous year Audited, tested though-out the year on testnet etc then implemented at a set date/time/month every year.
This gives ample time for bugs to be found. Processes to be improved and allows Pools and Exchanges the “HF” date every year to be prepared and ready to upgrade.

Author: timbeiko
Date: 2019-03-18T13:26:09.323Z

Thanks for your comment! Is it fair to rephrase this comment:

I think the problem with more frequent HF could be more problems if something like EIP1283 happens again. A 3 month schedule is tight one to make, should something happen, that will then cascade down and possibly delay the rest.

as "Increases risk that bugs found in HF x cause delay in HF x+1 ?
If that is fine with you, @xazax310, I can add it to the list in the original post.
Similarly, can I rephrase this:

Audited, tested though-out the year on testnet etc then implemented at a set date/time/month every year.
This gives ample time for bugs to be found. Processes to be improved and allows Pools and Exchanges the “HF” date every year to be prepared and ready to upgrade.

as “Allows ample time for security evaluation” ? The rest of your concern seems already captured by " * There is a coordination cost to each HF, so more frequent ones involve more coordination work across major stakeholders running clients (e.g. miners, exchanges, block explorers, etc.);", but let me know if it isn’t.

Author: xazax310
Date: 2019-03-18T13:39:05.812Z

as “Allows ample time for security evaluation” ? The rest of your concern seems already captured by " * There is a coordination cost to each HF, so more frequent ones involve more coordination work across major stakeholders running clients (e.g. miners, exchanges, block explorers, etc.);", but let me know if it isn’t.

Yeah, that seems right in line with what I’m thinking.

as "Increases risk that bugs found in  HF x  cause delay in  HF x+1  ?

Math has never been my favorite subject  so that works for me.

Author: timbeiko
Date: 2019-03-18T14:04:08.893Z

No worries. I meant that this increases the risk that a bug found in a planned hard fork delays the next one. I will rephrase in a less math-y way in the original post.

Author: AlexeyAkhunov
Date: 2019-03-18T14:24:08.090Z

xazax310:

I think the problem with more frequent HF could be more problems if something like EIP1283 happens again. A 3 month schedule is tight one to make, should something happen, that will then cascade down and possibly delay the rest. I know I may be the only one arguing for this, but I think one year release schedule where EIPs are chosen the previous year Audited, tested though-out the year on testnet etc then implemented at a set date/time/month every year.


It is my current intuition that unless we make serious improvements in the way the EIPs are put it, there is little hope that Ethereum 1x will deliver what it is supposed to. The current rate of change seems too slow to accommodate the crucial fixes + all the other stuff the people are now proposing since it looks like “the gates are open once again”. I guess it will become very clear in a few months

Author: xazax310
Date: 2019-03-18T15:36:57.396Z

It is my current intuition that unless we make serious improvements in the way the EIPs are put it, there is little hope that Ethereum 1x will deliver what it is supposed to.

That’s how I’m seeing it too. Is it the EIP process that needs to be reviewed in addition to HF times? I know it sounds unintuitive but would a Committee on EIPs resolve any of those issues? Such as Security concerns, release times, inclusions or exclusions due to security concerns.
[ WIP ] -> [ DRAFT ] -> [ LAST CALL ] -> [ ACCEPTED ] -> [ FINAL ]

[ WIP ] -> [ DRAFT ] -> [ LAST CALL/REVIEWED ] -> [COMMITTEE  ACCEPTED] -> [PLANNED INCLUSION OF HF SCHEDULED DATE]-> [ FINAL ]

I’ll post it here since it relevant but to me looks like another topic for discussion.

Author: lrettig
Date: 2019-03-18T20:41:43.212Z

AlexeyAkhunov:

It is my current intuition that unless we make serious improvements in the way the EIPs are put it, there is little hope that Ethereum 1x will deliver what it is supposed to. The current rate of change seems too slow to accommodate the crucial fixes + all the other stuff the people are now proposing


Seconded, this is my concern and my fear as well. Combined with Higher standards for EIPs, I think we have the beginnings of what needs to be done to improve the EIP process and increase the pace of innovation.
I think testing is definitely one bottleneck in the existing process and we should discuss how to improve throughput - I think a “layered pipeline” approach as discussed here would make sense. Does the testing team have sufficient resources today? CC @holiman (I don’t see Dimitry here)
Another thought to consider: instead of a waterfall approach, would a leaner approach with multiple “sprints” maybe make sense here? It seems like Afri’s proposal, which we’ve been working with for Istanbul, works this way - we’re pursuing multiple EIPs at the same time, with hard deadlines for EIP submission, implementations, testing, etc. and whatever makes it into the next upgrade goes in, whatever doesn’t must wait until the following one.

Author: timbeiko
Date: 2019-03-18T22:02:32.057Z

lrettig:

Another thought to consider: instead of a waterfall approach, would a leaner approach with multiple “sprints” maybe make sense here?


I think we get this from having planned HFs in advance, regardless of the size  At this point, we’re mostly debating the length of the sprint

Author: holiman
Date: 2019-03-29T12:23:32.464Z

lrettig:

I think testing is definitely one bottleneck in the existing process and we should discuss how to improve throughput - I think a “layered pipeline” approach as discussed here would make sense. Does the testing team have sufficient resources today? CC @holiman (I don’t see Dimitry here)


Sufficient resources - I’d say no on that. Testing is a bit thankless task, and what complicates the matter is that it both requires very solid knowledge of EVM internals and Ethereum in general, and it’s also much  case of not much happening, and then suddenly there is tons of work to be done, as we finalize eips.
So from that respect, I think having a steadier flow of smaller eips would be a definite win. Then it wouldn’t be this case of coordinating testcases for N new features which may or may have internal interaction in odd ways.

Author: timbeiko
Date: 2019-03-29T13:15:59.148Z

Thanks for sharing! I’ve added this to the original post.

Author: timbeiko
Date: 2019-03-29T14:30:21.324Z

One thing that came up in the AllCoreDevs call today is that the this could potentially change before Istanbul. When and how should we get consensus on whether we want to change this?

Author: boris
Date: 2019-03-29T14:33:02.184Z

I think this should be an Informational EIP (of which we have very few). We can update 233 to say that dates are picked based on those guidelines. Let’s get it in and finalized @shemnon.

Author: lrettig
Date: 2019-03-29T15:07:16.422Z

On the all core devs call just now @holiman proposed an “EIP-centric” upgrade process rather than a hard-fork centric model like we have now. @AlexeyAkhunov also expressed concern about a deadline, like the May 17 Istanbul deadline, meaning that folks would have to rush their EIPs in before the deadline lest they “miss the boat” and have to wait 9 or 12 months until the next hard fork. I’m also concerned about people submitting half-baked “placeholder” EIPs before the deadline.
I like Martin’s idea a lot, especially in combination with smaller, more frequent hard forks. @shemnon’s proposal at https://github.com/shemnon/EIPs/blob/4e3069b4f9a30a639b142151dc6295f634712786/EIPS/eip-network_upgrade_windows.md looks reasonable to me.

Author: gcolvin
Date: 2019-04-12T15:12:29.420Z

Advantages to fast enough upgrade schedule:

If a feature isn’t ready on time it’s not a huge slip to wait for the next upgrade.
Upgrades happen too fast for the mob to get mobilized.
Discussion of EIPs gets pushed further back into the process where it belongs.
Upgrades may become as uneventful as Apple point releases.

Disadvantages:

Developers are testing more than developing.
The mob never stops screaming that they weren’t consulted.
More work and coordination for miners.

Author: gcolvin
Date: 2019-04-12T20:40:09.731Z

Testing is a thankless task for developers.  It’s a job that real testers like to do.



 holiman:

Testing is a bit thankless task

Author: gcolvin
Date: 2019-04-12T20:43:39.751Z

From AllCoreDevs:
Nick Sawinyh @sneg55 09:06

More work and coordination for miners.

It’s not a big deal actually for most of mining pools.
Peter Salanki @salanki 13:00
+1 on Nicks comment. Updating node software for mining pools is very painless. Takes 5 minutes for me
Greg Colvin @gcolvin 14:34
Then we are down to the mob, which I don’t care about, and the lack of testing resources.

Author: fubuloubu
Date: 2019-04-13T15:31:51.385Z

+1 Lack of testing resources.

Author: cdili
Date: 2019-04-20T09:34:28.746Z

Top developers and engineers know to own their code. They know that the engineering includes testability, including all the code for testing, keeping tests reliable, efficient, maintainable, extensible, etc.
Yes, other eyes and engineers are required for producing robust code, but the culture needs to be more on ownership rather than on other people/testers to find the bugs or security issues.
There are engineers that come from such cultures but usually they are very comfortable in their big company jobs.
I’m not writing this to argue but to clarify your points further. +1 to a lack of engineers on fronts like testing, security, performance…

Author: gcolvin
Date: 2019-04-21T06:23:16.295Z

cdili:

Top developers and engineers know to own their code. They know that the engineering includes testability, including all the code for testing, keeping tests reliable, efficient, maintainable, extensible,


Over the years I’ve seen many patterns on the relationship of development and testing.  But when I have worked with professional test engineers I’ve found that they are simply much better at it than I am, as you would expect.
When I have been sole owner and tester of my code I can do fine.  I spent three years writing one system that manifested only one bug in the next seven years in production.  But I’m more productive when I can concentrate my efforts where I am most skillful, and let test engineers concentrate their efforts where they are most skillful.
This is independent of big vs. small company.  The best test engineer I ever worked with was at a tiny startup.  But it’s true that no big company I worked at failed to have professional test engineers on staff.  Lots of them.
What’s been hardest here is maintaining ownership in an open-source environment that lets anybody on earth make PRs.

Author: shemnon
Date: 2019-04-22T05:04:30.112Z

So one of the questions at 1x Berlin related to the preferred cadence of 1.x network upgrades.  6 month vs 4 month was the point where consensus broke down.  As an advocate of 6 month the big advantage I see for client developer is that it will keep the clients focused to one upgrade at a time.  With a 4 or 3 month cadence there will start to be some overlap between the upgrades before they are “done.”
Here’s a chart I put together with some cheesy placeholder names for future upgrades that illustrates the overlap.  EIPs is the deadline for EIPs to be considered.  Clients is the client development soft deadline.  Testnet and Mainnet are respective hard fork dates.  These landmarks are presuming we keep the same Istanbul landmarks for future network upgrades.
6 month Cadence




Date
Istanbul
‘Asiago’
‘Brie’
‘Cheddar’




May 2019
EIPs





Jun 2019






Jul 2019
Clients
Kickoff




Aug 2019
Testnet





Sep 2019






Oct 2019
Mainnet





Nov 2019

EIPs




Dec 2019






Jan 2020

Clients
Kickoff



Feb 2020

Testnet




Mar 2020






Apr 2020

Mainnet




May 2020


EIPs



Jun 2020






Jul 2020


Clients
Kickoff


Aug 2020


Testnet



Sep 2020






Oct 2020


Mainnet



Nov 2020



EIPs


Dec 2020






Jan 2021



Clients


Feb 2021



Testnet


Mar 2021






Apr 2021



Mainnet



4 month Cadence




Date
Istanbul
‘Asiago’
‘Brie’
‘Cheddar’




May 2019
EIPs
Kickoff




Jun 2019






Jul 2019
Clients





Aug 2019
Testnet





Sep 2019

EIPs
Kickoff



Oct 2019
Mainnet





Nov 2019

Clients




Dec 2020

Testnet




Jan 2020


EIPs
Kickoff


Feb 2020

Mainnet




Mar 2020


Clients



Apr 2020


Testnet



May 2020



EIPs


Jun 2020


Mainnet



Jul 2020



Clients


Aug 2020



Testnet


Sep 2020






Oct 2020



Mainnet


Nov 2020







With a 4 month cadence we need to lock in EIPs prior to a successful launch of the previous upgrade.  And the hard fork window is the same time period where devs would need to work on client implementation for the next version.  If something goes bad on the pending upgrade the next upgrade will be severely impacted as well.
Because of this mainnet launch and next upgrade overlap that I think anything less than 6 months is a higher risk cadence than we should be looking to take on.

Author: AlexeyAkhunov
Date: 2019-04-22T10:04:14.289Z

shemnon:

With a 4 month cadence we need to lock in EIPs prior to a successful launch of the previous upgrade. And the hard fork window is the same time period where devs would need to work on client implementation for the next version. If something goes bad on the pending upgrade the next upgrade will be severely impacted as well.
Because of this mainnet launch and next upgrade overlap that I think anything less than 6 months is a higher risk cadence than we should be looking to take on.


Makes sense. Though I would say that most of this is based on the our “conventional” way of doing things, like:

Assumption that people working on the EIPs are the same people who are developing major clients - this does not need to be the case. Working Groups are the attempt to change that.
EIPs are often under-researched when they hit the roadmap, and there is a large uncertainty of their implementability (effectively EIP process is used as a research process). If EIPs are higher quality and properly researched and prototyped, the risk of them being thrown out and causing knock-on effect are lower
Test preparation is a fairly centralised process

Challenging these assumptions is something that would have benefits regardless of whether the cadence is increased. And therefore, it is something to strive for

Author: boris
Date: 2019-04-22T10:38:03.503Z

@shemnon thank you this is great! I still have to figure out how to pull this into a summary so we can gather everything — thanks for doing “homework”.
@AlexeyAkhunov I think we can move to a more continuous / faster cycle, it will take time for people & processes to adjust rather than time to get work done!
Essentially “kanban” where EIPs are pushed through to ready and then bundled into releases.

Author: shemnon
Date: 2019-04-27T19:49:21.964Z

To formalize what I said on AllCoreDevs on 26 April, for @AlexeyAkhunov’s point 1 if a fork goes poorly, like Constantinople did (with both testnet and mainnet problems) the same devs that would implement the change for the next network upgrade would be the same people fixing the problematic deployments of the previous network upgrade.  If things go well you are correct they will not be the same people working them.
If we get to a point where things are going smoothly at 6 months (both Istanbul and Asaigo) we can re-evaluate for 4 months (with Brie and Cheddar or Cheddar and Derby overlapping).  But both Byzantium and Constantinople were not what I would consider smooth.  Alexey’s points 2 and 3 are the indicators we will need to see to consider a 4 month cycle.
And to be clear, these cheesy names are placeholders until we get more formal ones.  But when talking about particular network upgrades in the future we need some mnemonic that implies monotonic order.

Author: shemnon
Date: 2019-05-21T22:45:22.492Z

A couple of things on my mind for Asaigo -

Create a new “EIPs Proposed” checkpoint two to three months after kickoff.  6-7 months before mainnet.
Change the “EIPs” Proposed checkpoint to “EIP ready.” 4 months after kickoff and 5 months before launch.

This new checkpoint will be when we close the door to new EIPs for the upgrade, rather than 5 months before upgrade it will be 6-7 months.  This will then give time to discuss and hash over the proposed EIPs for two to four all-core-devs calls.  Anything that gets kicked out of the previous upgrade (such as EIP-1283 was) would automatically be considered as proposed.
EIPs don’t need to be well formed, they just need to be communicated as proposed with some reasonable bounds.  Like “My fee market proposal as per my talk at Conference Y” or “State Fees steps W, X, and Z.”
The existing 5 months to go mark the EIPs proposed would need to be “ready” - i.e. someone would have been on ACD to champion the EIP, ACD had discussion on it on the call or in FEM (or some other appropriate forum) and the EIP would be in a condition it could go into last call, accepted, or final.  The idea being it is ready for client implementors to implement without concern for it being incomplete.
The 3 month (client implementations soft deadline) and 2 month (Testnet launch) checkpoints would remain the same.




Date
Istanbul
‘Asiago’
‘Brie’
‘Cheddar’




May 2019
EIPs





Jun 2019






Jul 2019
Clients
Kickoff




Aug 2019
Testnet





Sep 2019

Proposals




Oct 2019
Mainnet





Nov 2019

EIP Ready




Dec 2019






Jan 2020

Clients
Kickoff



Feb 2020

Testnet




Mar 2020


Proposals



Apr 2020

Mainnet




May 2020


EIP Ready



Jun 2020






Jul 2020


Clients
Kickoff


Aug 2020


Testnet



Sep 2020



Proposals


Oct 2020


Mainnet



Nov 2020



EIP Ready


Dec 2020






Jan 2021



Clients


Feb 2021



Testnet


Mar 2021






Apr 2021



Mainnet



Future cheesy placeholder names:
‘Danbo’ - Oct `21
‘Edam’ - Apr '22
‘Fetta’ - Oct '23
‘Gouda’ - Apr '23
‘Hoop’ - Oct '23
‘Infossato’ - Apr '24
This will get us 5 years out, which is what, two major bear markets?

Author: axic
Date: 2019-05-22T10:42:03.823Z

I suggest to use Devcon locations past Istanbul:

(devcon 0: berlin?)
devcon 1: london
devcon 2: shanghai
devcon 3: cancun
devcon 4: prague
devcon 5: osaka

After 2.5 (?) years that would mean we need to have more devcons or switching naming convention

Author: shemnon
Date: 2019-05-22T18:36:08.192Z

There was a joke told at CoreDevsBerlin that we should auction off the naming rights.  I’m not convinced that is a bad idea.
a) Names must be flavorful and meaningful.  A proposal should include the meaning.  e.g. the “lima bean” upgrade would be rejected without some meaning.
b) Names cannot be the names of existing or known future projects or companies.  e.g. the “Ethereum Foundation”, “Parity”, and “PegaSys” upgrades would not be valid names.
c) The name should be relatively benign and non-controversial.  I would give examples of objectionable names but I’m pretty sure we all can think of some.
Why auction?  The funds could be used for paying for AllCoreDevs meeting venue fees and catering/paying for 1-6 meals during these meetings.

Author: boris
Date: 2019-05-22T18:51:42.149Z

Hey @axic – @shemnon very much means these names as bad placeholders. We don’t need to pick the real ones until a meta EIP is filed.

Author: jpitts
Date: 2019-05-23T19:36:10.351Z

As a suggestion to reduce confusion, we should use protocol version numbers with “Unnamed” or “TBD” if we don’t yet have one, and still keep the version number once we know the names.
v8 - Istanbul
v9 - TBD
v10 - TBD

Author: axic
Date: 2019-05-23T23:32:53.914Z

shemnon:

There was a joke told at CoreDevsBerlin that we should auction off the naming rights. I’m not convinced that is a bad idea.


If you restrict what can be a name severely, then who would sponsor a generic random name? I’m not convinced it is a useful idea.



 boris:

very much means these names as bad placeholders.


That’s fine but the longer people refer to them, the more likely they are going to be sticky. Who wants sticky cheese? 



 boris:

We don’t need to pick the real ones until a meta EIP is filed.


I was actually going to file one to get started and not leave submissions/reviews to the deadline (as with Istanbul).

Author: shemnon
Date: 2019-05-24T01:51:03.663Z

axic:

If you restrict what can be a name severely, then who would sponsor a generic random name? I’m not convinced it is a useful idea.


I would want to avoid to avoid stuff like the “Sony Playstation 5” upgrade or a hate-speech derived fork name.



 axic:

That’s fine but the longer people refer to them, the more likely they are going to be sticky. Who wants sticky cheese? 


You will notice the alphabetical progression, that’s more important than the cheesy theme for the placeholders.  We could call it the “a” upgrade as a placeholder, but the state rent proposal already has the letter space taken.



 axic:

I was actually going to file one to get started and not leave submissions/reviews to the deadline (as with Istanbul).


I was hoping we could wait until the kickoff checkpoint for the next meta so we are only juggling one mutable network upgrade document at a time.  It also (currently) lines up with the client implementation checkpoint so stuff can easily move from one list to the next.

Author: axic
Date: 2019-05-24T14:12:45.068Z

shemnon:

I was hoping we could wait until the kickoff checkpoint for the next meta so we are only juggling one mutable network upgrade document at a time.


Too late: Add hardfork meta after Istanbul (Berlin) by axic · Pull Request #2070 · ethereum/EIPs · GitHub

Author: shemnon
Date: 2019-06-03T14:49:08.934Z

I’m thinking that perhaps we should just use numbers for future network upgrades, instead of names.  That should paint the bike shed once and for all.  This aligns with EIP-1846 that wants to move the reference tests away from names and towards numbers upgrades.
So ‘asiago’ would formally be ETH-009-00, and informally ‘version 9’, ‘brie’ would be ETH-010-00 and informally ‘version 10’, and so on.

Author: timbeiko
Date: 2019-07-26T16:21:00.404Z

Cross-linking this for context based on today’s AllCoreDevs call:
https://twitter.com/TimBeiko/status/1154785971067609088
TL;DR:

Istanbul testnet upgrades on Sept 4th vs. Aug 14th
Istanbul may be split in two upgrades
We need to agree on what makes sense for the next fork after that

Author: axic
Date: 2019-08-11T14:55:15.805Z

axic:

I suggest to use Devcon locations past Istanbul:


Proposed this forACD#68.

Author: axic
Date: 2019-08-11T15:16:13.188Z

I like the pun on “cheesy hardfork names”, but agreeing on cheese names for forks just shouts bike shedding.

Author: timbeiko
Date: 2019-08-12T13:37:00.477Z

I think this is a good idea.
My personal preference would be to auction off the name, and I have a few ideas for it, but realistically this will take a while to get consensus on, and subsequently implement. Devcon locations is non-contentious, and could easily be made a default in case another scheme failed (i.e. an auction with no bidders).

Author: shemnon
Date: 2019-08-12T17:15:08.940Z

Starting with the January upgrade I really do think we should split the internal names from the external names.
Internally we should use something very simple and derivative, like numbers. Natural numbers without multiple layers of decimals and rule about compatibility.  Specifically the number of forks (or attempted forks) since the beginning, like we number our blocks.
By internally I mean stuff like reference tests, genesis file flags, etc.  This way we don’t require people working on the code to keep mental models of where devcon was, what cities were at the entrance to the black sea, what cheese starts with the letter ‘E’, etc.  The code and ordering then are obvious when deciding if ETH09ForkBlock comes before ETH10ForkBlock without having to remember if devs met in Berlin before they met in London.
This sequential fork number would be set in the meta-eip when the first testnet fork is set.  This provides a hedge against emergency forks like occurred with the shanghai attacks to help ensure natural fork number ordering.  Perhaps we could re-edit the other meta-eips to add their associated fork numbers as part of this.
We can still use marketing designations as part of the fork block, but these don’t live in symbols in the code and don’t require lines in testing docs reminding test developers what the order of the blocks is.  We can put the name in a comment next to the block table in our code, and use the friendlier marketing name in blog posts, twitter updates, conference talks, and other such collateral.  But where the number meets the road it is simply a fork number.  A sysadmin adage I heard that applies is “Name your pets, but number your herd.”