Burning out the garbage
Blockchain is famous for saving all of its history in publicly verifiable form. If the node is connected to network, it gains access to full history of transactions, and can replicate all the information to its local database. It is one of the most important features of blockchain technology, but of course, it doesn’t come without any tradeoffs. The biggest problem of this algorithm is that it requires a tremendous amount of storage to keep alive. The entire Bitcoin database size is about 160GB as of May 2018, and it’s still growing at a rate of 2% per month. To make things worse, most of the instances participating in the network should store all of this database in their local storage, so storage consumption in total would be astronomical.
In its simplest form, a blockchain database consists of block data and state information at that point. Of course it is dangerous to remove block data from the local storage; however, for state information, the situation becomes vastly different. Sometimes it is favorable to lock the asset permanently, and forbid access to this UTXO afterwards. Without any special treatment, these outputs would be left forever in the global storage. These “garbage” assets are such an attractive optimization point, and Bitcoin introduced a standard script called “Null Data” for it. But most people will agree that it’s too limited in functionality, and it is hard to call it a true solution for the situation. Even a tiny bit of additional logic, such as hash collision checking, will pose a problem with this design. It will be within the database permanently, without providing any benefit for the system.
In CodeChain, our solution for this situation is introducing burnability of UTXO. Traditionally, execution result of lock/unlock script has only two possible value, success or failure. CodeChain script adds one more possibility here, called “burnt” state. To burn the asset and make it invalid, the only thing the user has to do is execute a specialized opcode called `BURN`. If the script execution says the UTXO is burnt out, the transaction validation logic of CodeChain will assure that the asset turn into “ashes”, so that it will never be used in the future. It will also remove them from the storage, and achieve higher space efficiency too.
One may doubt the advantages of burning out the garbage, since it didn’t show positive results for Bitcoin. Total space consumption of serialized UTXO is about 2.7GiB, and according to this research, size of null data only count up to 40MB. It’s only about 1.5% of UTXO set, and 0.02% of total disk usage. It seems to be such a small portion at first glance, and it is true for the case of Bitcoin.
However, CodeChain targets general multi-asset management systems, and there are plenty of real world examples that generates tons of garbage every year. The most remarkable case would be that of gift cards. The gift card market has such an enormous size, summing up to 130 billion, solely within the U.S. in the year 2015. The most common practice is to invalidate these cards after every usage. If this kind of asset were to be integrated into a blockchain, even a tiny portion of these used cards would eat up all the remaining space in no time. Most of them even requires some validation logics like timeout or random lotteries, which makes it virtually impossible to detect all invalidation without a special marker. With burnable UTXOs, we can obtain both efficient disk usage and guaranteed disposal of the asset.
The ability to manage multiple assets in one system is quite a tough requirement to meet. CodeChain is hard at work to be flexible enough to cover as many cases as possible, and simultaneously strives to maintain a simple structure. We believe our design choices will bring you the utmost comfort, and adding burnability is one of many features we provide. Our blog still has a lot of stories to tell you about our efforts, so please stay tuned for the next article!
Check out the source code at our github repo. If you would like to chat with the CodeChain developers community, join our gitter channel.
