Inside the blockchain developer’s mind: The upgradeability crisis

This is Part 1 of a three-part series in which Andrew Levine outlines the issues facing legacy blockchains and posits solutions to these problems. Read Part 2 on the vertical scaling crisis and Part 3 on the governance crisis as they go live on Sept. 24 and 25.

It is our belief that there are three fundamental problems, or crises, that are standing in the way of blockchain adoption: upgradeability, vertical scaling and governance. In this article, we are going to explore the upgradeability crisis and how computer operating systems could serve as a useful analogy that holds the secret to resolving this crisis and enabling blockchains to achieve mainstream adoption.

The most powerful concept for understanding the upgradeability problem is “antifragility.” Proposed by Nassim Taleb, antifragility is a property of systems that improve when stressed. Fragile systems can seem to be working great most of the time, but when stressed, they fall apart, or “blow up.”

Antifragility is a property that emerges from multilayered, hierarchical systems that contain fragile subunits that by breaking/dying/blowing up result in an overall healthier system. In nature, we call this process evolution. Evolution occurs when a species replaces a less successful trait with a more successful trait. In computing, we call such improvements “upgrades.”

The problem with the major blockchains we know today is that they weren’t designed to be upgraded, which means they can’t evolve. The reason why evolution is so important is that it enables systems to survive “black swans,” which are highly unpredictable events with severe consequences. Not only can antifragile systems survive black swans, they actually get better from them.

In blockchains, there are virtually no separate layers with fragile subsystems that enable healthy adaptation to stressors. Instead of designing from a perspective of humility, the creators try to present themselves as infallible visionaries who have designed a perfect system that immediately deserves a high valuation.

Maps drawn before territory explored

There is no greater proof of this than the reliance on hard forks for system upgrades. A hard fork is the opposite of an upgrade path. It is tossing out the old system and replacing it with a new one.

There is, however, a silver lining to this analysis, which is that the solution is less about breaking through technical barriers than it is about breaking through psychological barriers. We aren’t designing blockchains from first principles, but are still primarily iterating on top of preexisting architectures like those in Bitcoin and Ethereum.

There are many ways to implement a blockchain, but we often assume that the way in which these protocols implement some component of the blockchain is by default the “right way.” These protocols totally frame the way we look at these issues, leading us to create mental “maps” of the problems that were “drawn” before we had even begun exploring this new territory.

Bitcoin and Ethereum were essentially the first decentralized computers. As with any new computing paradigm, in the early stages, engineers and developers are focusing their attention on whether they can even use the technology to solve a specific problem and, if so, use it to build their application. There’s no tooling and no platforms they can take advantage of, so they have to build everything from scratch and optimize their stack for their specific application.

The end result is a monolithic piece of code powering an application designed to solve a specific problem.

First movers and fragile systems

These early applications can be quite successful thanks to the first-mover advantage, but when it comes to software development, the success that comes from being a first mover is illusory. The first movers in software find the features, or “behaviors,” that users will find most valuable, thereby validating the new technology.

But maintaining this advantage is nearly impossible because the application is built on a mountain of old code that few people understand or are capable of upgrading. Bugs are a nightmare to fix, and just maintaining the existing code becomes a Sisyphean task; forget improving it.

At this stage, the apps can die for any number of reasons, but the underlying cause of death is that they are fragile. The black swan that ultimately wreaks havoc on existing apps is the development of the operating system. Operating systems make it an order of magnitude easier for developers to launch the same kind of applications, with the same core behaviors featured in the first movers.

The advent of operating systems enables the technology to scale to the next level by making it easier and faster for developers to release better programs that penetrate more of the market and reach more users. Plus, it gives us another layer in the stack. Now, if one application blows up, the most critical lower layers remain unaffected.

So, problem solved, right? While first-generation operating systems provide a massive competitive advantage to the application developers who adopt the right ones, they also suffer from the same upgradeability problem of the first-generation applications. They emerge as a means of providing core features, security and a shared user base, but not to maximize upgradeability. So, they eventually become feature-bloated, complex and difficult to upgrade.

The operating system analogy

Upgrading the system requires a system reboot and reloading process that becomes longer and more disruptive the bigger and more complicated it gets. While one layer (the OS) is insulated from the mistakes made in another (the application layer), the OS itself remains fragile.

Blockchains like Ethereum and EOS were designed like these early operating systems. They provide core features, security, a shared user base and a programmable “user space” that developers can leverage to add the custom features they need to power their specific applications.

In the case of blockchains, the problems that plague first-generation operating systems are amplified due to immutability; they are constantly growing in size, which places additional stress on infrastructure and creates a distinct scaling challenge.

Further, because they are decentralized, upgrades must make their way through a governance process that ends, under the best of circumstances, in the execution of a coordinated effort in which all of the computers stop running the old software and start running the new software (a new “fork”) at the exact same time. This is far from easy, which is why calling it a “hard” fork is especially apt.

When certain changes require a hard fork, people are forced to bundle those changes because implementing them piecemeal would result in additional network downtime. This results in a “rider problem” similar to what we see in governmental systems where unrelated changes get attached to important changes. In other words, there is a centralization-in-time problem. Because every important thing must be done at the same time, and because people disagree on what is important, the moment in time when those changes must be implemented creates an attack vector.

Regardless, hard forks wind up being big, political, risky and, most importantly, they take down the network! This dramatically slows the rate of progress, and because every major blockchain works this way, the sector as a whole stagnates.

Antifragility through upgradeability

What we need is another layer beneath the operating system that enables the entire system to evolve. In operating systems, that layer is called a BIOS — a basic input/output system. But it’s important to remember that we are only using operating systems as an analogy. We need to construct this layer from first principles specifically for use in blockchains. That layer, like every other layer, must be made up of fragile subunits that can somehow “break” without blowing up the system as a whole.

The creation of the BIOS was a critical step for mainstreaming computers because it enabled developers to rapidly build, test and iterate upon the applications that would make personal computers useful to ordinary consumers.

If we want to cross that same chasm, we don’t just need a better blockchain OS, we need an operating system that is built on a BIOS-equivalent for the specific purpose of upgradeability.

We must be able to add any feature to the blockchain without requiring a hard fork. This will enable the blockchain to adapt to stressors (attacks, bugs, missing features, etc.), improve itself, and scale to meet the needs of the masses.

Until that day comes, the quality of blockchain-based applications will continue to stagnate, and the space will remain dominated by projects that might look like they are working on the surface but that aren’t being widely adopted, are inherently fragile and will one day “blow up.”

The views, thoughts and opinions expressed here are the author’s alone and do not necessarily reflect or represent the views and opinions of Cointelegraph.