Draftnet Driven Deployment

# Draftnet Driven Deployment This document attempts to formalize a pattern that has evolved over the past few Ethereum Hard forks (Paris to Prague): a devnet driven deployment pipeline. The devnets for these forks have served as development checkpoints to validate interoperability as well as to shake down design decisions to ensure there are no unintended interactions. This document outlines a framework, mostly describing current practices, aimed at increasing the velocity at which forks can be shipped without unduly restricting EIP development. It will also preserve the flexibility to ship critical features in a short time frame. The largest change is to introduce the notion of a draftnet. A draftnet is a devnet that serves as a "draft" of a possible mainnet fork that could be promoted to as a final fork with minimal work. ACD would handle two classes of draftnets: a draftnet that aggregate smaller and headliner changes (much like current fork devnets) and a series of single-feature draftnets for larger standalone features. Mainnet would create forks off of either of these classes of draftnets. ## Prior Art ### The Mythical Man-month [A set of essays from 1975](https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf) whose central theme is that adding manpower to a software project that is behind schedule delays it even longer. Also, important is the chapter on code freezes, where at some point new features need to stop, the code needs to be shipped, and new features are deferred to the next version. ### Extreme programming [Extreme Programming](http://www.extremeprogramming.org/) is one of the primordial Agile methodologies. One of their many cafeteria-style tenets is "Working Software." The core of the tenet is that software is always maintained in a state that it is always functional and could be released, if desired. In particular, you are not bound to wait for future features. > We can stop when ever we think we have done enough or a higher priority projects \[sic\] comes along. \[[Agile Software Development: A gentle introduction](http://www.agile-process.org/working.html)] ## On EIP Sizes First, it will be useful to establish a taxonomy of sizes for EIPs/Features that go in a fork. Sizes are the easiest to grasp (small/medium/large) where the size is the measure of the impact, not the technical effort. ### Small Small changes are changes that, in and of themselves, **would not justify a fork**. These changes are meant to accompany other, larger features. An aggregation multiple smaller changes _could_ justify a fork. #### Historic Examples * MCOPY opcode * Beacon Block Root in the EVM ### Medium Medium changes would, **in isolation, be worth the effort of pushing a fork**. This is typically the "headliner" of a fork. #### Historic Examples * EIP-4844 Blobs * EIP-1559 Fee Market * Any Difficulty Bomb Adjustment ### Large Large changes are changes that not only justify a fork, but for political and/or technical reasons **should occur in isolation**, away from other minor or major changes. #### Historic Examples * EIP-1057 ProgPOW (political isolation, never scheduled) * No technical isolation examples Note that while several difficulty bomb forks were the only feature in their fork they are not large. ### Huge Any fork that is appropriate to prefix with the article "The" is larger than the scope of this proposal. This is typically for merges that **require special coordination** and activation rules. There are currently no forks under serious consideration that would qualify as Huge. #### All Historic Examples * The DAO * The Merge  ## On Draftnets as Shippable Units Since The Merge/Paris Fork the Ethereum Core Developers has developed a practice of building a series of devnets prior to testnet activations. Each of these devnets would sometimes add features and would also revised the existing specifications of these releases. The final set of devnets focused just on tweaking the already added features. The fork specification was then finalized and rolled out to the persistent testnets, and then to mainnet. ### Draftnet to Mainnet Pipeline With a few minor tweaks this becomes a repeatable state machine. ```mermaid graph LR A((Development)) B((Release<br/>Candidate)) C(( Testnets )) D((( Mainnet  ))) style A fill:#000,color:#fff,width:100px style D fill:#000,stroke:#fff,stroke-width:4px,color:#fff subgraph G [Draftnet] A--📥📤 Add/Remove Features-->A A--🧊 Feature Freeze-->B B--💅 Update Specs-->B end B--🚢 Ship It-->C B--🫠 Unfreeze-->A C--🐛 Critical Bug-->B C--🚢 Ship It-->D ``` #### Testnet and Mainnet Process The progression outside of draftnets remains as-is: the fork rolls out to testnets and, barring any critical bugs, rolls out to mainnet. Client code may change, but the specification of the fork does not. #### Draftnet Process For draftnets, they are conceptually split into feature freeze and unfreeze states, each iterative draftnet is built when features are added and removed, or when the specification is refined. Two milestones need to occur, first there needs to be an explicit or implicit feature freeze. Then there needs to be a collective decision to schedule the current draftnet spec for testnets. The decision to freeze and ship could occur in the same draftnet, and even in the same moment. There are times, however, where it is valuable to say the next draft is only for polishing, hence the state separation. What this means is when a draftnet has completed (either settling to stable operation or otherwise producing useful findings) the core devs need to make a decision: ***ship*** or ***iterate***. If the core devs are set on delivering a particular headliner for the fork, and it isn't in this draftnet, then they must iterate. But there exists the option of shipping something else if they so choose and ship that headliner in the next release. ### Multiple Draftnets Within this structure it is possible to run multiple draftnets with multiple purposes, one could be for future standard forks and others can be for large feature forks. There is also the possibility of running draftnets that will never reach testnet or mainnet, but those are really just devnets. #### Future Fork Draftnets It may be desirable to run a draftnet for the fork just past the current fork. For this to be effective _the current draftnet would need to be in feature freeze_ with no expectation it would thaw into general development. This allows the fork under development to fine tune its spec while allowing future development to progress. #### Large Feature Draftnets The other useful category is for features that would be considered large features that would ship in isolation. The large feature draftnet would need to be based off of either _the mainnet hard fork_, or the _hardfork progressing through the testnets_. Large draftnets based off of anything other than the current fork cannot be proposed for mainnet deployment until they rebase to the current shipping mainnet/testnet specification. Having a separate draftnet that could ship in lieu of the current draftnet allows for decisions about shipping the large feature to occur independent of pending draftnet work. Such forks would be able to ship sooner, shipping when they are ready without having to either ship the current fork or have debates about how to delay the current fork. The action from ACD would be to ship the large fork and rebase the current draftnet on the new large fork codebase. Here are two examples of how uncoupling large testnets from the small and medium testnets could work. A large feature testnet "Marseille" is in process and ACD has determined is ready to ship in Q1 of 2026. In that case the next Medium fork Amsterdam would not ship until much later 2026, as Marseille has taken priority.  ```mermaid gantt dateFormat YYYY-MM title Future Forks - Large Ships First axisFormat %yQ%q section SM Prague: active, Prague, 2024-03, 2025-03 Osaka: active, Osaka,2024-08,2025-09 Amsterdam: Amsterdam, 2025-03, 2026-09 Bogota: Bogota, 2025-09, 2027-03 section L Marseille: active, Marseille, 2024-03, 2026-03 ``` Alternately, if Marseille needed to do some late spec revisions based on new requirements, then Amsterdam could progress and ship in Q1 of 2026 and Marseille would ship in Q3 when the spec revisions are complete and tested. ```mermaid gantt dateFormat YYYY-MM title Future Forks - Large Ships Second axisFormat %yQ%q section SM Prague: active, Prague, 2024-03, 2025-03 Osaka: active, Osaka,2024-08,2025-09 Amsterdam: Amsterdam, 2025-03, 2026-03 Bogota: Bogota, 2025-09, 2027-03 section L Marseille: active, Marseille, 2024-03, 2026-09 ``` ## On Naming More often than not city names have been used for fork names. Variants include glaciers, stages of cities, and unrelated names for emergency patches. The city theme seems to be the most "sticky." ### Small and Medium Feature Forks Small and medium feature forks will continue to use the names of devcon and Devconnect event cities. DevConnect 2023 will require special handling, as we have already used the name of the city at the Bosporus Strait three times. ### Large Forks Two large forks have occurred. The first, the DAO fork, has never had any other notable name associated with it. The second, "The Merge," has internally been referred to in tests as the Paris fork, to honor the EthCC conference. To continue that honor it is proposed that future large forks be named after cities in France. It is unlikely to cause collision with Devcon/Devconnect and provides a rich thematic list to chose from. Alternately cities with large annual Ethereum conferences that have not had a named fork could be chosen, but that is a smaller set than the number of cities in France. (Is it just Denver? Or do we include any conference that used the name Eth\<City\>) ### Emergency Forks If we need an emergency fork it is proposed that a two word nonsense name be chosen, to be consistent with the forks around the Shanghai attacks. ### Retire Glacier Fork Names Since we will never be adjusting the difficulty bomb, the glacier fork names are formally retired. ## On Frequency of Draftnets :shrug: There are a number of open questions about frequency. * Do we start a rhythm of monthly draftnets? * Is the small/medium draftnet always open? * On occasion focus exclusively on a large draftnet? * Who has final say as to what enters/leaves each draft? ## History 0.0.0 - Initial Draft (23 Sep 2024) 0.0.1 - Devnet -> Draftnet (25 Sep 2024) 0.0.2 - EthMag post, updated gannt charts (28 Jan 2026)