Reflections on Ethereum governance following the 3074 saga

Does “core dev” really have a well defined coherent meaning, or is it just some nebulous term we borrowed from Bitcoin, which doesn’t have a governance problem because it doesn’t have any governance. In Bitcoin the question of who calls themselves a core dev is inconsequential. If someone wants the honor fine, there’s no point in arguing with them about it because it doesn’t give them the power to change the rules of consensus.

Importing this uncritically to Ethereum may bake in some hidden unsafe assumptions that are worth examining. It’s possible that the status quo of client devs being a governance power would not make sense in a world where client development was more decentralized and diverse.

One could argue that client devs having special governance powers is a bug, not a feature. That ideally, they’d be equal participants in an emergent consensus process. That the only power they should have over changes to the networks rules of consensus is the power to make good arguments, just like everyone else participating in the process. The influence of all participants should be based on their ability to persuade others on the merit of their arguments, not on any special privileges they have over a particular repo.

Otherwise if “core devs” actually have governance powers, we have to think hard about who counts as a core dev. Consider what would happen if we had 3 forks of every client joining ACD calls? Is every dev that commits code to one of these repos a core dev? If we accepted that definition, it wouldn’t be too hard for an adversary to manufacture as many core devs as was needed to overwhelm the ACD process, especially if any actual voting is happening.

Sadly, there does seem to be some actual voting taking place in the inclusion calls.

Under the hood, Ethereum clients are just open source projects supported by various sources of public good funding. Having dedicated most of my life to open source projects, I understand how a developer can confuse stewardship with ownership. “What we’re given to administrate we frequently believe we own”, but Ethereum clients have been funded by the community and they belong to the community. It’s safer if developers that undermine the emergent consensus process have their legitimacy and funding transferred to other developers that don’t assert any special governance powers to settle disputes.

The simple fact is anyone can contribute to any repo or maintain a fork. You couldn’t formalize a credibly neutral governance process that gave client devs special powers because you’d be cornered into anointing some repos as the official canonical ones as soon as the absurdity of the design started getting exploited and too many clowns started showing up as core devs and demanding that their vote also be counted. It only makes sense if you don’t think about it too hard, or if there are never any important disagreements. If we are going to discuss governance, we should be intellectually honest and not sweep governance under the “core dev” rug.