In this episode of the Koinos Group Podcast, 
No, we don't agree that the problem is a lack of blockchains written in Haskell or not enough peer-reviewed articles, but we do agree about the importance of reducing fees, enabling developers to write smart contracts in JavaScript (they project that capability in 3-5 YEARS), and of course we agree that people want to create their own fungible and non-fungible tokens. Like us, they want to offer a turnkey decentralized network that developers can use to run great dApps, and I think that's great. We are taking very different approaches, but that's even better. At Koinos Group, what matters most to us is that people are given the technologies they need to take ownership of their data. The more great teams working toward that goal, and taking different paths, the better.
A Worthy Rival can push us in a way that few others can — not even our coaches, mentors, or advisors... Traditional competition forces us to take on an attitude of winning; a Worthy Rival inspires us to take on an attitude of improvement. The former focuses our attention on the outcome; the latter focuses our attention on process... It is the focus on process and constant improvement that reveals new skills and boosts resilience. An excessive focus on beating our competition not only gets exhausting over time, it can actually stifle innovation. - Simon Sinek
One of the reasons they site for implementing the tokens natively is to reduce the fees associated with token transfers. Bear in mind, they don't eliminate the fees. Implementing something natively on a blockchain means that you are not implementing it in smart contracts. Smart contracts are computationally expensive to run, so by foregoing the need to run a smart contract you are necessarily going to lower the fees associated with performing the action.
We agree wholeheartedly that fees are a problem which is why we're designing Koinos from the ground up around eliminating fees altogether. Of course, there's always a cost to running computations on a blockchain which is why we've developed a number of innovations that will dramatically reduce the cost of running the blockchain which you can read about in our whitepaper.
In this episode we talk about a lot of things, but the unique insight I felt like I could lend related back to our experience developing Steem. Because we didn't have smart contracts (just like Cardano at the moment) we had to implement everything natively in the blockchain. That's why we were developing Smart Media Tokens which were fungible tokens natively implemented on the Steem blockchain.
Granted, Steem and Cardano are very different protocols. The ultimate aim of Cardano is to support smart contracts whereas Steem was always intended to be an application specific blockchain (i.e. no smart contracts). But as a result of that intention, it made perfect sense to continue to add features to the blockchain through native implementations. What we didn't realize is that this would only make the base layer more complicated, which would make it more difficult to upgrade in the future and limit the number of people capable of understanding the system sufficiently to even be capable of improving it. This is a problem that could rear it's ugly head on Cardano, especially since it's written in Haskell, an even more obscure programming language than C++.
This is one of the reasons why, when we decided to build our own blockchain we would limit native implementations to the bare minimum necessary to create blocks, run smart contracts and that's it. No consensus algorithm, no governance system, no accounts, no nothing. Everything else would be coded up in separate smart contracts (i.e. modules) that would run in the virtual machine and kind of "replace" the minimalist implementations running natively. This would keep the blockchain itself small and easy to understand, while also minimizing the number of components that could break. With nearly everything living in smart contract modules, developers will be able to quickly find the part of the system they are interested in, understand it, and develop improvements (if necessary).
We call this capability "modular upgradeability" (for obvious reasons). Through the lens of modular upgradeability, native implementations in general purpose blockchains like Cardano come to look like a kind of crutch. They're an "easy" way to improve performance and reduce fees as long as someone is capable of understanding the increasingly complex system and can push through changes whenever they want.
We think that smart contracts are the future and the focus of a general purpose blockchain development team should be minimizing the cost of running smart contracts. Modular upgradeability enables the Koinos community to experiment with all kinds of features, rapidly iterate toward greatness in a live environment while we develop in parallel native implementations that are focused entirely around performance and efficiency enhancements.
Like I said before, what matters most to us is that people are given the technologies they need to take ownership of their data. The more great teams working toward that goal, and taking different paths, the better. Cardano is certainly taking a different path and I think that's GREAT. This is an important enough problem to solve that we should be trying to solve it in different ways not replicating one another's work. Understanding Cardano is helping me to better understand what WE are building and for that alone I am extremely grateful.
