Clarify mainnet upgrade date requirement #1780
Conversation
| ### Mainnet | ||
|
|
||
| - Mainnet should not have an upgrade date set until all testnets have been upgraded. | ||
| - Mainnet should not have an upgrade date set until at least one testnet has been upgraded. |
There was a problem hiding this comment.
I think this is reasonable. My 2c from a client dev perspective:
Things can always go wrong - we could set hard requirements and be more conservative (e.g. wait at least a week after all testnets have upgraded) and delay shipping even if the failure rate is extremely low; But I see more benefit in being optimistic and focusing on improving our testing process to reduce the failure rates. (which I believe we’re constantly getting better at!)
In my opinion, doing more devnet iterations with clear goals until things are robust is much more meaningful than having a hard requirement to wait for all testnets to upgrade.
There was a problem hiding this comment.
On the other hand, hooli and sepolia serve different purposes and are targeting different user groups - and we could discover different things on the two devnets that could potentially impact our mainnet timeline.
There was a problem hiding this comment.
For process, I don't mind us being able to plan ahead and to have an upgrade epoch we are targeting. However, from a client implementer prospective, I don't think I would include any mainnet fork configuration parameters in any release until all the testnets have forked successfully.
There was a problem hiding this comment.
This isn't meant to decide when a client puts the dates into their releases. I don't think we should decide that for the client teams here.
There was a problem hiding this comment.
Mainnet must not upgrade less than 30 days after the final testnet has been verified to have been successfully upgraded.
this point effectively means you should not make a client release containing the mainnet release fork date until the final testnet has been deemed "successfully upgrade" (a condition for which we don't have criteria, beyond "looks good")
There was a problem hiding this comment.
I think that should be up to the client team's decision when they wanna make a client release.
The point here is to have the public know more in advance when to expect the mainnet fork, not just one month before it happens but ideally up to 2mo in advance.
There was a problem hiding this comment.
I think that should be up to the client team's decision
It has been a community expectation that between hard forks, you should be free to run whatever version of whatever client you want and it should "just work" - releasing a client version that is out before the criteria for the hard fork are fulfilled seems to go against that principle. True, it could happen due to some security issue discovered late that we recall a release, but I don't think it's something we should encourage as an "ordinary" thing to expect - ie "hard fork is ready to ship, let's upgrade the nodes" is a simple message. "hardfork is mostly ready, maybe upgrade your clients" is a mess.
Pursuant to this, I would call any date announced before the two test nets transition as "tentative" or "conditional" - one simple reason for this is that if during the transition a security issue is discovered (say an EIP introduces some repricing etc), it might lead to the hard fork contents changing.
There was a problem hiding this comment.
I'm against this change. We can (and in Fusaka's case have) propose a target date. but it shouldn't be confirmed until all testnets have been upgraded.
Though even with a proposed date, if there is an issue which requires more time, then we should be prepared that the wider world will see this as core devs delaying an upgrade.
5 participants
No description provided.