With Shanghai/Capella’s scope finalized, focus has begun shifting to Cancun/Deneb. But, before we get too far in planning that upgrade, it’s important to take a step back and consider improvements to our process.
Ethereum has evolved a lot over the past year, on both the technical and human sides. We now have a single, unified network running both the Beacon Chain and execution layer, two sets of client teams who must coordinate with each other (as well as with client-adjacent contributors across R&D, devops, security, etc.) and a growing number of non-client teams championing Ethereum Improvement Proposals (EIPs) & contributing to protocol changes. And, of course, opinions by the broader Ethereum community about the direction of the protocol have grown both in quantity and quality.
In order for protocol developers, researchers, and the broader community to agree upon and deliver on Ethereum’s ambitious roadmap, good coordination is paramount. In this vein, I’d like to propose the introduction of Network Upgrade Meta Threads to help facilitate higher-level discussion about the overall scope of upgrades. Let me explain!
- I propose introducing Network Upgrade Meta Threads on Ethereum Magicians as a place for the community to discuss the best high-level scope/goals/size for network upgrades
- These threads, along with EIPs’
$UPGRADE-candidate(examples) threads, would serve as input for AllCoreDevs calls. This will hopefully improve the quality of our planning process
$UPGRADE-candidatethreads should serve as the canonical place to catalogue community support/objection to certain EIPs
- I propose we trial this process for Cancun/Deneb, and reevaluate after the upgrade whether it’s worth repeating
Today, the scope of network upgrades is decided upon during AllCoreDevs calls. Client developers consider various EIPs, debate their technical merits, and eventually arrive at a set of EIPs which they believe are technically sound, provide sufficient value relative to their complexity, and can be implemented together in a single network upgrade.
While this generally works well, there are some cases where it’s challenging for ACD to make a decision, let alone the optimal one, such as:
- When different community members have different preferences for EIPs, but there isn’t a strong technical reason in favour of one vs. another;
- When a proposed change is the “first step” towards a longer-term roadmap item, which may or may not change;
- When a set of candidate changes is too big for a single upgrade and must be spread out over multiple ones.
This is partially due to the nature of ACD, where the “units of concern” are EIPs. Most of the discussion on calls is about the technical merits of proposals, potential issues, how to best test them, etc. This is both good (we don’t want bad proposals to make it into an upgrade) and unsurprising (these domains are what most regular attendees are experts in).
When the discussion must move to a higher level, e.g. the relative prioritization of proposals, the opportunity costs of upgrade timing, etc., ACD calls don’t provide the ideal setting. Not only is this a big context switch from discussing technical tradeoffs, but these conversations often must happen quite rapidly (due to the time constraints on the call) and sometimes without all relevant stakeholders (given they may not be regular attendees).
That said, client developers are the ones who must ultimately write the code for these upgrades and hence must be core to the final decision about scope. This proposal hopes to provide a way to increase the quality of input into this decision-making process.
Today, network upgrades get planned roughly the following way:
- EIP author writes a Core EIP: someone writes an EIP with a proposed change to Ethereum’s consensus rules. Discussions about the EIP often happen on EthMagicians.
- Champion presents EIP on AllCoreDevs: an EIP champion, often the EIP author, comes on an AllCoreDevs call to present their EIP. In most cases, this leads to feedback from client teams and several rounds of iteration on the EIP.
- Champion requests EIP inclusion for upgrade: when an upgrade is being planned, the EIP champion signals that they would like their EIP to be considered. Since Shanghai, this process has migrated to EthMagicians.
- Client teams debate which EIPs should be considered: teams can come to either “weak” (“Considered for Inclusion”) or “strong” (“Included”) consensus on including the EIP.
- Prototyping/testing/etc.: as teams work on the candidate EIPs for an upgrade and gain a deeper understanding of their implications, the scope gets refined. As more implementations and testing suites are available, when issues come up, client teams can determine whether it is better to fix issues with an EIP or remove it in favour of shipping the other ones quicker.
- Testnet deployment: once teams are satisfied with their implementation and test coverage for a set of EIPs, those get bundled together for a test network upgrade.
- Mainnet deployment: assuming the testnet deployment goes smoothly, the upgrade is now scheduled for mainnet.
As mentioned earlier, this process is very centered around the EIPs themselves. While this isn’t a perfectly accurate illustration of how every fork was planned (e.g. The Merge was quite different), it’s a rough sketch of the process.
Network Upgrade Meta Threads
To provide both better input into the upgrade planning process as well as a formal venue for the broader community to voice their preferences, I believe we should introduce dedicated Ethereum Magicians thread focused on the “scope” and “size” of upgrades, rather than the technical details of EIPs.
These Network Upgrade Meta Threads would:
- Be created on EthMagicians when we begin planning a new upgrade (i.e. the Cancun one should probably already be up);
- Serve as a place to discuss topics such as:
- What should be the main priority/priorities for the upgrade;
- When, roughly, should we aim for the upgrade to happen, and the tradeoffs of including a marginal feature vs. delaying;
- How to split multi-upgrade features across >1 upgrade, and the implications of including a subset of those features in a specific upgrade;
- Be used as input into AllCoreDevs calls, but not serve as a venue for the final decision about upgrades’ scope. ACD would still be where the decision is made.
As with everything else on Ethereum Magicians, these threads would be open for all to share their views. The ACD151 agenda has good examples of comments which would be appropriate for such a thread:
Hopefully, by having such a thread open for weeks/months prior to finalizing an upgrade’s scope, rather than hours/days, we can improve the quality of our prioritization.
A note on
With the Shanghai upgrade, we trialed having EIP champions signal on Ethereum Magicians that they’d like their EIP considered for a network upgrade (proposal).
This was done by adding a
shanghai-candidate tag to either the EIP’s
discussion-to thread on Ethereum Magicians, or by opening a new thread to discuss the EIP’s inclusion in the fork, like for EIP-1153.
For EIPs where strong community support matters, this latter option can be a great way to catalogue support for and objections to the EIP, for which discussions can happen anywhere. Moving towards doing this in Ethereum Magicians threads can help avoid EIPs having to reinvent the wheel to document this information. A good forum templates for these posts could serve as an alternative to full blown EIP websites, such as eip4844.com.
Putting It All Together
With the introduction of Network Upgrade Meta Threads, the upgrade process would rely on the following components:
- EIPs: technical specifications for changes (coupled with executable specs)
discussion-tothreads: async discussion of technical EIP details
$UPGRADE-candidatetags/threads: async proposal to consider an EIP for an upgrade, cataloging support, objections, status updates, etc.
- Network Upgrade Meta Threads: async discussion of network upgrade scope/size/relative priorities
- AllCoreDevs calls: synchronous discussion of EIPs and network upgrades scope, relying on all the above as input
First, I’d like to get feedback both here and on AllCoreDevs about whether introducing these threads would be beneficial. Assuming this is the case, then I suggest we trial the process for Cancun and reevaluate afterwards.