Qtum’s UTXO Design Decision
One of the most exciting reasons to work in the blockchain industry is that there is no monopolistic solution to a problem due to the vast majority of code bases being open-sourced collaborative environments. Based on the problems specifics, developers are encouraged to use the right tool for the task at hand.
Early on when Qtum was first being designed, the thought process was to build a business-ready blockchain that was versatile yet secure. To accomplish these motivations, Qtum chose the underlying UTXO (Unspent Transaction Output) model that Bitcoin is built on over the Accounts model that Ethereum style blockchains are built on.
Therefore, we wanted to take a second and explain why we went with the UTXO style blockchain and compare the two models for those just getting into blockchain.
UTXO Model
The UTXO model was the first blockchain model, deployed as a fundamental part of how the bitcoin blockchain works. It’s simple and elegant in its structure. While a lot of crypto enthusiasts like to talk about the amount of “bitcoins” they have, this sometimes leads to the misconception that bitcoins are like tokens or coins that they would trade with each other.
From the technical standpoint, “bitcoins” are more like receipts. If Alice, a miner, finds a block, the system issues her a receipt (transaction) stating that she is owed “25 Bitcoins”. This receipt is a single transaction and is currently unspent. Transactions only have two states, either they are spent or unspent.
When Alice goes to buy a new laptop from Bob that costs 1 bitcoin, she will consume (spend) the 25 bitcoin transaction to create two new transactions. One transaction is to Bob for the 1 bitcoin she owes him, the other transaction is to herself for the rest of the bitcoins (change).
Why can’t Alice just scratch off “25” in the original transaction and make it 24 and make a new transaction to Bob for 1 bitcoin? Well as we discussed before, transactions can only spent or unspent. They cannot be modified. This is one of the big features of what a blockchain is supposed to be, immutable. The only way to create a new transaction is to spend a transaction that is equal to or greater than the value of the transaction you’re using as the input. If the consumed transaction is greater than the value you want to spend, the rest of the value is turned into change and returned back to you as a new transaction.
Because every new transaction must have a record of what inputs were used to create it, we can audit to make sure no one has made money out of thin air. The only exception to the rule is the system itself, which generates a new transaction for the miner. In this way, you can trace back every transaction to its original issuance from the system, this is known as a coinbase transaction. This may sound complex, and the UTXO model is complex, but it results in a fully auditable blockchain.
Accounts Model
The UTXO model is great at ensuring immutability in the context for moving value around in the form of tokens, but what if the value you’re moving isn’t just a basic ‘token’. What if the ‘value’ you want to invoke is a piece of code? If the output of the transaction for publishing is a piece of code, how do you make it so it can be consumed by not just it’s publisher but anyone?
The Accounts model is far simpler than the UTXO model as it maintains a shared state across all the nodes using a database and transactions simply update the database when needed. It allows for complex data structures and allows for general computing.
Qtum’s General Computing Platform on UTXO
If Accounts is better suited for general computing than the UTXO model, then why and how did Qtum go with the UTXO model?
For the how, Qtum worked on a special “Accounts Abstraction Layer” which you can read about in our whitepaper or read about in our upcoming article about it. The AAL exposes an EVM compliant interface while allowing for a base of UTXO transactions.
Qtum chose the UTXO model primarily because of the security afforded by the longest standing model. Due to the limited set of opcodes used in Bitcoin script and the 8 years since Bitcoin (at the time of the Qtum whitepaper) it was viewed as a significantly securer model. The accounts model is built on top of a comparatively larger set of general computing functions, and as such it’s still riskier to implement natively than the UTXO model.
Secondarily, by using the AAL we can actually expose a general purpose accounts model, not just one that is EVM compliant. The first VM that ran on the AAL was the Ethereum VM and went live last year, but our current plans are to release an x86 VM alongside the EVM, both running on the Qtum chain. This is possible because we didn’t implement the EVM natively and instead expose it to the AAL allowing for modularity.
And finally, using the UTXO model, we can implement Proof-of-Stake consensus on a protocol level, and not just as a smart contract application on top of the chain. The modified Blackcoin Proof-of-Stake algorithm that we use makes use of parallel proofs and requires UTXO activity, something that we couldn’t do in an accounts model.
In short, the Qtum UTXO model allows us to build from the stability and security that the Bitcoin blockchain has been working on for years, while still allowing for a versatile development platform for decentralized applications.
