Interface Performance

Efficiency#

Index efficiency: multiple of other product (log scale)

Index efficiency is Libbitcoin's query rate relative to the other server, divided by the size of its index relative to the other's, both at block 950,000 (index sizes are on the footprint page). Each value is a multiple: 2.5× means Libbitcoin delivers 2.5 times the query rate per byte of index, and below 1× it delivers less. Address history rates are entries per second, silent payments rates are blocks scanned per second, and other rates are calls per second.

Throughput#

P2P/S block throughput (linear scale)

P2P/S block/tx throughput (log scale)

Bitcoind JSON-RPC block/tx throughput (log scale)

Bitcoind REST block/tx throughput (log scale)

Bitcoind REST hex block/tx throughput (log scale)

Native REST block/tx throughput (log scale)

The other charts measure one connection at a time. Throughput is what a server delivers under many: each connection count requests its own set of blocks or transactions back to back for 20 seconds, repeating the set if it runs out, from 16 client processes, with both servers configured to accept the full connection count. Each set is requested twice in succession and the second, warm pass is shown. Block series purge the cache and restart the server before every connection count; transaction series do so once per series. On the linear block chart, the dashed line marks the block rate that 10 Gbps of network can carry, so a block curve above the line means the network, not the server, would be the limit.

Bitcoin Core serves only unconfirmed transactions over P2P, so P2P transactions are shown for Libbitcoin alone. Bitcoin Core serves P2P blocks from a single thread and levels off at about 1,100 blocks per second from two connections, with latency growing in proportion to the load; Libbitcoin serves them concurrently and reaches about 5,900 per second by 64 connections. Over encrypted (BIP324) P2P, Libbitcoin reaches about 4,600 blocks per second and Bitcoin Core about 630, while Libbitcoin transactions are faster than unencrypted, since BIP324 drops the per-message double SHA-256 checksum and Libbitcoin's ChaCha20 is hardware accelerated.

Bitcoin Core does not serve HTTPS or websockets, so the HTTPS and websocket series (secure ones dashed), and the native chart, show Libbitcoin alone. HTTPS uses 256 listening ports, one per connection. TLS carries data in records of at most 16 KiB, so a 1.5 MB block is sent as about a hundred separately encrypted and authenticated records; that per-record work is inherent to HTTPS and secure websockets and weighs most on large responses. The HTTPS and secure websocket curves level off where the test client's TLS saturates its processes; Libbitcoin uses under six cores at those rates, and the rate rises with more client processes. Plain HTTP transactions level off near 140,000 per second.

Native REST Interface#

Chain object rate (log scale)

Address output rate (log scale)

Libbitcoin only, in binary data format over HTTP. Addresses are grouped by history size as in the Electrum interface, and an address response is its outputs, so the rate is outputs returned per second of call time.

Electrum Interface#

Chain object rate: comparative (log scale)

Address history rate: comparative (log scale)

The Electrum interface is compared with Fulcrum 2.1.3, which indexes from Bitcoin Core at default settings. Addresses are grouped by history size, and the largest class adds 27 addresses of 100k to 2.2M entries. The 0 entries class uses 300 script hashes that own no output, the query a wallet makes most often when it scans past its last used address, and is plotted in calls per second. Address history rates are entries returned per second of call time.

Sparrow Interface#

Silent payments scan rate, GPU: comparative (log scale)

Silent payments scan rate, CPU: comparative (log scale)

The Sparrow interface is compared with Frigate 1.6.1, which indexes silent payments from Bitcoin Core. A silent payments scan subscribes one scan key to a range of blocks ending at 950,000, and is timed from the subscription to the notification of completion. Each of three repetitions purges the standby list, scans cold with a new key, then scans warm with the same key. Rates are blocks of the range per second, and each range is labeled with its approximate span of time. GPU scans use each server's default GPU backend. CPU scans use Frigate's CPU backend, UltrafastSecp256k1 field arithmetic on BMI2/ADX, which has no SIMD path, and Libbitcoin's AVX-512 IFMA scan. A scan the server ended without completing, other than by timeout, is marked as a server failure. Libbitcoin's other CPU paths are shown warm, in order of rate above the Libbitcoin AVX-512 IFMA warm bar. AVX-512F builds the IFMA 52 bit multiply-add from 32 bit multiplies, and AVX-IFMA is measured as AVX-512 IFMA restricted to its 256 bit registers.

Bitcoin P2P Interface#

Chain object rate: comparative (log scale)

Each server is a peer to a single client connection over loopback. A block is a witness block by getdata, headers and cfheaders are 2,000 per request, and cfilter is one block per request.

Bitcoind JSON-RPC Interface#

Chain object rate: comparative (log scale)

The bitcoind JSON-RPC interface is compared with Bitcoin Core 32.0.

Bitcoind REST Interface#

Chain object rate: comparative (log scale)

The bitcoind REST interface is compared with Bitcoin Core 32.0.

Bitcoind ZMQ Interface#

Transaction notification dispatch rate: comparative (log scale)

Block notification dispatch rate: comparative (log scale)

Chain object rate: comparative (log scale)

Each server is at block 950,000 with an empty pool. Transaction dispatch is measured with 16 to 256 subscribers on one ZMTP endpoint (CurveZMQ dashed, Libbitcoin only), while one P2P peer offers the transactions of blocks 950,001 to 950,009 at 500 per second. For each notification, the span from its arrival at the first subscriber to its arrival at the last is taken, and the rate is the subscribers reached after the first per second of the median span. At 256 subscribers Libbitcoin delivers each notification to all of them in about 2 ms, Bitcoin Core in 8 to 10 ms.

Block dispatch is measured with 256 to 6,144 rawblock subscribers on one ZMTP endpoint, while one P2P peer offers nine blocks 6 seconds apart. The rate is taken as for transactions. At 6,144 subscribers Libbitcoin delivers each block to all of them in about 310 ms, Bitcoin Core in about 360 ms. As subscribers increase, the Libbitcoin rate rises from about 16,000 to 20,000 per second, and the Bitcoin Core rate stays between 15,000 and 17,500. On Windows, Defender network inspection, Web Threat Defense and the Windows Firewall examine each TCP send under a shared kernel lock. Libbitcoin sends to subscribers in parallel and spends about half of its delivery CPU waiting on that lock. Bitcoin Core sends from a single thread, so the same inspection does not contend.

The chain object rate times each of the 28,142 transactions of blocks 950,001 to 950,009, offered in block order by one P2P peer (inventory, then the transaction when requested), from its send to the arrival of its rawtx notification on a ZMQ subscription. Rates are 1000 / mean latency over the 24,517 transactions both servers accepted. Libbitcoin accepted 1,421 more transactions, as Bitcoin Core's clustered mempool imposes a hardwired capacity limit for performance reasons. Both rejected 2,204 transactions that were not yet valid at block 950,000: 1,522 are time-locked to a later block, 55 have unsatisfied relative lock times (BIP68), and 627 spend outputs of those.

BTCD Interface#

Measurements pending.

Esplora Interface#

Measurements pending.

Methodology#

Servers run one at a time on shelly (Threadripper PRO 9985WX, 512 GB, Windows 11), each with a store at block 950,000, called over loopback from the same machine. Libbitcoin 4.0 serves from its own store (address index load factor 5). Bitcoin Core 32.0 has txindex, txospenderindex and the basic block filter index.

Unless noted, each method is called 300 times, one call at a time on one connection, with requests drawn from random blocks across the chain. Each of three repetitions purges all caches and restarts the servers, then makes a cold pass and a warm pass on the same requests. Calls are timed to the last response byte, and rates are calls per second (1000 / mean ms). Bitcoin Core and Fulcrum hold all headers in memory, so their warm header bars are hatched.