How to avoid development hell

Cointelegraph is following the development of an entirely new blockchain from inception to mainnet and beyond through its series, Inside the Blockchain Developer’s Mind, written by Andrew Levine of Koinos Group.

We recently released the third and final version of the Koinos testnet, which is why I want to talk about something few projects like to talk about: Building blockchains is development hell. In this article, I’ll explain why and how other developers can avoid getting stuck in it.

At first blush, building a blockchain doesn’t sound so hard. A blockchain is just a combination of well-established cryptographic primitives, which, when properly implemented, allow for the construction of a ledger containing a verifiable history of transactions by a network. The more decentralized the network, the more trustworthy the history.

Blockchain “frameworks”

In an effort to make building new blockchains easier, other teams have released blockchain “frameworks” that, in theory, should eliminate the need for developers to worry about building the blockchain itself so that they can focus on whatever unique features they want to build into the blockchain. Cosmos, EOSIO and Polkadot’s Substrate are examples of such blockchain frameworks.

When our team stopped working on Steem (the world’s first fee-less blockchain), our original intention was to leverage an existing blockchain framework to build a blockchain designed to be as accessible as possible. We had spent four years refining Steem’s fee-less design and figured that, by porting that solution into an existing blockchain framework, we could deliver a blockchain that was far more accessible than any other blockchain in relatively little time.

Related: Inside the blockchain developer’s mind: Proof-of-burn blockchain consensus

Truly fee-less and general-purpose

But we were surprised to find that none of the existing frameworks allowed us to create the kind of truly feeless user experience we were looking to bring to the market. We didn’t just want to remove fees on a technical level, we wanted to empower developers to build applications that were free to use. They also lacked a number of other features we believed were required to deliver an acceptable developer experience.

The power of a general-purpose blockchain stems not from the features the blockchain engineers build into the blockchain but from the features that developers add to that blockchain as smart contracts. This is doubly true for a blockchain framework that should really be the most general-purpose blockchain imaginable since the whole idea is to allow people to build any kind of blockchain they can imagine. And yet, the existing frameworks failed to empower us, one of the most experienced blockchain development teams, in our attempts to build the blockchain we wanted to build in multiple ways.

The existing frameworks not only made it impossible for developers to create free-to-use applications, but they also forced developers to learn new and often difficult programming languages and dramatically restricted the rate at which both applications and the blockchain itself could improve.

Related: Inside the blockchain developers’ mind: Building a free-to-use social DApp

Freeing developers

We wanted to build a blockchain that would free developers to build insanely great applications that ordinary people would love to use. That allowed the developers to work in the programming languages they already knew and loved (what we call “universal language support”); that allowed their applications (and the blockchain itself) to rapidly evolve; and, most importantly, it allowed them to build applications that were free to use.

But in order to build that blockchain we first needed a truly general-purpose blockchain framework that would not only allow us to build the blockchain of our dreams but as a natural consequence of being the most general-purpose framework imaginable, should allow anyone to build the blockchain of their dreams.

Koinos is that ultimate general-purpose blockchain framework that will serve as the foundation for the ultimate feeless layer 1: Koinos mainnet. The Koinos Blockchain Framework (KBF) is designed to be the simplest blockchain imaginable, containing only those cryptographic primitives necessary to construct a blockchain and the right “system calls” to allow for the widest range of behaviors to be added in-band (without a hard fork) through the uploading of a smart contract.

Infinite upgradeability

The benefit of this design is infinite upgradeability, but the cost is that it makes getting the system calls right all the more important. Missing a system call or designing it incorrectly would mean having to deal with an otherwise avoidable hard fork. Because hard forks are so time-consuming, political and disruptive, they are the single biggest factor limiting a blockchain’s ability to improve itself, which is ultimately felt by every single developer whose application is built on such a platform.

Now we can see how both application and blockchain developers can get trapped in development hell: working in programming languages they aren’t comfortable with, on platforms that force them to incorporate fees and that improve at a snail’s pace. Under these conditions, even minor changes have incredibly high stakes, and we haven’t even factored in those scenarios where there are millions, sometimes billions, of dollars at risk.

That is development hell. As the core development team behind the Steem blockchain that had to oversee 23 hard forks, we know this terrain better than almost anyone else, which is why we were so committed to banishing it, well … to hell.

Building the Koinos Blockchain Framework from scratch with an entirely novel microservice architecture and getting it to the point where we could launch versions 1 and 2 of the testnet were incredibly challenging. But integrating the feedback we got from those testnets, fixing the bugs they exposed, and finalizing the all-important system calls were a whole other level. But we went through that development hell with the hopes of making it so that others won’t ever have to.

Harbinger

Testnet v3 is, therefore, more than “just another” version of the testnet. It is the final version of the Koinos Blockchain Framework, which is why we will now refer to the testnet, not by a version number, but by the name: Harbinger. It is the culmination of nearly two years of working, identifying and implementing all the necessary system calls needed to give blockchain developers the ultimate level of freedom and allow their application developers to benefit from a platform that is improving at a more rapid rate than any other blockchain out there.

Of course, whenever you’re trying to solve a really important problem, some level of development hell is inevitable. You just want to make sure that you don’t adopt technologies that raise the stakes unnecessarily and that the goal you’re striving for is worth the cost.

For us, that goal is not only sparing blockchain developers (including ourselves) from countless hours spent in developer hell but also leveraging this new technology to build Koinos mainnet: the ultimate feeless layer 1 for empowering developers to build insanely great blockchain-based applications.

No more development hell

The KBF aims to eliminate development hell by allowing developers to build any blockchain they can imagine simply by writing smart contracts, which is infinitely easier than working in the blockchain code itself. And that’s exactly the position we find ourselves in now. While developing the blockchain framework was incredibly challenging, now that it’s over, all that is needed to complete Koinos mainnet is just two smart contracts: one for our proof-of-burn consensus algorithm and the other for governance.

Not only is writing smart contracts far simpler than blockchain development, but this also means that blockchain developers now get to take advantage of the ever-expanding tools that are available to smart contract developers like the AssemblyScript SDK one of our community members built. AssemblyScript doesn’t just produce far more efficient smart contracts than those written in C++ (that was a surprise), it makes smart contract development accessible to JavaScript developers.

Since the KBF turns any smart contract developer into a potential blockchain developer, this means that developing custom blockchains will now be accessible to JavaScript developers with even more languages to come, such as Rust.

If you’re interested in running Harbinger, we’ve made it insanely easy to run a node so you can be up and running in under five minutes.

This article does not contain investment advice or recommendations. Every investment and trading move involves risk, and readers should conduct their own research when making a decision.

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.