Bitcoin full node and query server

Server Performance

Query performance measurements of libbitcoin-server across machines and configurations, some with Bitcoin Core, Fulcrum, or Frigate comparisons.

See also node performance.

Native REST Interface

Measurements pending.

Electrum Interface

Sparrow Interface

Bitcoin P2P Interface

Measurements pending.

Bitcoind JSON-RPC Interface

Bitcoind REST Interface

Bitcoind ZMQ Interface

Measurements pending.

BTCD Interface

Measurements pending.

Esplora Interface

Measurements pending.

Methodology

All servers run on one machine, shelly (Threadripper PRO 9985WX, 512 GB, Windows 11), one stack at a time, each with a store at block 950,000 on its own volume. The client is on the same machine, over loopback, making sequential calls on one connection. 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, with networking disabled. Fulcrum 2.1.3 indexes from that Bitcoin Core, at default settings and tuned to its maximum caches. Frigate 1.6.1 indexes silent payments from that Bitcoin Core. The Electrum interface is compared with Fulcrum, the Sparrow interface with Frigate, and the bitcoind JSON-RPC and REST interfaces with Bitcoin Core.

Each method is called with 300 unique requests, drawn from random blocks over the whole chain: a block, a transaction and an output script from each. Addresses are grouped by history size, and the largest class adds 27 addresses of 100k to 2.2M entries.

Each server starts once and runs until idle. Each of three repetitions, on its own requests, empties working sets and purges the standby list, sends 5 s of untimed pings, then makes a cold pass in shuffled order and a warm pass on the same requests in another order.

A call is timed from request to the last response byte, received into a preallocated buffer, with parsing after timing. Rates are calls per second (1000 / mean ms), and address history rates are entries returned per second of call time. Bitcoin Core and Fulcrum hold all headers in memory, so they have no cold header query, and their warm header bars are hatched.

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.

Copyright © 2011-2026 libbitcoin developers