Today we finish chapter 6 from Bitcoin: A Work in Progress.
With this solution, because you wouldn’t need a lot of RAM, you could start doing things in specialized hardware. For example, smartphones tend to have very little RAM, so they could get a big performance boost from Utreexo. Or, you could even have a specialized chip — like a GPU — with a tiny onboard memory that validates Bitcoin blocks. Then you have the protocol literally set in stone, or at least set in silicon. If somebody wants to do a hard fork, you’d have to break all the node hardware, and not just all the mining hardware. So, that’s a nice extra barrier to not do hard forks. Unfortunately, this also makes soft forks less attractive, as nodes can’t verify the new rules with the accelerated hardware — so your computer would have to slow down to check all the new rules whenever it encounters transactions that fall under the new rules.
But even without specialized hardware, there’s a potential speedup if the CPU can do most of the block validation work. A 1KB Merkle forest can easily be kept in a typical CPU cache. This avoids having to ferry UTXO set information between the CPU and RAM. Just like using RAM to avoid physical disk reads speeds things up, so does using the CPU cache to avoid using RAM.
In chapter 5 about AssumUTXO, we described how the source code contains a hash that represents the UTXO set a given snapshot height. The node still needs to obtain that UTXO set, which is several gigabytes in size, and it’d probably download it from its peers. With Utreexo, the UTXO set is so small that it can be put in the source code, thus removing the need to download the UTXO set for the snapshot.
Although Utreexo has the potential to be cool, there are some tradeoffs. The most apparent is that if you start using it, and then later, somebody finds a better accumulator you’d have to switch.
The general term for what Utreexo uses for its coin accounting is called an accumulator. It’s something you can use to add stuff to, and in this case, to also remove stuff from. But there are all sorts of mathematical tricks you can deploy to do this. The Merkle tree is conceptually very simple, as we hopefully illustrated, but there have been other proposals, like an RSA accumulator. There’s all sorts of cool cryptographic math you can do to just add things to a set and remove them from a set, essentially. It’s too early to set any particular accumulator in stone with a soft fork.
Such a switch is easy in a scenario with bridge nodes — multiple solutions could exist in parallel, each with their own bridge nodes. But once the proofs are added into blocks with a soft fork, there’s no easy way back.
Another downside is that bandwidth seems to be the bottleneck for Bitcoin right now, and this could make it worse. For that reason, Utreexo is more of an option that people can opt into if, in their case, bandwidth isn’t a problem. However, if the UTXO set grows to a significant degree where it does become a burden and slows down validation, then this might be more appealing.