Devs and Centralization


#1

I keep on having nagging thoughts about devs and bottlenecks in decentralization. I’d like to try to explore them here.

I consistently hear an argument that dev teams are not a threat to centralization. If a dev would try to push bad code (let’s define that as malicious and/or centralizing), then it would not be ratified. If a team pushed bad code, or someone with merge rights was compromised, then the public would reroute to other available software. The concept of having numerous clients to maximize the ability for the public to be able to accomplish this is a truly amazing accomplishment in Ethereum, by the way. If geth becomes evil, then there’s Parity. If it’s Parity, then there’s geth. If it’s both, then there are still other options. That’s the general argument, if I’m not mistaken.

Here are my reservations: Code bases are getting longer and longer, and more and more complex. How many lines in geth or Parity’s client? What about when sharding, Plasma, and PoS are all added? As the code bases grow, I would only assume that people with push rights increase. Not just that, as code bases get longer and more complex, I would assume more sub-specializing will occur. I wouldn’t be surprised to see a group in charge of handling sharding, another for networking, etc. I would also assume that people individually having a grasp of what is going on in the entire codebase will be fewer and farther in between, not that they are in any way common now.

I’d like to digress for a moment. I’m paraphrasing and modifying some ideas that I’ve seen in Taleb’s Skin in the Game. The practitioners and regulators of any field will always be a minority. As jobs and fields become more specialized, only a minority of people have the requisite knowledge and skills to properly contribute. This is necessary if we are to maximize progress: all fields must more or less be controlled by small groups of people. This isn’t tyranny. This is necessary if we would like to allow progress in highly specialized ways. Not everyone can understand how to get rockets to Mars, which means not everyone should be part of the process.

A part of this is delegation. We don’t necessarily have in depth medical/pharmaceutical knowledge, so we delegate our trust out. We may have opinions on specific issues, but we are probably clueless that numerous critical issues exist. Naturally, we delegate to trusted bodies, be they government bodies or otherwise.
Coding is no different. If anything, I think one of the underappreciated aspects of Vitalik is that he has a good grasp of the entire protocol, including any 2.0-related stuff, at least as far as I can tell. But that also means that as time progresses, less and less people will understand what’s going on in the code. (I’m not an expert in the world of Linux, but I wonder if Linus really knows what’s going on in the entire kernel. Perhaps. I also wonder if Ethereum can possibly stay as small as the Linux kernel.) This is not inherently a bad thing. It does, however, mean that people will have to delegate their trust to other bodies more and more. As this happens, I do believe that the chances of bad code go up.

I believe this also increases the angst about forking. One major theory is that a compromised protocol can be forked. At what point will non-technical, or even not sufficiently technical in the relevant matter fork? What kinds of echo chambers will be created supporting the various potential ecosystem? I believe that the power of defaults, UI, and social sciences, while being addressed, are undervalued in this subject. Especially the social sciences.

If we could fork a government, any current government, would we do it? That’s a question probably too hypothetical to be seriously answered. What would a forked government look like? But, if you would kindly bear with me for a minute, think about the massive infrastructure that would need to be maintained somehow, assistants, deputies, assistant deputies, liaisons to assistant deputies, etc. In addition, think about the power of branding/incumbents.

In something like the Linux kernel, as critical as it is, I don’t think the chances of bad code represent such a problem. A patch can be issued, and, in general, damage can be reverted. You can probably figure out where I’m going with this. Immutable, money, blah, blah, blah. There are more incentives to attack, and there is less capability to revert.

Bringing this back home, I think that the governance of contributions to codebases needs to be taken more seriously. Perhaps we’re not at a crisis point now, but as codebases increase, the threat surface will just get larger and larger. In my opinion, serious protocols for contributions to decentralized protocols, platforms, and programs need to be robust and in place before they are necessary.


#2

Thanks for this, I generally agree with the conclusion that governance of contributions to codebases needs to be taken seriously! Though I’m not sure I agree that it is not being taken seriously now – regardless it probably deserves more attention and documentation.


#3

I don’t think the problems that Ethereum faces wrt code governance and bad changes making their way into the code base are unique to Ethereum. Using Linux as an example, think about how many sensitive systems use Linux today, from Amazon and Google to banks and government data centers. Imagine if one vulnerability got into the code base that allowed an attacker to delete all the data on the server or ex-filtrate the data or something like that. It would be a million times worse than a bug in Ethereum just due to the scale of the problem (Ethereum is relatively isolated from critical systems today).

Now ask yourself what prevents that from happening to Linux, or what Linux users would do if something like that happened to their distro of choice. Even a project as complex as an Operating System like Linux today has at least a dozen healthy, vibrant, community-driven distributions to rely on as alternatives in case one “goes bad” and hundreds of reviewers that prevent such disastrous errors from happening in the first place (not saying it couldn’t or would never happen, but is just much less likely especially with the most popular distros).

I think as Ethereum becomes more integral to critical business processes, we will also see more independent dev teams watching and working on the code base, contributing more checks and balances to the governance and review of client upgrades. Yes, today upgrades are relatively centralized in their review and governance. But that’s because the ecosystem is small and there’s not much at stake aside from a lot of speculative value and a few mainnet dapps (also mostly used for testing purposes today). As the ecosystem matures and more businesses start relying on the protocol for critical processes you will see more resources dedicated to independent development and review contributions, as we see with Linux and other mature FOSS projects.

That’s my two satoshis on the matter anyways!


#4

I think the conversation is being brought up, by I generally hear some of the prominent voices saying that dev centralization is not an issue. I drew some inspiration as a response to Vitalik saying in Zug recently (TechCrunch blockchain conference) that if he were forced to incorporate bad code, it wouldn’t fly, since the community wouldn’t use it. I’m largely writing against that assumption. If I’m interpreting them correctly, both Vlad Zamfir and Nick Johnson also seem to be saying that dev centralization isn’t such an issue. To emphasize, I don’t think any of them are saying that it totally isn’t an issue, but I do think they’re saying that it’s not such a big issue.

This would only be true if teams are watching other teams’ code on the same protocols, and even then I’m not sure how much it would help. If later today one client team would start saying that there’s bad code in a different client, it would simply make a perfect storm, in my opinion. There would be pandemonium and chaos, but not necessarily a decisive conclusion. Put more technically, since we can posit that a client team wants adoption, they have an incentive to lower adoption of competing clients, both in order to occupy a larger percentage of the domain, and to tap users from a ‘competing’ client. As such, I believe that this lends an immediate lack of credibility to a competitor. Surely competent audits will follow from more neutral parties, but I suspect a certain level of polarization if either client is relatively popular.

More than that, and this touches on the critical infrastructure point, I want to emphasize again that since Ethereum is a platform that maintains a decentralized currency, it is a very special kind of target. I would argue that it is intrinsically critical infrastructure, even now. There is a massive incentive to rob decentralized currency.

Gentoo had their GitHub compromised recently. (Here’s one report.) To be clear, this isn’t that someone found a vulnerability in the kernel, but rather they managed to get in to the GitHub and put bad code in the kernel. While I can hardly call this a definitive heuristic, let’s try to analyze data from distrowatch.com. Since their popularity ranking comes from logging one ‘vote’ per IP address per day per distro clicked on, I would expect either a massive spike (clicking because of the news) or crash (from fleeing) comparing the last month stats to the the 3 month/6 month/ year stats. Stats show a general decline from a year to 6 months to 3 months, and then a little gain in the last month. However, the numbers remain somewhat similar (between 201 and 236 hits a day).

tl;dr I respectfully disagree with this point. People stay with their defaults. (We hope they download patches, at least.)

I do agree that these are not Ethereum-specific problems. This is a community building on Ethereum, and I feel that governance discussion in the Ethereum space has been the most open, creative, and productive. (I don’t think that’s a coincidence, either.) Because of all of that, I frame things in an Ethereum frame here.

You guys are awesome, thanks for the responses!