Introducing Kunta: A New Blockchain Development Ecosystem
Today I am excited to dive deeper into what the Kunta platform offers (even though we have been working on this for years ❤).
For those interested in reading our papers, or peeping at the code, you can find it on kunta.io
I introduced this work in September 2018, at the Blockchain Tech Conference in Atlanta, GA. Here is that video link (under the image):
Read the full paper here: https://arxiv.org/abs/1812.08073
I learned about Bitcoin in the middle of 2015 while working in Research & Development for a leading insurance company in the United States. One day they put a folder on my desk containing the original Bitcoin paper, and asked me to study “this thing”, and research if the company could use the underlying technology to gain a competitive advantage. so I took it home and read it.
I won’t say that I “was never the same”, of which I tend to hear a lot these days, but I will say that I began to think of innovations that have never crossed my mind before that.
Thus, began my adventure into the world of Cryptocurrencies. If only I had invested in Bitcoin that year, but that’s another story.
During the journey, I began to ask very common questions of the protocol like:
- “Where does the value come from?”
- “How is the network really secure?”
- “ Why was it chosen to arrive at consensus using that approach?”
- “Who really dictates what happens with the code”?
These studies led me to study several infrastructure protocols over the years (which really consists of obsessively diving through every line of code in the protocols, and reading all of the seminal research papers).
There were a few trends that I began to notice during this work. Also, I need to mention that this was my own work at that time, that phase of the blockchain project my employer wanted me to lead only lasted roughly 6–8 months. However, it was enough to begin a career into the space.
Problems
The problems I noticed were centered around:
- Developer Asymmetry
- User Friendliness
- Code Complexity
- Project Flexibility
- Specific Design Choices
Developer Asymmetry
Let us start with Developer Asymmetry.
The question is “who decides what the design choices of the protocol actually are?”.
The truth is there is a very small set of people who actually make those decisions. This is due to several reasons, but in my opinion, this is a hinderance for developers. I would hear development teams talk about “accepting” contributions from the public, which is an interesting concept regarding open source code. Of course, developers say, “just fork the code”, and edit it to your own liking, which brings me to my next problem I observed.
Code Complexity
For example, if I simply wanted to change the hash function used in the Ethereum, or Bitcoin protocols, I’d have to alter the code somehow, and I will likely break something.
For a strong computer scientist, reading code isn’t difficult, but the amount of man hours required on average to change such a simple property of a given protocol is harder than it needs to be in the projects I’ve studied.
Blockchain projects already seem to be difficult for most laymen, and even engineers to understand enough in order to customize a solution for their own use cases.
The more friction we add on top of that implicit friction, the more I believe we hinder the space as a whole from developing for custom use cases.
User/Developer Friendliness
Another problem is user friendliness, of which is covered by so many writers these days that I almost don’t want to cover it. For example, if I want to get an environment up and running for Ethereum, or Bitcoin, I’d have to pull the code down, and begin my own network, or connect to one.
This seems very simple by stating it in one sentence, but everyone who has attempted to do so themselves will attest to the great deal of frustration with doing so.
I do see this is getting better with time, as people/projects tend to focus less and less on the core protocols, and more on applications around development. However, this is putting band-aids on the problem, not really solving it. We also see companies like Amazon attempting the “Blockchain-as-a-service” plays.
Other Capabilities
The above few statements led me to begin thinking that these systems were NOT designed with friendliness, and customizability in mind from their origin.
And then, you have several design decisions that I began to take issue with. For example, I cover Smart Contracts vs Chain Functions in another dedicated post, but here is a summary.
Manifestations of “smart contracts” are conventionally a piece of logic that is augmented to a chain. Our belief, inspired by Bitcoin, is the logic on a network should be known, and defined at chain inception time. I understand Bitcoin had “upgrades” over it’s life, but upgrading a chain with new logic, and designing logic into it before deployment are two different problems.
With Kunta, logic of a chain is designed into it first, before launching a full network. Kunta also supports upgrading the runtime of a chain as well.
Customizability
This is the architecture for Kunta v1, the theorem prover was never finished, but everything else is brought to a “stable” status.
Kunta was made with customizability in mind from the project’s onset. Not only have we worked to build developer tools into the platform, but the design of the platform is heavily modular. This is something that I believe projects like Tezos has gotten more right than wrong. Their concept of modules is similarly something you can extend in javascript.
In regards to block storage, our database for the time being is raw flat files, however that itself is purposefully swappable — instead of increasing software dependencies, thus decreasing developer friendliness.
For the record anything written in code is “swappable” if you have the skills to write the code, just sayin’.
For any insights, or querying into a given chain, we make use of a triple store in a simple graph database — this can be n-store. The initial pieces of information we store in the graph db is simple, but allows for efficient querying. Initially, we store who authored what block, what block a transaction is stored in, and what account targeted another account, etc. This itself is highly customization.
Customizability is regarding the virtual machine, consensus, and other aspects of the protocol.
Of course, what would a flexible blockchain protocol be without customizable transactions. However our transactions work the same way, but are developed differently.
We make use of Chain Functions, and Smart-Contract Templates.
A chain function is a module that is included with the genesis block, and chain configuration.
So when certain states are triggered on chain, these verifiable sets of logic will be invoked. Upon the design of a smart contract template, no contracts that do not follow these templates will even be computed/used in the system.
The set of smart contract templates are defined at chain creation time, and dictate the type of logic the chain can execute.
Any subsequent transactions executed must abide by these templates, or it is not even considered for execution. The transaction is also discarded if it is malformed.
Programming Language Considerations
At the beginning of the project in 2017, we started developing our own language to develop “smart contracts” similar to Ethereum. However, along the way Rust (The Programming Language) has become more popular, and the community has grown. Also, Web Assembly has become more popular as well.
Using these resources, development on our own language slowed as these two have gotten the job done, and have larger communities than we have.
With these technologies, we have replaced the virtual machine in v1 with WASM modules, written in Rust.
This is similar to some projects such as Substrate, and I will cover the difference between the two in a subsequent post. However, substrate exposes very select logic into web assembly modules, Kunta aims to expose several more, for several components of a given chain.
We also use our own Integrated Development Environment for our v1 protocol.
The IDE has a syntax editor for compilation, maps for node discovery/interaction, and several others resources for protocol experimentation/management. Users can design their protocol, test, deploy, and monitor their chain designs locally, or in the cloud from inside the tool.
Since initially writing this, we have finished our newer protocol, AOS aos.kunta.io
We will be writing more on AOS soon. Subscribe to receive updates on our work over time
