Bitcoin’s promise is to provide its users with an open monetary network that has no centralised control and can be independently verified; when bitcoiners refer to being your own bank, they mean it quite literally since every computer running a full node checks every block against the consensus rules and stores all transactions since the beginning of bitcoin. These bitcoin account balances are stored as a collection of “Unspent transaction outputs” or UTXO sets, which are somewhat unintuitive and clunk to manage but provide privacy, coin control and efficiency benefits over the alternative “account” based model used in traditional finance.
Your bitcoin full node captures all transaction history as well as the current state of the system, but these are two different sets of information. The transaction history in Bitcoin is currently 400GB and contains every transaction since Bitcoin was launched in early 2009. Â The size of this history will, of course, only increase with time as more transactions are added roughly every 10 minutes a block is mined.
The current system state, however, is much smaller, at under 4GB, and deals with only who owns what right now. Â This state size has generally increased over time but can decrease as few transactions are added to the chain; the decrease could be due to transactions moving to sidechains like the Liquid Network or Lightning Network as part of bitcoin scaling in layers.
Scaling a network from 1 to 1000, then from 1000 to 1 million, gets harder every time and it’s one of the most persistent problems with bitcoin today. As we scale to meet the current demand, we need to remember that solutions need to consider the next billion people who want to use bitcoin. If bitcoin is to scale as a global payment network, it will have to service billions of users, and that can create one massive blockchain data footprint. Making it harder to manage the datasets without sacrificing decentralisation as people get priced out of validating the chain.
While the bitcoin blockchain will get larger, the historical transactions, despite its much larger size, is not the scalability concern. They are simply a record of where coins have moved in the past. They are not vital to the real-time use of bitcoin, in fact, one could run a pruned node and discard the history after processing with no loss of security. Â
What is a concern is if the state size of the bitcoin blockchain continues to grow in a fashion where nodes cannot validate the datasets in a timely fashion, one solution presented to get around this is the proposed update known as a UtreeXO.
What is a UTXO?
This UTXO model is the basis of bitcoin accounting; A UTXO is a discrete piece of bitcoin tied to a private key, these pieces of bitcoin are owned by individuals, analogous to physical coins or cash. Instead of using an account balance model, bitcoin’s UTXO set is a smart way to prevent coins from coming out of nowhere inside bitcoin or someone from using coins that are not really under their power.
The UTXO is fundamental to how bitcoin works and how we manage who owns what on-chain.
The problem with Bitcoin’s UTXO model
While UTXOs are a great way to manage and prove ownership of value on-chain, this model also generates a problem, and that is that it creates a large set of information that, in the end, causes the size of the blockchain to grow disproportionately. Instead of simply updating account balances, you must keep track of these UTXOs created, combined, split apart and moved around.
Not only does that take up a lot of memory and bandwidth as the data set grows, but it makes it increasingly complex and difficult to fully verify the blockchain, slowing down the synchronization process of the nodes.
The scalability problem with bitcoin might not seem like much of an issue now at our current onboarding and usage rate, but it can become a serious limitation over time. Every day more and more people create their wallets and begin to use the bitcoin network, with very few people using the bitcoin network effectively contributing to larger data footprints.
This greater influx of people within the bitcoin network increases the volume of information (more transactions and information within the network), information that the nodes must handle, and that must be recorded on the blockchain.
Reducing the load of UTXOs
To solve this problem and reduce the size of the UTXO information within the blockchain, Tadje Dryja, co-creator of Lightning Network, has presented a solution UTreeXO. The idea behind this improvement is to provide Bitcoin with a system that allows to prune correctly, and cryptographically verifiable the UTXO data set of the bitcoin blockchain to a hash.
That UTreeXO is a hash-based accumulator that takes the UTXO data from the blockchain and turns that data into a huge tree (similar to a Merkle tree). This tree is then synthesized into a root hash that synthesizes all that data set.
The system is cumulative, so the creation of a new hash simply requires the copy of the previous hash with the previous UTXO data, generating the accumulation process. As a result, the new hash is obtained.
This task would be in the hands of the so-called compaction nodes, and they would allow keeping the network synchronized concerning the UTXO and UTreeXO data as required. This ensures that the system cannot be tampered with, that it can be publicly verified, and that the system does not disrupt the current operation of Bitcoin.
What is a UTreeXo?
UTreeXO, is an improvement proposal designed by Tadje Dryja, aiming to improve the management of UTXO in the blockchain by compressing it into a simple hash reproducible by all nodes verifying the chain. The project seeks to help us reduce the problems that occur with managing unspent outputs (UTXO) within the blockchain.
In the UtreeXO accounting system, it allows full nodes to obtain and verify information about the UTXOs being spent in a transaction. A Merkle tree updated after every block accumulates references to every unspent transaction output, allowing nodes to skip storing the outputs themselves.
New transactions can be distributed with the UTXOs they spend and a Merkle branch proving they’re part of the UtreeXO Merkle tree. Overall, this can decrease the amount of storage full nodes need to a minimal amount at the offsetting cost of increases in bandwidth.
UtreeXO would not change Bitcoin’s security model, only the way the data is reviewed by the nodes and could make it easier for more nodes to be spun up with low-tech devices if they’re only going to be running a UTreeXO validation set.
How does UTreeXO work?
The compact nodes of UTreeXO act as a specific safeguard for the network focusing on new transaction creation and transmitting them through the network. At that point, the node takes the transaction, performs a cryptographic proof of that fact and regenerates the UTXO tree of the chain to obtain the final hash. The proof of inclusion (the cryptographic proof of the UTXO) is then sent along with the transaction and stored on the blockchain.
From then on, each UTreeXO compact node forwards the transaction and cryptographic proof to other compact nodes. In this way, a consensus is generated, and only the UTXO tree of the chain is added to the base chain, and the public verification of all this information is enabled.
UTreeXO compact nodes focus on state data and not on historical data. When the transaction is included in a block, all the test data is discarded. This means that compact nodes can keep transactions and tests in their memory. Thus, there is no information to be written on the hard drive.
An escalated solution
In addition to the compact nodes of UTreeXO, there are also the bridge nodes of UTreeXO. The function of these nodes is to receive the standard transactions of the network (those that are not initially formatted to use UTreeXO) and to carry out all the necessary processes to be included in the tree.
To achieve this, the bridge nodes contain the entire history of the blockchain and the complete UTXO list. Thus its role is to receive the information from the full nodes and create a proof of the existence of unspent funds based on the UTXO list. Once this point is made, this information is forwarded with its respective test to the compact nodes.
At this point, it is necessary to emphasize that the presence of the bridge node is only necessary when a standard full node sends data to a compact node. On the other hand, the compact node only sends the transaction data to the standard full node bypassing the cryptographic proof of funds. Ultimately, this system allows the implementation of UTreeXO in a backwards-compatible environment in which the standard nodes and UTreeXO can work without problems.
Objectives of UTreeXO
The main objective of UTreeXO is to decrease the amount of information necessary for the nodes to check the availability of the UTXOs. This way, they would only have to store a copy of the transaction property information, giving bitcoin nodes more resources to focus on chain state validation and improve scalability.
The limitations of a UTreeXO
- The implementation of UTreeXO requires that the intermediary nodes or bridge nodes be created. These nodes will serve as the information transition point from a standard full node to a compact node. The information flow in these bridge nodes must be complete. That is, they must maintain the blockchain as well as the UTXO list, to create the tests that compact nodes need for the validation of transactions.
- The presence of bridge nodes in the network could create situations that go against the decentralisation. This in case UTreeXO is widely used in the network.
- The creation of new commissions that serve as an incentive to the bridge nodes. This is a possibility that could occur in the case of the implementation of UTreeXO technology on the Bitcoin network. This would lead to an increase in the cost of transaction fees.
DYOR
If you would like to learn more about UTreeXOs and do your own research, we suggest starting your journey down the rabbit hole with the following resources:
UTXO management or UTreeXO management?
Do you run a bitcoin node? What kind of bitcoin node are you running? What do you think of the move to UTreeXO? Do you think it’s a possible solution for improving bitcoin’s decentralised validation and improve scalability?
Let us know in the comments down below.
