Blockchain Upgrades & Hard Forks

@andrarchyandrarchy

CEO of Koinos Group, creators of the Koinos blockchain

I’m Andrew Levine, the CEO of Koinos Group, the company that just released our testnet ON SCHEDULE! That’s something you don’t hear a lot from blockchain companies! Not only did we launch our testnet on time, in just two days we were able to integrate community feedback into the project in a small but powerful way that demonstrates one of the core innovations in Koinos; the requirement to hard fork in upgrades. If you’d like to run the testnet (in under 5 minutes), check out this article on HackerNoon, watch this video on YouTube, or just head over to the github repo.

I discuss this (and more) in the latest episode of Our Decentralized Future:

One of our community members pointed out that it was confusing that they were receiving KOIN tokens from the testnet faucet when these are just test tokens with no real value. The testnet will one day become the mainnet so it made perfect sense in our minds for us to use the eventual name of the native token when we were building the testnet, and this kind of thing happens all the time in development.

We agree this confusion isn’t ideal so we decided to change the name of the testnet token “KOIN” to “tKOIN.” Simple right? Well, on Koinos it is, but on other blockchains it’s definitely NOT for a couple of reasons. On blockchains where the base token is implemented natively, changing the name would at least require a hard fork just to add a “t”! But on Koinos all it took was upgrading the KOIN token contract. That’s it. No hard fork required.

Importance of Modularity

But this example highlights more than just the capability of Koinos smart contracts to be upgraded without a hard fork, it also highlights the benefit of having the incredibly high degree of modularity featured in Koinos. The perfect example of this was when Justin Sun purchased Steemit prompting the community to create their own fork of STEEM called “HIVE.” They needed to change the name of their token from “STEEM” to “HIVE.” Simple right?

Again no, because Steem, like most blockchains, has a monolithic design which means that all of the complexity of the different subsystems is exposed and interconnected like a giant bowl of spaghetti (or “big ball of mud”). When one thing breaks it causes many other things to break which makes both finding and fixing the source of the breakage more difficult.

The STEEM token was part of that “bowl of spaghetti” which meant that the word “STEEM” was replicated all over the codebase. Not only did this make finding every instance more time consuming, it meant that if an instance was missed, there could be serious consequences because every part of the system is interconnected.

Lean Blockchain

But on Koinos, the system features are implemented as smart contract modules and not “natively” in a monolithic blockchain. This keeps the blockchain lean and the features organized so that when we wanted to change the name of the base token we only needed to go to one place (the KOIN token system-owned smart contract) make the change and push the upgrade. It didn’t really even register as a difficult problem until we started imagining how it would have worked on other blockchains.

It literally took Koinos blockchain architect, Michael Vandeberg, less than one minute! It took me far longer to write this article! Now, Michael is an amazing engineer, but the modular design of Koinos and incredible upgradeability did the heavy lifting, in this case allowing us to rapidly make a quality-of-life improvement to the network while those using the testnet probably didn’t even notice!

Don’t let the fact that this was a minor change fool you. On other platforms these “minor” changes with widespread consensus are still highly disruptive which means that time and resources that could have been spent on more important changes have to be diverted.

But the reality is even worse. Because minor changes are just as disruptive as major changes, the minor changes are just never made at all and so they accumulate over time leading to an overall worse platform.

Mass Adoption & Rapid Adaptation

Worst of all, none of this makes the difficult changes any easier, in fact, they are even more difficult to coordinate and more disruptive to the network. This is the reason that no decentralized platforms have been able to break into the mainstream; because they aren’t capable of rapidly adapting to the needs of developers and evolving into a platform that people will love using.

Koinos is designed to make both kinds of changes infinitely easier. The modularity of Koinos makes finding the source of a problem and creating a solution easier. The upgradeability of Koinos eliminates the disruption of actually making the change to the system so that the simple changes are trivial to make. This leaves more time and energy to be spent on more important changes that are also easier, and less disruptive, to make!

Of course, mainnet won’t allow any random developer to upload a smart contract and begin reprogramming the blockchain. One of the major components that needs to be built for mainnet is a governance system which will regulate when system-owned smart contracts can be upgraded. Amazingly, governance itself will be implemented as a smart contract module which means that it too can be upgraded without a hard fork!

This means that once governance comes to a consensus, a contract will be upgraded and the system improved without any disruption of service. If you’d like to learn more about the upgradeability of Koinos, check out this article on HackerNoon.

If you’d like to run the Koinos testnet, head over to the Koinos github.