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.
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.
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.
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
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.
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.
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.
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?
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.
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.
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…
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.
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.
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
so that works for me.