Skip to content

Clarify mainnet upgrade date requirement #1780

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Clarify mainnet upgrade date requirement #1780

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
831b5ea
Clarify mainnet upgrade date requirement
barnabasbusa Oct 23, 2025
348c2ea
Fix grammatical error in protocol-upgrade.md
barnabasbusa Oct 23, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion processes/protocol-upgrade.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ Ethereum has regular protocol upgrades that introduce performance, security and

### 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.
Copy link
Contributor

@jimmygchen jimmygchen Oct 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@jimmygchen jimmygchen Oct 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@philknows philknows Oct 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@barnabasbusa barnabasbusa Oct 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@arnetheduck arnetheduck Oct 24, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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")

Copy link
Member Author

@barnabasbusa barnabasbusa Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@arnetheduck arnetheduck Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@abcoathup abcoathup Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- The upgrade must have gone through at least two testnets.
- Mainnet must not upgrade less than 30 days after the final testnet has been verified to have been successfully upgraded. This is to ensure enough time has been given to test and spot potential issues before going live on mainnet and to allow for downstream projects to plan their upgrades. L2s need time to produce DAO proposals, organize their own upgrades, etc.

Expand Down