@andablackwidow asked a great question on @edicted's post "[Koinos Consensus Algo: Proof-of-Burn](https://leofinance.io/@edicted/koinos-consensus-algo-proof-of-burn)" that I think many people might be interested in learning more about but be warned: this is a technical post.
The question was:
> Seems like EOS at first sight. Which is good, but it is also worth noting that EOS has quite a lot of "native" code for handling time sensitive and/or privileged parts of core contracts, which would need hardfork in case that code needs to be updated. **I wonder if Koinos will face the same problem.** [Emphasis mine]
I think @dan deserves credit for pioneering the use of WASM in general purpose blockchains and the idea of "user" versus "system" contracts, which was certainly an idea that we integrated into the architecture of Koinos. But that's effectively where the direct influence ends. We did not build Koinos in reference to any specific blockchain or blockchain framework, but constructed it from scratch integrating what we saw as the best ideas from many general purpose blockchains. Below I compare Koinos to EOSIO and Polkadot to help explain how Koinos is so much more upgradeable than any other blockchain.
### In fact, I am confident that the nature of its upgradeability means that Koinos will improve at a far faster rate than any other blockchain in the world.
# EOSIO
EOSIO introduced several innovative concepts like in-band upgradeable smart contracts and a few “system smart contracts” which allowed them to change some system parameters without a hard fork. However, there are still a great many scenarios where hard forks are necessary, because most of the “business logic” is still implemented natively in C++.
It seemed to me that "system contracts" were a kind of "hack" that BlockOne developers implemented when they realized that there were specific parts of the system that were likely to need upgrades and they didn't want those upgrades to be bottlenecked by the hard fork process. Since EOSIO smart contracts were upgradeable, moving that logic into smart contracts solved that problem. It was a super clever hack, which is how most innovations are actually found. Koinos takes that innovation and pushes it to the extreme (farther than any other blockchain) by moving ALL business logic into upgradeable smart contracts.
# Polkadot
**Disclaimer: I am not an expert on Polkadot and some of this information might be old.**
Polkadot does leverage WASM to allow “forkless upgrades,” however, it remains inaccessible to most developers and does not provide the degree of modularity and flexibility of Koinos because it still does not separate out the business logic from the native implementation through a design analogous to an operating system. Instead, Polkadot divides the node into a “Runtime” and a “Host” where the Runtime can be upgraded without a hard fork, but the host cannot.
[The components of a Polkadot Host are:
](https://wiki.polkadot.network/docs/learn-polkadot-host)
- Networking components
- State storage, storage trie, database layer
- Consensus
- Wasm interpreter and virtual machine
- Low level primitives for a blockchain
Only once a compiled Polkadot runtime containing the necessary logic is uploaded can a host build a blockchain. In other words, the Polkadot Host is not a true general purpose blockchain because 1. It includes specific business logic (like consensus and finality) and 2. It cannot produce blocks. Of course, the Runtime can’t function without the host therefore it too is not a true general purpose blockchain. Our approach, which we call “modular upgradeability” is fundamentally different and results in a truly general purpose blockchain.
The design of Polkadot also means that system logic can only be written in a single language, Rust, because it is not implemented as smart contracts which means they cannot leverage the same toolchain as dApp developers. Because modular upgradeability has system logic written as smart contracts, blockchain developers can take advantage of the same toolchain as dApp developers including whatever SDKs exist. Since Koinos was also designed for maximum language support, this means upgrades can be developed in any of the major programming languages. It is so accessible to add language support to Koinos that a community developer (Roamin) added TypeScript support (in the form of [AssemblyScript](https://www.assemblyscript.org/)) long before we even shipped main net.
We even used that SDK to develop main net system contracts like the decentralized governance contract! We were surprised to find that smart contracts created using this SDK take up far less space on the blockchain and even run a little faster! For example, the governance contract we had written in C++ took up 200kb of space, whereas the same contract written in AssemblyScript took up only 50kb, for a 75% reduction! In one comparison, an AS smart contract ran 2% faster than the C++ comparison, which means it also consumed less compute. When you're talking about code that is executed every single block, these improvements make a HUGE difference and none of that would have been possible on EOSIO or Polkadot.
# Microservice Architecture
To understand what makes Koinos unique you have to first understand that Koinos is one of the first blockchain's to feature a microservice architecture. Microservice architectures are the dominant paradigm in cloud computing. In addition to providing incredible scaling and debugging benefits, the open source tools that are being developed to support such architectures are exploding which gives Koinos access to more tools like the Advanced Message Queuing Protocol (AMQP).
What this all means is that within the Koinos node “the blockchain” is one of potentially many microservices. Often times blockchain projects like to take a commonly used term and give it a totally different meaning, so I just want to point out we are **not** doing that when we refer to Koinos microservices. A microservice in Koinos is no different than any other, which means that it is entirely up to the user (a node operator) whether to upgrade, customize, or create a microservice. All the node operator, and the network at large, “cares about” is whether valid blocks are being added to the blockchain.
# Chain Microservice
Microservices are insanely easy to upgrade since they are definitionally small and non-consensus. When we're talking about the upgradeability of the blockchain, we're talking about the Chain microservice. The core design principle of the chain service is that it should be a minimalist blockchain that only includes the low level primitives needed for a blockchain and “default” native implementations. The defaults are implemented such that the node can construct a blockchain and transmit blocks over a p2p network (unlike Polkadot’s implementation) but that is all it can do. It has absolutely none of the “real-world” rules that describe how information should be created, stored, or altered within the blockchain ("business logic").
In other words, the chain service has no business logic only **dispatch logic**. It contains only the logic necessary to construct a technically true “blockchain” (include and order transactions) plus logic that allows the system to call into smart contract implementations at the moment of code execution (“runtime”).
Ironically, even the developer of an application-specific blockchain would implement their business logic in smart contracts! For example, one could use TypeScript to write a proof of work contract and a token contract that effectively describe the behaviors of Bitcoin, upload them as system contracts to the Koinos blockchain framework thereby creating a high performance, highly upgradeable implementation of Bitcoin. In fact, that is basically what the original Koinos test net was!
# System Calls
The mental model motivating this design is therefore of “the blockchain” as a kernel of “system calls.” In traditional computing, a system call is a way for a computer program to interface with the operating system kernel; the core of the OS which has complete control over the entire system. They are the OS industry-standard-solution for safely regulating access to the most important part of the operating system.
EOS implemented its system in a fundamentally different way; as a large set of WASM host functions. In order to leverage WASM for blockchain one must take advantage of their “host functions” to specify additional native features that WASM doesn’t have “out of the box.” EOSIO has the user load a WASM module with blockchain-specific features added as host functions (accessing databases, etc.), but which still exist as native implementations in C++ and ultimately means they can only be changed by executing a hard fork.
Koinos effectively has only one host function; invoke_system_call. This allows for the passing of a system call ID along with arguments in the form of a character array which are then parsed by the system and used to identify the desired function which could be implemented either natively or as a WASM smart contract that overrides the natively implemented system call (system call override).
When a computer attempts to run a blockchain with this design, it will execute native implementations until it hits an override at which point it is dispatched to a smart contract containing the alternate business logic. That business logic will be executed in lieu of the native implementation and the computer will be dispatched to the next module of business logic whether that is contained within a native implementation or another “system” smart contract.
In short, EOSIO did not solve the problem of hard forks because its use of WASM did not result in the separation of the higher level rules that determine how data should be created, stored, and upgraded (i.e. the business logic) from the lower-level details of the system infrastructure. This is why (as @andablackwidow points out) EOS, and EOSIO-based chains, as are still bottlenecked in terms of their rate of improvement because they often find themselves having to hard fork in upgrades.
# Conclusion
I realize this was all highly technical, but @andablackwidow's question was technical, so I wanted to give them (and anyone like them) an answer they would find satisfactory. If there are people who want a more plain english explanation, let me know in the comments!
hiveblocks