November 2024

#genesis
assumevalid=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
blocksonly=1
dbcache=16384
txindex=1
listen=0
#maxconnections=125 (default)
disablewallet=1

2024-11-02T03:22:55Z Config file: M:\Core\Data\bitcoin.conf (not found, skipping)

Dell, Windows 10
32 Dual 2.1GHz cores
256GB 2400MHz RAM
4TB 7,450 MB/s SSD
PCIe3
AVX2, no SHANI
2.3Gps down / 40Mbps up Internet (measured)

2024-11-03T12:57:37Z Using data directory M:\Core\Validate
2024-11-03T12:57:37Z Config file: M:\Core\Validate\bitcoin.conf
2024-11-03T12:57:37Z Config file arg: assumevalid="000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"
2024-11-03T12:57:37Z Config file arg: blocksonly="1"
2024-11-03T12:57:37Z Config file arg: dbcache="16384"
2024-11-03T12:57:37Z Config file arg: disablewallet="1"
2024-11-03T12:57:37Z Config file arg: listen="0"
2024-11-03T12:57:37Z Config file arg: txindex="1"
2024-11-03T12:57:37Z Using at most 125 automatic connections (2048 file descriptors available)
2024-11-03T12:57:37Z Wallet disabled!

2024-11-03T21:57:03Z UpdateTip: new best=00000000000000000071ef0363647bbfb591b04ee268642060596ca21b7671d7 height=500298 version=0x20000000 log2_work=87.697860 tx=284383466 date='2017-12-20T18:03:47Z' progress=0.257010 cache=7979.4MiB(62457317txo)
2024-11-03T21:57:03Z opencon thread exit
2024-11-03T21:57:03Z Shutdown: In progress...
2024-11-03T21:57:03Z addcon thread exit
2024-11-03T21:57:03Z msghand thread exit
2024-11-03T21:57:03Z net thread exit
2024-11-03T21:57:03Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat started
2024-11-03T21:57:03Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.00s)
2024-11-03T21:57:04Z scheduler thread exit
2024-11-03T21:57:04Z Writing 0 mempool transactions to file...
2024-11-03T21:57:04Z Writing 0 unbroadcast transactions to file.
2024-11-03T21:57:04Z Dumped mempool: 0.000s to copy, 0.005s to dump, 27 bytes dumped to file
2024-11-03T22:03:27Z Shutdown: done

# Set the number of script verification threads (0 = auto, up to 15, <0 =
# leave that many cores free, default: 0)
#par=<n>

2024-11-04T14:22:07Z Config file: M:\Core\Validate\bitcoin.conf
2024-11-04T14:22:07Z Config file arg: assumevalid="000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"
2024-11-04T14:22:07Z Config file arg: blocksonly="1"
2024-11-04T14:22:07Z Config file arg: dbcache="16384"
2024-11-04T14:22:07Z Config file arg: disablewallet="1"
2024-11-04T14:22:07Z Config file arg: listen="0"
2024-11-04T14:22:07Z Config file arg: par="-1" <<<<<<==========
2024-11-04T14:22:07Z Config file arg: txindex="1"
2024-11-04T14:22:07Z Using at most 125 automatic connections (2048 file descriptors available)
2024-11-04T14:22:07Z Wallet disabled!
2024-11-04T14:22:07Z scheduler thread start
2024-11-04T14:22:07Z GUI: "registerShutdownBlockReason: Successfully registered: Bitcoin Core didn't yet exit safely…"
2024-11-04T14:22:07Z Using /16 prefix for IP bucketing
2024-11-04T14:22:07Z init message: Loading P2P addresses…
2024-11-04T14:22:07Z Creating peers.dat because the file was not found ("M:\Core\Validate\peers.dat")
2024-11-04T14:22:07Z init message: Loading banlist…
2024-11-04T14:22:07Z Recreating the banlist database
2024-11-04T14:22:07Z SetNetworkActive: true
2024-11-04T14:22:07Z Script verification uses 15 additional threads  <<<<<<==========

For one, since there is no utxo set, prevouts are verified unspent by looking up the outpoint’s spending transaction and verifying that it does not exist. This to me would seem slower than looking up the prevout from a utxo set.

Based on insights from a private conversation, Libbitcoin will also skip checking confirmability if below the milestone. This means that transactions are written in order in the confirmability thread, but their inputs are assumed to exist and be yet unspent. Skipping this check is where the real speedup lies I believe, and was not clear to me on first read. With that in mind, this approach seems more like a combination of assumevalid and assumeutxo, since the signature checks are skipped and the utxo set is assumed to be valid based on the block height.

My intuition is that the speedups are coming from the more aggressive peer utilisation during download, and the clear separation of unordered vs ordered checks to take advantage of parallelism.

I do also think this is what drives most of the IBD speedup there. And it is directly related to their architecture, doing it for Bitcoin Core wouldn’t bring much benefit since you still have to update the UTxO set

Yes although in the context of this specific benchmark it’s more about being able to skip a whole class of checks than parallelizing them, i think.

1. Non-overlapping ranges of blocks (e.g., 1000 blocks at a time) are downloaded and and unordered checks are done in parallel across multiple ranges
2. The first range can also start confirmability checks (genesis to block 999), after which transactions from this range are committed to the Transactions table and the ConfirmationIndex is updated
3. Now that the first range has finished with it’s confirmability checks, the second range of blocks can start its confirmability checks, and so on

1. The entire chain can be downloaded concurrently. Ranges are not necessary and can often make milestone runs slower. Using the configurable window improves data locality and prevents long-running gaps. But it's purely statistical.
2. Validation checks can progress as soon as there are no download gaps in the candidate chain, and continue to the next gap. Once the validated chain is stronger than the confirmed chain (typically 1 block at a time during catch-up), confirmability checks are performed in block order (heavily concurrently within each block).
3. The only delays for validation and confirmation are gaps and resource availability.

Conceptually, this seems close to a MapReduce algorithm, where unordered checks are mapped on to each range, and then the Reduce step requires sequential ordering of each range of blocks for the confirmability checks.

Clear separation between un-ordered and fully ordered checks is what makes this possible, from what I can tell. The partially ordered checks are not done under the -assumevalid / milestone model.

When a Libbitcoin node serves a block to a peer, it must reconstruct the block into its serialised representation, which will require some compute for each block request. Bitcoin Core, however, stores the blocks on disk in their serialised format and will simply read the block from disk and send it to the peer

My personal view on the role of a Bitcoin node is that its primary purpose is to validate and propagate new blocks as quickly as possible, such that all nodes and miners on the network can quickly come to agreement on what the longest/heaviest PoW chain is. This is why I favour the Block based data model.

This isn’t so much block storage which makes a difference but how their content is indexed. In this case it would be clearer to make a distinction between a historical transactions index vs an unspent outputs index.

tx.hash(false)    7.4%
tx.hash(true)     4.9%
bk.merkle(false) 0.47%
bk.merkle(true)  0.48%
======================
total hashing   13.25%

    else if constexpr (use_shani)
    {
        wbuffer[Round] = mm_sha256msg2_epu32
            (
                mm_add_epi32
                (
                    mm_alignr_epi8
                    (
                        wbuffer[Round - 1], wbuffer[Round - 2], SHA::word_bytes
                    ),
                    mm_sha256msg1_epu32
                    (
                        wbuffer[Round - 4], wbuffer[Round - 3]
                    )
                ),
                wbuffer[Round - 1]
            );
    }

        else if constexpr (use_shani)
        {
            state[1] = mm_sha256rnds2_epu32(state[1], state[0], wk[Round]);
            state[0] = mm_sha256rnds2_epu32(state[0], state[1],
                mm_shuffle_epi32(wk[Round], 0x0e));
        }