An important matter when someone designs a blockchain is the base system. Should it be a balance or an UTXO system? Let’s describe them both and then compare them and see what trade-offs take place between them.
Let’s start with UTXO for historical reasons (bitcoin architecture). What is really UTXO? It stands for Unspent Transaction Output. It is a system to track if a payment is valid or not. In fact, UTXO is a database. If the transaction is not in the UTXO database, the spender tries to spend something that does not exist, or tries to double spend coins. Either way, transaction is marked as invalid and rejected.
Let’s examine the consequences of this architecture: First, it needs RAM. The need for RAM becomes larger as the chain grows. This can stress the nodes. If the need for RAM achieve a high level then some nodes can stop operating. This is bad for the chain as less nodes means more centralization.
Another drawback is the complexity factory. If the chain supports smart contracts then it can be a headache for the developers.
On the other hand, we have the balance system. Balance system is simpler. Each public address holds a balance. A simple check can reveal the amount the address holds, making the coding of smart contracts easier. This makes the architecture much more development friendly. And of course, not large RAM is needed as there is no need to track unspent transactions.
A question arises why Satoshi has chosen UTXO model. He was aware of course of the alternative of the balance model. But we know that he was very sensitive on security maters. He was very careful about the “double-spend attacks” threat. In fact, in his white paper (and the innovation that made the existence of concurrencies possible) was the solving of the double-spending problem. Bearing this in mind, it seems natural that he adopted the UTXO model.
So how balance system counters double-spending attempts ? It turned out that double-spending attacks were not a big issue for balance system either: something that differentiates the transactions can prevent a double-spending. For example, Ethereum uses a number (a nonce) that is increasing each time. Transactions must have a different nonce to be valid.
From the above, it looks like that balance model is more suitable for chains that have smart contract functionality. Balance (Ethereum) architecture makes much sense.
But not so fast. UTXO has the ability to execute transactions in parallel. We do not have mention yet the most important issue for public chains: scalability. What scalability means ? Basically, it means that the usability stays in reasonable good levels as the public chain grows in size. Simply put, the users can access the chain and use it easily, or at least without serious problems.
UTXO model scales better compered to balance model. This is a fact because it is make possible the use of “light wallets”. The user can use a client (wallet) that does not need the whole chain just to make transactions. UTXO database provides enough information to ensure that an amount is unspent. This is called Simplified Payment Verification (SPV). SPV ensures that the users transaction are already written in a block and also shows confirmations on top of that block. As a consequence, user does not need to have the data of the whole chain to make or accept payments.
In balance model, to get the current balance of any public address you need to scan the whole chain. If a wallet gets “out of sync” then it must ‘reindex’ (that is, scan again the chain) to get the actual balance. It is not unusual, even for the third parties (which are used by many other people!) to get out of sync and “show” wrong balances for some period of time.
Light wallets are of great importance for devices such as mobiles or tablets, where it is impossible to download the whole chain. Of course, there are applications that make the use of a wallet possible for a small device for the balance system. But there is a great difference: this applications are forced to use a third party app (a node in a server that keeps the whole chain). This brings up security questions and somehow defeats the purpose of a public chain. You must trust the third party or node, but the whole point of public chains is that they can be used without any trust (trustless property). As a final note, today even the desktops have issues downloading the whole chain for a large blockchain (for example Ethereum). It take really long time and you need a fast drive to be successful. Even in Linux, who uses ext4 file system, it is really hard or impossible to download the chain and sync the wallet without an SSD. HDD can not do the job. This is getting worse as the chains grows in size.
Additionally, there is the privacy issue. UTXO is consider better than the balance model in this aspect. To be fair, balance model can counter this by implementing ring signatures or zero knowledge schemes. These solutions are complicated and have some drawbacks. I’m not going to analyze them now.
So, if someone wishes to adopt the UTXO model for a chain that implements smart contract functionality he must first answer two questions: a) How can developers program without get annoying with UTXO model? b) what happens with the problem of high RAM that is needed ?
The answer to first question is that a special feature of the chain can overcome this problem. It is possible for the virtual machine to be completely agnostic to UTXO payment system. That way, the developer doesn’t need to worry about anything related to payments, as the smart contracts use the balance system. The chain code automatically picks the UTXO transactions and create new ones. So, an intermediate layer is needed to connect the two models. This is achievable (already some chains have implemented it).
The second problem can be handled with the use of memory swap. Now, I must clarify that because of UTXO model there is no real problem for light wallets. The problems arises for the nodes, that is, the machines that keep the whole chain. Why someone must keep the whole chain? Obviously, the chain decentralization is based on the nodes. From the node point of view, it needs the whole chain if it wants to do “mining” or “minting”. Using swap memory relieves the nodes, as disk space is very cheap compared to the memory. So what is the problem, someone may ask. The answer is that memory swap is slower. That means that the node may need some seconds when each new block creation starts. This may not look like a big dial but it is a problem in Proof of Work chains: using memory swap may put a node in disadvantage as it has less time to start mining compared to another machine that has the whole UTXO database in physical memory. This problem is serious if the block creation time is short: if on average the creation time of a block is less than thirty seconds, then even two or three seconds put a miner in disadvantage, making the game “unfair”, or more precisely, it puts small players in an inferior position. Economies of scale are encouraged, forcing node total number to decrease in the long run. This will have an impact on decentralization for the chain.
But the above is not a problem in a Proof of Stake consensus protocol. To understand this is simple: node submits the hash every n seconds. Even for small granularity (for example 8) , the node has 8 whole seconds before he can submit its first “hash” , so there is no disadvantage even for the “small” nodes who want to mint. You can see what is granularity in my explanation of PoS consensus work in another post.
For the above we have decided to use the UTXO model for our chain. We believe that it will increase the usability of our public chain. We do not have false expectations about scalability, the total chain size must grow in a pace similar to technological progress (basically according to hardware and networking costs). But is is our firm belief that UTXO will be a better model in the long run.