Before Devcon, client teams held an R&D workshop with a session about process improvements for ACD, here are the notes.
Three concrete ACD process improvements emerged:
- Add a
Declined for Inclusionstatus to Network Upgrade Meta EIPs, allowing core devs to signal an EIP should not be included in the current fork (but could be considered for future forks). Draft PR: Update EIP-7723: Add "Declined for Inclusion" by timbeiko · Pull Request #9056 · ethereum/EIPs · GitHub - Include non-consensus changes in Meta EIPs, to signal their importance and give client teams a hard deadline for implementation.
- Note: this has already proven valuable with PeerDAS (a Networking EIP) being SFI’d for Fusaka. While it’s unclear where to explicitly formalize this, we should discuss whether to similarly “include” EIP-4444 in Pectra or Fusaka.
- Formalize the relationship between EIPs being added to devnets and the PFI → CFI → SFI statuses.
To expand on (3), there are currently two failure modes in our process: we risk committing to more EIPs than we can realistically implement, too early in the process or we risk including EIPs in network upgrades “just” because they are implemented.
+One solution could be to formalize the transition from CFI to SFI to mean “these EIPs will be included in the next fork devnet”. This would allow anyone to propose an EIP for inclusion, client devs can then “shortlist” EIPs in CFI, but the CFI → SFI transition would be bottlenecked by our actual devnet implementation capacity.
Additionally, we currently use “devnet” to mean two different things: the pre-testnet hard fork testing environment (e.g. pectra-devnet-x) and single EIP devnets for testing. We should consider having a clearer distinction between these two cases, either by using a different term than devnet for one of them, or by making it more explicit that $FORKNAME-devnet-x is qualitatively different from a “feature devnet”.