This is a rewording of my comments during ACD last week. The problem isn’t the fork size, it’s that forks are bloated with EIPS that seem “small enough” that including them feels like it will not cause any delay in the fork. These claims are often taken at face value.
Core developers get very busy implementing EIPs that are completely unrelated to the big picture of the roadmap, but it feels like something is being done because yet another EIPS is included.
One can add as many committees and smaller decision groups as one wants, the problem will still be the same if there is no commitment to the overall roadmap, and if frivolous EIPs keep getting scheduled.
I agree with the Nethermind team, that there should be a much higher expectation on the quality of the testing and the specification of each EIP. This is exactly what we have tried to achieve with the verkle trees/stateless effort, and yet this has played against it: people realized how complex it was and preferred (putatively) smaller EIPs that felt like we something would ship fast.
There needs to be a way to commit to long term items on the roadmap as a way to signal that work doesn’t get wasted. In other words, we need commitment from core developers and especially the research team, that it is safe to work on extremely challenging and difficult forks. Without these guarantees:
- it’s impossible to plan and work in parallel - only the next fork is thought of while everything else is a “maybe”
- the amount of people willing to take the risk of working on extremely ambitious forks will decrease, as the costs to do so are high and the rewards non-existent.
This is not a question of decentralization: large, centralized companies run into the same kind of issues as they grow successful.
There’s no easy way to solve these issues, but the few steps below would be a good start:
- EIP champions should justify on ACD how an EIP advances the roadmap (or Increase the security of the network, obviously). That means EIP that are currently scheduled for Prague or Osaka.
- Don’t change the road map because twitter panics. Any change to the roadmap should be a month-long process involving many stakeholders, probably during an interop or a major conference.
- Improve communication between research and core devs. The latest example is inclusion lists (and quantum resistance a close second). While these topics do need to be researched, they have been pushed onto the core development agenda way too early, caused a lot of confusion and had a negative impact on the timelines as teams worked on building them before realizing the idea wasn’t ready for its prime.
- Commit to forks long-term. This doesn’t mean that any change should be slated for a specific fork ahead of time. This means there needs to be tracks, and if the output of any of these tracks is ready (i.e. devnets running and execution specs written) then they should be shipped in the next fork. We can have 4 forks a year with this (or 0, which means teams are working on adding value to the protocol, and that’s fine).