Apologies in advance for the long post!
- I propose we have fixed deadlines for when we stop considering EIPs for specific upgrades.
- I think we should try and agree on the “large items” for each of the coming network upgrades, even if subject to change, so that we can have better visibility over the general roadmap.
- I share some thoughts about the “best practices” we’ve seen groups pushing larger initiatives for Ethereum take.
On ACD117, we had a discussion about how to improve network upgrade planning and longer-term roadmapping for Ethereum. A few core issues were highlighted:
- A lot of things need to be done on Ethereum in the next 18-36 months;
- Our current process tends to bias towards smaller changes, but a lot of the most important work we need to do is larger (e.g. The Merge, State Expiry, etc.);
- For client teams, working on network upgrades means putting maintenance of the client aside for a while;
- For EIP champions, not knowing when upgrades will happen causes a lot of uncertainty and pressure to get an EIP included in the next upgrade.
There were also a few things that most people seemed in agreement about:
- Client teams can likely handle 2 upgrades per year, but not more;
- There is value in having things scheduled farther out in the future and when things try to get added in the current upgrade, it causes a lot of stress and delays;
- In many cases, testing is the biggest bottleneck, rather than client implementations.
Finally, there was some conversation about how upgrade coordination would work post-Merge. For simplicity, this is out of scope for this document.
If we target ~2 upgrades per year, it means each will happen at a roughly 6 month interval. It is also worth noting that towards the end of an upgrade (e.g. after the testnet releases are set), there is typically some bandwidth to start considering things for the next upgrade. Let’s use T for the time at which an upgrade gets activated on mainnet.
Roughly six months before an upgrade is scheduled to go onto mainnet, nothing can be “Considered for Inclusion” for it anymore. Any “new idea” since then automatically gets CFI’d for at least the next upgrade.
Roughly five months before the upgrade goes live on mainnet, devnets should be started with all CFI’d EIPs for this upgrade.
At this point, EIP champions should be actively contributing to test coverage for their EIP. Insufficient testing can be used as a blocker for an EIP to go from Client Integration Testnets to being formally included in the network upgrade.
Roughly three months before the upgrade goes live on mainnet, a final list of EIPs for the upgrade has been agreed upon and implemented in all clients, along with a testnet activation block, with the goal of choosing a mainnet block after successful testnet upgrades.
The upgrade goes live across the major public testnets.
Roughly one month before the upgrade goes live on mainnet, a block is chosen and clients are released with activation scheduled for this block.
One comment raised on ACD117 was that we should “open” upgrades earlier in order to provide better visibility to EIP champions. Here is an initial proposal:
- Needed because of difficulty bomb pushback in EIP-3554
- “CFI open”: ???
- T-6 “CFI closed” mark: June 1
- Special case because this process is new. Worth talking with client teams about EIPs already proposed to gauge interest and impact on Merge work.
- List of changes available here. Unlikely to include anything else given the large scope.
- “CFI open”: now - T-6.
- T-6 “CFI closed” mark: shortly after mainnet-compatible Merge releases by clients are out.
- Large initiatives to consider: Beacon Chain ETH Withdrawals, State Expirty “Stepping Stones” (Verkle Tries, Address Space Extension)
- EIPs to consider: EIPs excluded from Shanghai
Note: first post-Merge upgrade, will need to be coordinated with the Consensus layer because of withdrawals.
- CFI open: shortly after mainnet-compatible Merge releases by clients are out.
- T-6 “CFI closed” mark: when Cancun mainnet-compatible client releases are out.
- Large initatives to consider: State Expiry
Changes which affect multiple components of the Ethereum network tend to require a larger, more structured effort to make progress, gain community acceptance, and eventually get deployed to mainnet. These can be thought of as working groups.
Typically, these working groups end up doing/producing the following, usually over 6-18 months:
- A specification of the change (EIP, or a set of EIPs);
- Prototypes of the change across >1 client implementation;
- Hosting calls between implementers and/or the community to discuss the change and progress made;
- Reaching out to relevant parts of the community to gather feedback, address objections, document support for the proposal;
- “Audit” the change, either with a formal audit or at least a thorough analysis of the impacts of the change on clients, users, infrastructure, etc.;
There currently is no official “playbook” for how to sucessfully project-manage these initiatives, but two that can be used as reference are the recent Fee Market Changes and the work around The Merge.
There is likely little value in overly formalizing how working groups should operate, but having examples (and potentially retrospectives on their success/failure) can be useful for future contributors.