In today’s AllCoreDevs call there was discussion about potentially moving from large hard forks containing several EIPs to smaller ones with less (or potentially only a single) EIPs.
The goal of this thread is to start a discussion around the Pros and Cons of each approach. I’ll begin by listing a few, but I don’t feel like I have the full picture, so it would be valuable for others to chime in. Namely, @AlexeyAkhunov, as you had advocated for smaller hard forks in the past and brought it up again in today’s call .
I will keep editing the argument lists below as people comment on the thread.
Arguments for Smaller, More Frequent Hard Forks
- More frequent updates to the protocol;
- Can separate concerns better / isolate changes;
- Multi-hard-fork initiatives, such as State Rent, can drastically reduce their deployment time;
- “Unless we make serious improvements in the way the EIPs are put it, there is little hope that Ethereum 1x will deliver what it is supposed to.”
- Simplifies testing due to a more steady flow of less EIPs to test and less cross-EIP interactions to test.
Arguments for Larger, Less Frequent Hard Forks
- Less frequent need for users to update clients;
- There is a coordination cost to each HF, so more frequent ones involve more coordination work across major stakeholders running clients (e.g. miners, exchanges, block explorers, etc.);
- Allows ample time for security evaluation
- If hard forks are too close to each other, bugs found in a given hard fork may delay/push back subsequent hard forks
- Ad-hoc vs. fixed schedule for hard forks
- Smaller hard forks may result in multiple hard forks happening in parallel (where various forks are at different deployment stages)