Hornet UTXO(1): A custom, constant-time, highly parallel UTXO database

Reading through the Hornet Node page, it seems like it’s an entirely separate Node implementation.

That’s correct, although the focus is on spec-based consensus, validation, and IBD. There is so far no mempool behavior, although maybe that will be added later.

I find that very interesting and would love to read more about it

The most complete documentation is here:

Hornet Node Overview
Hornet Node Executable Declarative Specification

The Hornet UTXO(1) database is the latest addition to this workstream.

and get my hands on the source code.

I’m not widely sharing the code yet, although I’m planning to do so once this IBD phase is complete. I’d be happy to give a presentation or demo too if you would like to connect via email.

How was the comparison structured? Was it Bitcoin Core vXX.X vs Hornet Node with Hornet UTXO(1) as a DB engine? Or were the 15min achieved by somehow porting the DB to Bitcoin Core?

Bitcoin Core v30.0 vs Hornet Node, yes. Bitcoin Core was run with the -assume-valid option to skip signature and script validation, so that the main cost is the UTXO database construction and querying.

Have you made the same or a similar comparison to libbitcoin? The validation speed on that implementation was also quite astounding and was discussed on Delving Bitcoin as well.

I haven’t but I agree that would be interesting. Is that something you can assist with? My expectation is that libbitcoin beats Core but Hornet wins due to parallelism.

Generally speaking can the DB be somehow used for other purposes like an indexer or similar use cases, or is it constrained as a db engine for Hornet Node?

It could be extended to index transactions and addresses etc. if desired. It’s just low level code so anything’s possible. My initial priority though was just to discover what performance I could get for initial block download.

Thanks, T#

2 Likes