The Ethereum developers have been rediscovering (but certainly not reinventing) software engineering. Under the benign dictatorship of Vitalik Buterin, Ethereum has struggled to maintain professional quality software without a conventional top down, closed organization. (See also this and this).
This month we read about their struggle with planning and scheduling “hard forks”-significant software updates that are incompatible with earlier code . In conventional software development, these are managed through a central distribution, and users must take the update or loose compatibility. In cryptoland, “hard forks” are “voted on”, and if a significant fraction of the network does not accept the change, the network splits. And there may be competing “forks” that address a problem in different ways. Sigh. This is no way to run a railroad.
While this approach is “disruptive”, at least in the sense of “less organized and much harder” than conventional software project management, But it hardly “reinvents” software development. Amazingly enough, all the hard problems of software maintenance are found in cryptocurrency software, and still have to be solved.
Crypotoland is already famous for its non-functional planning and decision-making. What changes should be made? More important, what changes must be made, versus might be made? What are the effects and implications of a proposed change? And so on. (See this and this and this.)
The “hard forks” problem is basically the difficult question of compatibility. Some changes are so drastic that you basically have to throw away all the old software and data—it’s effectively a whole new product. These changes are painful for users, and the more users you have—the more successful you are—the more difficult such upgrades become. There is too much sunk cost in the old software to blithely toss it out and redo it.
This is not just conservatism or laziness. As the Ethereum folks recognize, there are a lot of people using the software that simply do not have money, people, or expertise to port their stuff to a new version, let alone to do so over and over again. And if they do try to keep up, they may spend most of their time just chasing the releases, with no time for their own software or business. (Been there, done that.)
In the case of Ethereum, they also face a classic software dilemma. They are working on “Ethereum 2.0”, which is a pretty complete rework of the basic Ethereum protocol. In principle, everything will be wonderful in 2.0, but it will be quite a while before 2.0 is ready—it’s already a couple of years of discussions, and probably several more years before it might be done.
In the mean time, there are many changes that might be made to the current version of Ethereum core software. Some of these may be critical fixes, others are good ideas, and others are, well, who knows? But all these changes will be obsolete when the great day comes and Ethereum 2.0 comes out. (Although, some changes might be applicable to both old and new—so they have to be done twice.)
So just how frequent should these “hard forks” be? Too few, and the software may suffer. Too many, and downstream developers will be overwhelmed? And everything you do before V2.0 will essentially be thrown away.
Coindesk reports that the developers are discussing setting a regular schedule of forks, every six months, or even every three months. Of course, if history is a guide, they probably can’t hit such a target anyway, presumably because the process of testing and preparing (and, I hope, documenting) the code takes longer than hoped. (Definitely been there, done that.)
The ultimate kicker is that unlike conventional software, every one of these updates can be a political disaster, potentially causing a schism in the network, with untold consequences for users. Software maintenance is hard enough without having to have to worry about civil wars among different interest groups.
It is good to see that Ethereum folks seem to have some understanding of these challenges, and are taking them seriously. It is reported that the God Emperor of Ethereum, VB, wants a conservative policy for changes, doing only those necessary for survival of Ethereum, until 2.0 is out. On the other hand, the schedule for 2.0 is uncertain and seems to slip farther into the future every year, so there is desire to improve what exists, rather than what might exist someday.
However “innoruptive” you think cryptocurreny/blokchain is, it’s still software, and it’s still hard. And the more you succeed, the harder it gets.
Welcome to the software biz!
- Christine Kim (2019) Ethereum Core Developers Debate Benefits of More Frequent Hard Forks. Coindesk, https://www.coindesk.com/ethereum-core-developers-debate-benefits-of-more-frequent-hard-forks