*** Please note that this article describes a very early version of the technology that is now known as the Antara Framework. As the Custom Consensus framework evolved, and Komodo launched a full rebrand in July 2019, the Custom Consensus framework was rebranded to the Antara Framework. You can learn more about the current state of the Antara Framework here. ***
Traditionally, Bitcoin Script is thought of as incapable of supporting smart contracts. This is mostly a consequence of the fact that Bitcoin Script is not Turing complete. Now, all of this is changing with Komodo's Custom Consensus framework and UTXO-based smart contracts.
As is often the case, Komodo is leading the blockchain industry in this brand-new technology. This post will explain what the Custom Consensus framework is, how it works, and how UTXO-based smart contracts will dramatically alter the blockchain landscape.
A Brief Review of Bitcoin Script
The very first block in the Bitcoin blockchain was mined on or around January 3, 2009. Since then, this revolutionary technology has exploded, forever changing the way we think of money and currency. We owe many of these developments to Satoshi Nakamoto and his original Bitcoin core code.
The Bitcoin core code itself is written in C++. A time-tested and well-known programming language, C++ is Turing complete and can therefore do all of the things that any other Turing complete programming language can do.
However, Bitcoin transactions are not executed with C++. Instead, transactions are carried out with a special protocol called Bitcoin Script. Script has a number of opcodes, or commands, that tell nodes how to deal with any specific transaction that has been requested.
While most computer programming languages are considered Turing complete, Bitcoin Script is not. It’s widely accepted that this was an intentional decision. But before we can discuss the relative merits of making a programming language Turing complete, let’s take a moment to understand what exactly Turing complete means.
In 1936, a British computer scientist and mathematician named Alan Turing published an academic paper called “On Computable Numbers, with an Application to the Entscheidungsproblem.” It has become a seminal essay in the fields of computer science and computational theory.
In the essay, Turing describes a hypothetical machine that, when granted a few basic assumptions, can theoretically “compute any computable sequence.” This basically means it can solve any mathematical problem that uses only computable numbers. According to Turing’s definition, “a number is computable if its decimal can be written down by a machine.”
Turing called this device a “universal machine” but it is now better known as a “Turing machine.”
Turing machines are generally described in this way: Imagine a simple device that can read and write numbers. This device also has the ability to store data. (Turing assumes that the device has an infinitely large storage capacity but this isn’t essential to understanding the concept of Turing completeness.)
Now, imagine that this simple machine moves from left to right along a thin, infinitely long piece of tape. It reads a number, decides what to do based on a series of instructions that it has been given, and then executes the instructions accordingly.
In simply reading numbers, executing commands, and writing numbers (when instructed to do so), this simple machine can solve any computational sequence. It may take an arbitrarily long period of time but, theoretically, the machine would eventually solve the problem.
So what does all of this actually mean? Why is it important?
The idea of something being “Turing complete” is derived from this idea of a Turing machine. While we know that no machine has an infinitely large memory, we can use the basic theoretical framework to decide whether or not a machine can solve any computable sequence.
It is in this sense that computer languages are said to be Turing complete. A language is Turing complete if it can solve any mathematical problem made up of computable numbers.
As we noted above, Bitcoin Script is not Turing complete. This means that there are some problems and sequences that Bitcoin Script is not capable of solving.
Ethereum and Solidity
This is where Ethereum enters the picture. In December 2013, Vitalik Buterin released Ethereum’s very first white paper. One of the major contributions Ethereum offered was a Turing complete programming language, called Solidity, that can be used to write smart contracts.
In fact, Buterin makes this perfectly clear on the first page of the white paper:
“What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.”
This, in many ways, is an improvement over Bitcoin Script. The ability to create smart contracts— defined in the Ethereum white paper as “systems which automatically move digital assets according to arbitrary pre-specified rules”— opened up a new world of possibilities for blockchain technology.
At the same time, Turing completeness creates a few vulnerabilities. Let’s discuss.
Pros and Cons of Turing Completeness
Any Turing complete programming language has the ability to create “loops.” A loop just means that a certain operation or set of commands can be written once but executed an arbitrary number by simply commanding a machine to execute the operation X times.
In other words, a programmer can tell a computer to execute one piece of code X number of times. There is no need to re-write the same piece of code for each time the operation is to be performed.
In a language that is not Turing complete, like Bitcoin Script, a programmer would need to copy and paste the same piece of code X number of times if he wanted a computer to execute the operation X times.
While loops are beneficial in some ways, they also present vulnerabilities. A programmer may accidentally write an infinite loop into a smart contract, unnecessarily burdening the network with an infinite number of meaningless operations to perform.
If malicious spammers wanted to grind the network to a halt, they could unleash a huge number of smart contracts with infinite loops. These pointless, endless operations would cause crippling congestion.
To avoid this possibility, Buterin introduced the idea of “gas” to the Ethereum network.
Gas: Ethereum’s Way of Avoiding Infinite Loops
In short, users must pay a fee for every single operation that they want the network’s nodes to perform for them. These fees are simply called “gas.” Gas prices disincentivize malicious actors from spamming the network. It also incentivizes developers to write efficient contracts that require as few processes as possible.
Moreover, gas prevents an accidental infinite loop from wreaking havoc on the network because once all the gas is used up, the network stops processing the contract. The loop runs out of gas and the nodes stop executing its commands.
While the concept of gas is a clever innovation, it also makes complex applications prohibitively expensive. If a particular contract or app needs the network to perform a large number of operations to function as designed, it would simply cost too much money to keep it running. It is not financially sustainable.
This is a major problem for Ethereum because, as Buterin himself noted in January 2014, “our goal is to provide a platform for decentralized applications - an android of the cryptocurrency world, where all efforts can share a common set of APIs, trustless interactions and no compromises.”
But later, in July 2018, Buterin had this to say: “If you want to build a decentralized Uber and Lyft on top of an unscalable Ethereum, you are screwed. Full stop.”
For a platform designed to run apps, not being able to sustainably run useful apps is a serious problem.
Recall that Bitcoin Script is not Turing complete. This choice was deliberate. Leaving Bitcoin Script in a simple form was a quicker, safer alternative to a Turing complete language. This is true because it removes the possibility of infinite loops clogging the Bitcoin network.
However, at the same time, the lack of Turing completeness also prevents smart contracts and decentralized applications from being launched on the Bitcoin-protocol-based blockchains. Until now.
Custom Consensus Framework
Komodo's Lead Developer James 'jl777' Lee recently implemented an enhanced version of Crypto-Conditions, which was initially an open standards draft from the Internet Engineering Task Force (IETF). After making serious adjustments to Crypto-Conditions, jl777 invented a way for smart contracts and decentralized applications to be developed on top of Bitcoin-protocol-based blockchains. Komodo calls this new technology the Custom Consensus framework.
This is a truly groundbreaking development because it eliminates one of the major advantages that Ethereum has traditionally had over Bitcoin and BTC-based cryptocurrencies: support for smart contracts and decentralized applications. Thus, Komodo is dramatically shifting the landscape of the entire blockchain industry.
For now, just four basic Custom Consensus (CC) modules have been activated on Komodo Platform: Assets, Faucet, Rewards, and Dice.
The Assets CC module allows any blockchain in the Komodo ecosystem to create tokens on-chain. One native coin can create as many as 100 Million tokens, which may then represent assets.
The Faucet CC module is just what it sounds like: a faucet that allows users to draw a small fraction of a token (0.1) provided that they meet a set of conditions. At present, the conditions state that the funds must be drawn with a unique address that has no more than 3 previous transactions. In the future, these conditions will be customizable.
The Rewards CC module is a method of giving users a reward for locking their funds into an individual CC module address for a specific length of time. This is similar to one of the incentives of a Masternode coin.
Finally, the Dice CC module is a simple dice game. It is completely blockchain-enforced and doesn’t require users to download any special software. The results of each round of play are known within a few seconds.
All four of these Custom Consensus modules are currently written into the Komodo code base. The mandatory updates to the Komodo daemon at block height 1 Million activated the Custom Consensus framework throughout the ecosystem.
The fact that the four CC modules described above are written into the Komodo code base also means the conditions are predetermined. Adjusting the conditions of a CC module would require an update on every machine running the Komodo daemon around the world.
However, Custom Consensus modules will become more flexible and customizable as the Komodo development team continues to advance this brand-new technology.
The goal is to create a library of CC modules to choose from, each with a series of adjustable specifications. That way, most of the labor of coding the modules is already complete but every project can still customize the conditions of the contracts to meet their individual needs.
It’s worth emphasizing that these first four modules are merely scratching the surface of what is possible with Komodo's Custom Consensus framework. To get a better understanding of the enormous potential of the CC framework, let’s learn more about how it works.
CC Modules: UTXO-Based Smart Contracts
Stated simply, a Custom Consensus module locks UTXO in a publicly-known address and prevent those UTXO from being spent until a certain set of conditions has been met. Once the conditions have been fulfilled, the UTXO are unlocked and sent to the appropriate address. It may be helpful to think of a CC module as the ability to create an individual, customized consensus mechanism for any sum of funds.
If you’re not entirely clear on what a UTXO is, Komodo's guide to UTXO will help bring you up to speed.
Before diving any deeper into how Custom Consensus modules works, we need to understand a few things about Bitcoin payments scripts.
Now, Komodo has created an additional payment script that designates a UTXO as belonging to a specific CC module. In other words, it puts constraints on that particular UTXO.
The UTXO in question gets marked with a specific EVAL code. This will effectively lock those funds into the desired module. Every CC module has its own unique EVAL code so there is never any confusion about which module a specific UTXO is entering.
There is also never any confusion about where the funds are sent because for each pubkey in existence, there is a unique address for each different EVAL code. The pubkey remains the same, but due to the actual script having different EVAL codes, it ends up with a different result when entered into a cryptographic hash function, and thus a different address for each module.
Each Custom Consensus module has its own special address that is known to all, including its private key. Making the privkey public enables SPV-based interaction with the modules. It also allows everyone to see that some specific sum of funds have entered a module.
At the same time, the funds cannot be moved until all the conditions of the module have been satisfied. This is true despite the fact that the private key has been made public.
Although anyone can use the privkey to sign a transaction, the module's conditions must be satisfied before the funds can be moved. Remember, the UTXO-based smart contract is basically a customized consensus mechanism. It’s also worth pointing out that one of the conditions of a Custom Consensus module can be a restriction on which addresses the funds can be sent to.
For all of these reasons, the private key is no longer the relevant factor for control of the funds. The relevant factor is the set of conditions set forth by the module. And, as we’ll soon learn, the conditions of a Custom Consensus module are essentially boundless.
To learn more about the technical details of Komodo’s Custom Consensus framework, read this post by Komodo’s Lead Developer jl777 (or this series of the same post compiled and edited by Satinder Grewal).
Advantages Of Komodo's Custom Consensus Framework
There are a few additional advantages of Komodo's Custom Consensus framework that must be emphasized.
First, these modules are hardcoded into the Komodo code base, which means they can be written in C and C++. They can also be written in any compiled programming language that can create a linkable library capable of calling and being called by C/C++ functions. In that sense, Komodo’s CC modules are language agnostic.
The C and C++ programming languages are widely understood, time-tested, and, perhaps most importantly, Turing complete. Thus, CC modules can be programmed to do anything that any other existing program or application is able to do.
Second, CC modules are more secure than balance-based smart contracts. Because Komodo’s CC modules are UTXO-based, the entire balance of an address is never at risk.
This is not the case with balance-based smart contracts, like those on Ethereum, which are linked to an address itself. If hackers are able to exploit a bug in the code, they can drain all the funds from all the addresses associated with a contract, as opposed to taking only the funds locked into the contract itself. We’ve seen this happen again and again and again.
Third, Komodo's Custom Consensus framework is essentially an extension of Bitcoin protocol so a series of RPC calls can be established. This will make it extremely simple to customize and implement CC modules.
It would be a straightforward process to create a GUI so non-technical users can make use of Komodo’s Custom Consensus framework without needing to work through a CLI. Eventually, once a large variety of RPC calls have been created, it will become possible to build entire decentralized applications based on RPC calls alone.
Fourth, CC modules allow zero-confirmation micropayments. The payments will be fully peer-to-peer and will be considered confirmed as soon as they enter the mempool. These 0-conf micropayments will also be protected by Komodo's delayed Proof of Work security mechanism.
Finally, and perhaps most significantly, Komodo's CC modules do not require “gas” or any sort of fee for every process executed. Recall that the smart contracts and dApps built on Ethereum must pay for gas for every single process. This makes complex apps impossible.
Komodo, on the other hand, is far more scalable and will not require a fee for every single process (other than a single, ordinary transaction fee for sending funds).
To avoid the risk of infinite loops, Komodo is exhaustively testing the code for all CC modules prior to implementation.
Then the modules are embedded into the Komodo daemon. This prevents alterations while also making the code publicly visible. Anyone can verify the code of the modules to see that they do exactly what they claim to.
If a project within the Komodo ecosystem would like to use a module that isn’t already in the code base, they can submit a Pull Request to the Komodo repository on Github. If accepted, Komodo will write the module and make it available for all blockchains within the Komodo ecosystem at the next notary hardfork.
If a project on Komodo Platform needs additional modules urgently and has the required technical skills, they can simply fork the Komodo codebase, add the new modules, and spawn their chain.
As far as the Komodo team knows, no other blockchain project has successfully implemented anything like Komodo's Custom Consensus framework on a live chain. From atomic swaps and on-demand blockchain scalability capabilities to blockchain interoperability features and the Custom Consensus framework, Komodo is continuing to develop technologies at the bleeding edge of the blockchain industry.
At present, there are only four CC modules have been integrated. But these four modules will be available to any blockchain built within the Komodo ecosystem on or around September 8, when Block 1 Million is mined. This means, among other things, that any chain will have the option of creating tokens.
There are several additional modules already in development, including a lottery module, a gateways module that will allow peer-to-peer transfers and exchanges of assets, an automatic invoice and payment module, and the zero-confirmations-payment module mentioned above.
To learn more about Komodo's Custom Consensus framework, join the #crypto-conditions channel in Komodo’s community on Discord. You can also sign up for the weekly newsletter to get regular updates about Komodo’s developments.
Join us as we continue to lead the world in blockchain innovations.