I think the Paradigm Ethereum Acceleration post is totally correct that ACD is a bottleneck and that client developers should not be the primary decision-makers. I don’t think this is desirable for anyone, not even the client developers, who have too much responsibility and have to constantly make controversial and stressful decisions they shouldn’t have to.
I think the main issue with Ethereum development is that we’ve erroneously felt that “sufficiently decentralized” means that the process has to be an entirely organic process. Devops came about when people adapted industrial engineering concepts to the environment of the server. We should also be able to adapt principles from devops to design efficient processes which are nevertheless still decentralized.
We don’t even have to start from scratch. In my opinion, the development of Kubernetes provides a good starting point as an open source project which releases complicated yet robust software on a regular cadence, without any single party or person being in control.
I want to make three concrete suggestions:
- Have a fixed, regular release schedule and cadence.
- Formalize breakout rooms to be the primary venue for feature development, consideration, and prioritization.
- Replace ACD with a dedicated steering committee led by an elected release coordinator.
There is a industrial engineering principle which keeps being independently developed which is that when setup for a particular process is slow, it will always have delays. Because setup is slow, the tendency is to make the batches large so that the impact of setup time becomes less. However, the large number of changes results in added complexity which results in delays. This leads to a vicious cycle where more changes are piled on, resulting in more delays, because if you miss your chance there are no guarantees for when your change can get in. The solution to this is actually to make the batches smaller. Small and simple changes are less likely to cause delays, and the large setup time provides an incentive to dedicate resources towards automation. It must be regular so people know that missing the fork does not mean the end of the world. Kubernetes releases a new version every 15 weeks. I think Ethereum should be able to do something similar: perhaps something like 10 weeks for development into a code freeze with 5-10 weeks of testing (decreasing as testing infra gets better and more automated, and possibly overlapping with the start of development for the subsequent fork). There should be no delays: if a EIP isn’t ready for testing or fails testing, it gets dropped, you can bring it back when it’s ready. Nor should any single client failing to be ready hold up everyone else.
In Kubernetes, feature development is handled by what they call Special Interest Groups (SIGs). In my opinion, ACD has no business in deciding something like which of two blob changes should be prioritized in a fork. Instead, there should be a Data Availability SIG, consisting of both researchers and developers and which is open to the public to view and contribute to. Instead of EIPs being opened by a single person who then has to shepherd it into existence (or more likely, get completely burnt out), the SIGs should have their own separate forums for the purpose of research, consensus building, and development. Something like specifying an EIP should be done entirely within the relevant SIG. For each fork, the SIG should decide which specified EIPs they want to prioritize for each fork and work with client developers (who should also be members of relevant SIGs) to ensure that they make it in. Alternatively, dedicated groups like SIGs may find that they can deliver features without requiring a hard fork: it’s my opinion if there was a rollup SIG the ball would have started rolling much earlier with interop than it did.
This results in decision-making and planning being taken out of ACD, arguably rendering it unnecessary. The main thing left is coordination, which can still be done via a regular group call, but which is probably better done informally, through temporary committees, or by a dedicated team headed by a release coordinator. Decentralization can be added by having the release coordinators be elected or selected by sortition from valid candidates, starting by shadowing the current coordinator and then rotating into the role for the next fork.
These changes would remove the bottleneck that is ACD, separate planning from execution and allow them to happen in parallel, distribute power from client developers, add transparency and predictability to the fork process, and provide support to EIP owners and newbies entering the space.