# EIP-centric forking This is my (@holiman) proposal for how we should handle forks (technical upgrades) to the Ethereum Mainnet. ## Background Ethereum has, for the last couple of forks, based the forks on 1. Set a time where a fork will occur 2. Decide on which EIPs make it into fork 3. Take a lot of time to actually make the decisions 4. Possibly postpone the fork, and possibly remove or add EIPs There's an inherent race condition here; people want EIPs to go in, since the next upgrade might be a long way off. On the other hand, pushing EIPs in further increases the delays, and increases the 'penalty' for EIPs that misses the fork-slot. ## EIP-centric model In the "EIP-centric" model, there would be some milestones. ### Step 1: Get ACD blessing Presuming that an EIP exists (step 0), the Allcoredev would officially decide on whether the EIP is "Initially Accepted". "Initially Accepted" (or, 'blessed') means that ACD, representing the major clients _and_ ecosystem stakeholders etc: * Are positive towards the EIP, * Would accept (well written) PRs to include the EIP into the codebase. * So that it could be toggled on for testing... * ...but not with an actual block number for activation ### Step 2: Implementations Once ACD has given the go-ahead, developers and/or eip-authors implements it and makes PRs against the clients. If implementations are _merged_ into major clients, this milestone is complete. ### Step 3: Test cases Since the feature is now 'activateable' within the clients, it's now possible to produce cross-client testcases for the feature. The testcases should contain - Happy-path tests, - Quirk/edgecase tests, This step should be performed in conjunction with many people that have in-depth knowledge not only about the EIP, but also the EVM in general, to get maximum coverage on what should be considered edgecases. At this point, a security review should be done, and the review items should be fed back into the EIP, under "Security Considerations". The review should also focus on finding edgecases for testing. This milestone is completed once the test-team considers the tests to be complete. ### Step 4: ACD final acceptance. At this point, the ACD can again take the EIP up for discussion. * Evaluate the EIP, the implementations, side-effects, testcases etc. If everything appears to be in order, the ACD can simply decide when to activate the EIP. For example, the ACD could say > "Yes, let's activate this EIP on testnet in one month (at block X), and on Mainnet two months from now (at block Y)". All clients will contain the upgrade at next release, within one week from now, and also functionality to postpone the EIP via command-line flag. > If it should happen that multiple EIPs reach Step 4 simultaneously, the ACD might decide to roll two or three out simultaneously -- unless there are concerns that the EIPs might have internal dependencies/couplings which might interfere (or cause additional edgecases for testing). ## Benefits As I see it, the benefits are - No need for endless discussions on ACD about what to include when, and whether to postpone to get something in or cut something out, - More stable / predictable work for the testing team, with smaller hardforks more spread out over time, - EIP authors can focus on their tests, their implementations, but can take their time and do not have to work against a deadline arbitrarily set by the ACD /Martin Holst Swende 2019-08-08