Crypto-Conditions: UTXO-Based Smart Contracts on Komodo Platform

Traditionally, Bitcoin Script is thought of as being incapable of supporting smart contracts. This is mostly a consequence of the fact that Bitcoin Script is (intentionally) not Turing complete. Now, all of this is changing with Crypto-Conditions and UTXO-based smart contracts.

As is often the case, Komodo Platform is leading the blockchain industry in this brand-new technology. This post will explain what Crypto-Conditions 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 blockchain 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.

Turing Completeness

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.

Crypto-Conditions

Komodo Platform recently implemented Crypto-Conditions, a mechanism that allows smart contracts to be developed on top of Bitcoin-protocol-based blockchains.

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 Crypto-Conditions-based smart contracts have been activated on Komodo Platform: Assets, Faucet, Rewards, and Dice.

The Assets smart contract 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 smart contract 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 smart contract is a method of giving users a reward for locking their funds into a Crypto-Conditions address for a specific length of time. This is similar to one of the incentives of a Masternode coin.

Finally, the Dice smart contract 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 Crypto-Conditions contracts are currently written into the Komodo code base. The mandatory updates to the Komodo daemon at block height 1 Million will activate Crypto-Conditions contracts throughout the ecosystem. That means any assetchain on Komodo Platform can begin using smart contracts on or around September 8, 2018.

The fact that the four smart contracts described above are written into the Komodo code base also means the conditions are predetermined. Adjusting the conditions of a smart contract would require an update on every machine running the Komodo daemon around the world.

However, Crypto-Conditions smart contracts 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 smart contracts to choose from, each with a series of adjustable specifications. That way, most of the labor of coding the contracts 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 contracts are merely scratching the surface of what is possible with Crypto-Conditions. To get a better understanding of the enormous potential of Crypto-Conditions-based smart contracts, let’s learn more about how they work.

UTXO-Based Smart Contracts

Stated simply, Crypto-Conditions smart contracts lock 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 UTXO-based smart contracts 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 Platform’s Guide To UTXO will help bring you up to speed.

Before diving any deeper into how Crypto-Conditions works, we need to understand a few things about Bitcoin payments scripts.

There are several different ways to execute a Bitcoin payment. In particular, there are Pay-To-Pubkey payments, Pay-To-Pubkey-Hash payments, and Pay-to-Script-Hash payments.

Now, Komodo has created an additional payment script that designates a UTXO as belonging to a specific smart contract. In other words, it puts constraints on the UTXO.

The UTXO in question gets marked with a specific EVAL code. This will effectively lock those funds into the desired smart contract. Every Crypto-Conditions contract has its own unique EVAL code so there is never any confusion about which contract 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 contract.

Each Crypto-Conditions contract has its own special address that is known to all, including its private key. Making the privkey public enables SPV-based interaction with the contracts. It also allows everyone to see that some specific sum of funds have entered a contract.

At the same time, the funds cannot be moved until all the conditions of the contract 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 contract’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 Crypto-Conditions contract 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 contract. And, as we’ll soon learn, the conditions of a Crypto-Conditions smart contract are essentially boundless.

To learn more about the technical details of Komodo’s UTXO-based smart contracts, read this post by Komodo’s Lead Developer jl777 (or this series of the same post compiled and edited by Satinder Grewal).

Advantages Of Crypto-Conditions & UTXO-Based Smart Contracts

There are a few additional advantages of UTXO-based smart contracts that must be emphasized.

First, these smart contracts 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 UTXO-based smart contracts are language agnostic.

The C and C++ programming languages are widely understood, time-tested, and, perhaps most importantly, Turing complete. Thus, UTXO-based smart contracts can be programmed to do anything that any other existing program or application is able to do.

Second, UTXO-based smart contracts are more secure than balance-based smart contracts. This is true in two ways. For one thing, because Komodo’s smart contracts 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, UTXO-based smart contracts are 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 UTXO-based smart contracts.

It would be a straightforward process to create a GUI so non-technical users can make use of Komodo’s smart contract tech 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, Crypto-Conditions allows 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 secured by Komodo’s delayed Proof of Work security mechanism.

Finally, UTXO-based smart contracts 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 smart contracts prior to implementation.

Then the contracts are embedded into the Komodo daemon. This prevents alterations while also making the code publicly visible. Anyone can verify the code of the contracts to see that they do exactly what they claim to.

If a project within the Komodo ecosystem would like to use a contract 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 contract and make it available for all assetchains at the next notary hardfork.

If a project on Komodo Platform needs additional contracts urgently and has the required technical skills, they can simply fork the Komodo codebase, add the new contracts, and spawn their chain.

Conclusion

As far as the Komodo team knows, no other blockchain project has successfully implemented Crypto-Conditions on a live chain. From atomic swaps and on-demand scalability features to cross-chain interoperability syncing and UTXO-based smart contracts, Komodo Platform is continuing to develop the technologies at the bleeding edge of the blockchain industry.

At present, there are only four Crypto-Conditions-based smart contracts integrated into Komodo. But these four contracts 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 contracts already in development, including a lottery contract, a multi-gateway contract that will allow peer-to-peer transfers and exchanges of assets, an automatic invoice and payment contract, and the zero-confirmations-payment contract mentioned above.

📧Komodo Newsletter

If you'd like to learn more about blockchain technology and keep up with Komodo's progress, subscribe to our newsletter. Begin your blockchain journey with Komodo today.