A return to proof of work mining, a blockchain built to be fork resistant, and the chance to develop in multiple programming languages. Lessons from history — and an eye to the future.
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. In Part Four, Andrew Levine of Koinos Group discusses some of the challenges the team has faced since identifying the key issues they intend to solve.
In this post I will summarize the solutions we’ve developed to these problems, which we will be showcasing in the upcoming Koinos testnet planned for the second quarter of 2021.
Since that series Koinos Group has successfully launched a token, KOIN, as a proof of work mineable token on Ethereum. By using proof of work to distribute the initial token supply we were able make the token accessible to early adopters and forgo an ICO.
Assessing the ICO model
ICOs and similar token sale tools, while not without their use cases, have created their own crisis within the space by misaligning incentives before development even begins. The issue is not with the ICO as a tool, but what happens when a team is financially rewarded before they have even shipped a product.
While so many projects have followed in the footsteps of Bitcoin, it’s surprising how few have replicated arguably the most successful aspect of its launch; a token distribution exclusively through proof of work.
The benefit of this approach is that it ensures with algorithmic certainty that the people behind the blockchain have no advantage in acquiring the token. In short, everyone, no matter who they are, has to make a financial sacrifice in order to acquire that token and the scale of that sacrifice is determined by some neutral third party. In the case of proof of work, that neutral third party is the manufacturer of hardware.
For Koinos Group, that means we had to spend money to acquire our token just like everyone else. In fact, because we have to spend most of our time developing the product, we are even at a disadvantage relative to professional miners. So we have to keep working to add value to the protocol if we’d like to get a return on our investment.
Proof of work algorithms are not without their problems, but we mitigated those in a few ways.
- First, the mainnet will be governed by a totally different consensus algorithm that won’t be proof of work or proof of stake, so any attempt to develop an ASIC would be a waste of resources.
- Second, we made the algorithm GPU resistant.
- Third, we released this token long before releasing our mainnet. In fact, we released the token long before we had even completed development of our framework. Without a functional product, this token becomes a way for people who believe in our team and who share our vision for a fee-less smart contract platform to acquire the token at a reasonable cost.
Rapid rate of improvement
Part of what makes this launch strategy work is the innovative property set of Koinos. We built Koinos totally from scratch, not around any single feature like transactions per second or sharding, but with the goal of creating a blockchain that would improve at a much more rapid rate than any other blockchain out there.
In our experience developing the Steem blockchain, the need to execute hard forks was the single biggest factor holding back progress. If we wanted to eliminate that bottleneck, we reasoned, moving as much of the system code as possible into smart contracts that could be upgraded in-band would do the trick.
That’s why the Koinos blockchain framework contains only the most basic blockchain features (called “thunks”) like contract input/input, getting parameters, and writing to the database. All of the more complex features that people are more familiar with (consensus algorithm, accounts, resource management, governance, etc.) have been moved into modular WASM smart contracts running in the virtual machine that can be upgraded without a hard fork.
Because all behaviors are now coded in distinct “modules” that can be individually “upgraded” we call this feature modular upgradeability.
As a result of modular upgradeability, any behavior can be added to the blockchain without a hard fork because individual upgrades can be distributed in blocks and transactions that are pushed to the network much like an operating system patch, but with the added benefit of an on-chain record of the entire upgrade path.
By moving nearly all of the system code of the blockchain to smart contract modules that can be upgraded without a hard fork we have made Koinos into a blockchain that derives its strength not from the features it is born with, but based on its ability to rapidly acquire new and better features faster than anything else out there.
This is why we call Koinos the first blockchain capable of evolution.
Modular upgradeability was just the first major technical innovation that we developed to make Koinos less monolithic and an order of magnitude more upgradeable. Just like there is code that does not need to be implemented natively (in the blockchain itself) but that can be implemented as smart contracts (most of it in fact), there is plenty of code that does not need to be implemented either natively or as smart contracts and can instead be implemented as microservices.
Microservice architectures have many benefits which is why this has become the industry standard for modern software development, but one major benefit is scalability because individual services can be scaled up without having to scale up the entire system. This can dramatically reduce the cost of running a network while improving both the speed and quality of improvements to that network. As a result of historical accidents, blockchain stacks appear to be the last to adopt this new standard as Koinos will be the first blockchain built on a microservice architecture.
This creates amazing new opportunities for developers who will be able to build application specific microservices for Koinos that will help them run their nodes, and their applications, more efficiently; and as a consequence deliver better user experiences. Best of all, this will make Koinos node operation more accessible, thereby improving decentralization, and enabling the network as a whole to run more efficiently so that developers and their end-users can get more out of their decentralized applications.
Another benefit of a microservice architecture is that individual microservices (basically small programs) can be written in the best (fastest, most secure, best libraries, etc.) programming language for the job, a capability we also wanted to offer for smart contract developers. But in order to take advantage of this trait we needed to develop a way for these small programs written in different languages to “talk” to one another in a way that conformed to the unique needs of a decentralized network. To solve this problem we created a cross-language serialization framework named Koinos Types.
Koinos Types is like the Rosetta Stone for blockchain data structures. It allows programs written in different languages to talk to one another in a simple and unified way by giving them access to the same objects (the “building blocks” of modern programming languages). Koinos Types allows for the interpretation of Koinos (i.e. blockchain) data structures in practically any programming language which will be extremely useful for the development of blockchain-related microservices, clients, and smart contracts.
Koinos Types solves a number of problems. It helps us add multi-language support to Koinos more generally (including for smart contracts), it enables microservices to communicate with one another, and it makes it far easier to develop and update client-libraries. While modular upgradeability and the microservices architecture alone make Koinos far more upgradeable than any other blockchain, Koinos Types takes that upgradeability to another level. That’s why we were so excited to make Koinos Types the first piece of Koinos that we open sourced.
As you can see, ensuring that Koinos can improve at a more rapid rate than any other blockchain isn’t about any one feature.
- It’s about getting the incentives right from the beginning.
- It’s about ensuring that the blockchain has modular upgradeability.
- It’s about modularizing the very architecture itself as microservices.
- And it’s about making sure that developers operating at every level of the stack (not just smart contracts) are able to use the programming languages they already know and love.
The views and opinions expressed here are solely those of the author and do not necessarily reflect the views of Cointelegraph.com. Every investment and trading move involves risk, you should conduct your own research when making a decision.