Server Performance

Updated: 1 Feb, 2022

Sparrow Wallet relies on the Electrum server protocol for transaction data management.

This document provides current performance benchmarks for various full index Electrum server implementations on standard hardware, and discusses two distinct implementation approaches based on these findings.

Background

An Electrum server functions as a Bitcoin address index, allowing users to retrieve transactions associated with a given address. Unlike the Bitcoin reference implementation, which lacks this feature, Electrum servers offer this functionality. While compact block filters can provide similar information, they don’t support mempool transactions and are less efficient.

The Electrum server protocol is the most widely adopted Bitcoin address index protocol. This benchmark focuses on full address indexes, which are crucial for privacy as they don’t store specific wallet details on the server. For optimal cold storage security, all wallet information should be contained within the wallet file and removed from the server after wallet closure. This approach excludes projects like BWT and EPS that require storing wallet addresses on the server.

MotivationPermalink

This benchmark builds upon Jameson Lopp’s July 2020 performance report, with two key differences:

1. It uses a Raspberry Pi 4 instead of an AWS server, making it more relevant for home users.
2. It employs up-to-date builds of the projects and retests them after significant changes.

These updates make the benchmarks particularly useful for Sparrow users who want to run their own Electrum server on a single board computer, allowing them to compare different implementations and choose the one that best suits their needs. The results provide practical insights for users considering self-hosting an Electrum server in a home environment.

Hardware

This benchmark uses hardware typical for privacy-conscious Sparrow users: a Raspberry Pi 4 (8GB model) running Ubuntu 21.10 64-bit OS. Data storage utilizes a 1TB external USB SSD, preferred over HDDs due to the large size of the Bitcoin blockchain and associated indexes (approximately 0.5 TB). This setup reflects common home-user configurations, providing relevant performance data for those considering self-hosting an Electrum server on similar single board computer setups.

Projects

ElectrumX

ElectrumX, the successor to the original Electrum server project, was adopted in 2017. After the original author ceased Bitcoin blockchain support, Electrum developers forked the project, now maintained at https://github.com/spesmilo/electrumx.

A significant challenge with ElectrumX is the initial index building, taking about a week on the test hardware. However, users can build the index on a more powerful machine and transfer it to a single board computer. Key points:

• Current database size: 75 GB
• Requires txindex enabled on Bitcoin Core
• No pre-compiled binaries available
• Tested version: ElectrumX 1.16

ElectrumX’s index can be built on more powerful hardware and transferred, offering flexibility for users with limited computing resources.

Electrs

Electrs, designed for personal use rather than public servers, offers lower storage requirements but higher CPU usage compared to ElectrumX. It’s maintained at https://github.com/romanz/electrs.

Electrs’ key advantage is its faster index building time, taking only 12-24 hours on the test hardware. This efficiency has made it the preferred choice for most prebuilt node packages. Key points:

• Current database size: 32 GB
• Doesn’t require txindex on Bitcoin Core
• No pre-compiled binaries available
• Tested version: Electrs 0.9.4

The significantly shorter index building time and smaller database size make Electrs an attractive option for personal use, especially on hardware with limited resources.

Fulcrum

Fulcrum, a modern C++ implementation, offers high performance despite larger disk space requirements. Maintained at https://github.com/cculianu/Fulcrum, it strikes a balance between indexing speed and operational performance.

Fulcrum’s indexing takes 2-3 days on the test hardware, positioning it between Electrs and ElectrumX in build time. Once indexed, it delivers exceptional performance. Key points:

• Current database size: 102 GB
• Requires txindex enabled on Bitcoin Core
• Pre-compiled binaries available for Linux (x86_64 and arm64) and Windows
• Tested version: Fulcrum 1.6.0

Fulcrum’s combination of reasonable indexing time and outstanding operational performance makes it a compelling option, especially for users who can accommodate its larger storage needs.

Electrs-esplora

Electrs-esplora, a fork of Electrs, builds additional indexes for enhanced enterprise performance. However, its high data requirements (approximately 800 GB) make it unsuitable for the test hardware. Key points:

• Extremely large storage requirement (~800 GB)
• Can be run with --lightmode flag, reducing disk space by half
• Even in light mode, it nearly exhausts a 1TB drive when combined with the ~420GB blockchain

This implementation’s extensive storage needs exceed typical single board computer setups, making it impractical for most home users. While it offers performance benefits for enterprise use, its resource demands limit its applicability in personal or small-scale deployments.

addrindexrs

addrindexrs is another Electrs fork, used by the Dojo backend for historical transaction data retrieval. It lacks significant performance-related changes that would justify its inclusion as a separate implementation in this benchmark. This fork maintains similar characteristics to the original Electrs project, making it redundant for performance comparison purposes in this context.

Indexing

Indexing performance varies significantly among the three implementations:

ElectrumX: Slowest indexing (1 week), due to Python’s single-threading and slower block parsing. However, its comprehensive index allows for more scalable server responses without frequent Bitcoin Core queries. A 64-bit OS is crucial for optimal performance.

Electrs: Fastest indexing (1 day), attributed to its smaller, simpler index and optimized block retrieval and parsing. This speed comes at a cost: it must reparse blocks during operation, potentially impacting performance for deeper wallets.

Fulcrum: Moderate indexing time (2-3 days), building a slightly larger index than ElectrumX but much faster. Its resource-intensive process benefits from low-level language implementation. The fast sync option can further improve indexing speed. The resulting comprehensive index leads to excellent operational performance.

Each implementation presents a trade-off between indexing time, index size, and operational efficiency, catering to different use cases and hardware capabilities.

The Test

This benchmark evaluates two common server loads from Sparrow using a large wallet (~3000 used addresses):

1. Initial wallet loading: Focuses on address subscriptions, which allow Sparrow to receive updates for address transactions. Importantly, each subscription request returns a hash of all transaction IDs and block heights affecting that address. The test measures the time to subscribe all wallet addresses.
2. Wallet refreshing: Simulates retrieving all wallet data (transactions and blocks) during a manual refresh, which is necessary when communication issues lead to bad data. Address subscriptions are already in place for this test.

Key test parameters:

• Large wallet with ~3000 used addresses
• Batch page size of 50 for all servers
• Measures subscription time for initial loading
• Measures data retrieval time for wallet refreshing

This approach provides a comprehensive performance comparison across different Electrum server implementations, focusing on real-world usage scenarios in Sparrow Wallet.

Test 1: Initial Load (Address Subscription)

Test	Cold Start	Run 1	Run 2	Run 3
ElectrumX	52655 ms	40721 ms	54143 ms	49011 ms
Electrs	322386 ms	393303 ms	384036 ms	427722 ms
Fulcrum	2333 ms	1413 ms	1472 ms	1413 ms

• Fulcrum: Fastest (avg ~1660 ms)
• ElectrumX: Moderate (avg ~49,133 ms)
• Electrs: Slowest (avg ~381,862 ms)

Fulcrum outperforms ElectrumX by 22x and Electrs by ~300x for initial wallet loading.

Test 2: Wallet Refresh (Data Retrieval)

Test	Cold Start	Run 1	Run 2	Run 3
ElectrumX	114466 ms	66175 ms	80133 ms	75489 ms
Electrs	17562 ms	11621 ms	11219 ms	11521 ms
Fulcrum	14152 ms	7854 ms	7382 ms	7442 ms

• Fulcrum: Fastest (avg ~9,208 ms)
• Electrs: Second (avg ~12,981 ms)
• ElectrumX: Slowest (avg ~84,066 ms)

Fulcrum is 8x faster than ElectrumX and 1.5x faster than Electrs for wallet refreshing.

Fulcrum consistently demonstrates superior performance in both tests, showing significant advantages in initial loading and maintaining an edge in wallet refreshing. ElectrumX performs moderately in loading but struggles with refreshes. Electrs, while slow in initial loading, shows competitive performance in refreshing.

Discussion

Sparrow Wallet relies on the Electrum server protocol for transaction data management. This document compares performance of full index Electrum server implementations on standard hardware, focusing on Raspberry Pi 4 with 8GB RAM and 1TB external USB SSD. It examines ElectrumX, Electrs, and Fulcrum implementations.

ElectrumX, maintained at https://github.com/spesmilo/electrumx, takes about a week to build its 75GB index on test hardware and requires txindex enabled on Bitcoin Core. Electrs, designed for personal use https://github.com/romanz/electrs, builds a 32GB index in 12-24 hours without requiring txindex. Fulcrum https://github.com/cculianu/Fulcrum builds a 102GB index in 2-3 days, requires txindex, and offers pre-compiled binaries.

Testing used a large wallet (~3000 addresses) to measure initial loading (address subscriptions) and wallet refreshing (data retrieval). Results show Fulcrum significantly outperforming others, being 22x faster than ElectrumX and ~300x faster than Electrs in initial loading, and 8x faster than ElectrumX and 1.5x faster than Electrs in refreshing.

The performance disparity between Fulcrum and Electrs in initial loading (1.4 seconds vs 6 minutes) stems from their different data storage approaches. Electrs stores minimal data, requiring extensive block retrieval and parsing for each wallet load. For the test wallet, this meant processing 3.5GB of blocks repeatedly, causing high CPU load and potential response failures on single board computers. ElectrumX and Fulcrum maintain comprehensive address indexes, allowing efficient data retrieval. This approach, combined with Bitcoin Core’s transaction index, enables Fulcrum’s superior performance.

Fulcrum’s C++17 implementation provides consistent speed across platforms, while ElectrumX’s Python-based architecture shows inconsistent performance and higher CPU usage. These findings highlight the trade-offs between index size, query speed, and resource utilization in Electrum server implementations, with Fulcrum offering the best balance for most users.

Conclusion

This benchmark reveals Fulcrum as the optimal Electrum server implementation for Sparrow Wallet users.

Despite a slightly longer initial indexing time compared to Electrs, Fulcrum’s comprehensive index offers superior scalability and performance.

As wallet depths increase and storage costs decrease, Fulcrum’s benefits in query speed, reliability, and hardware longevity outweigh its larger disk space requirement.

While Electrs may suit scenarios with very limited disk space and small wallet depths, Fulcrum is recommended as the ideal server for Sparrow, providing the best balance of performance and resource utilization for most users.

Technical note
Efficient address indexing in Electrum servers involves strategic data storage techniques. Fulcrum and ElectrumX use script hash keys (32 bytes and 11 bytes respectively) to map to transaction numbers (tx_num). This tx_num represents a transaction’s order in the blockchain, serving as a compact identifier. The systems maintain a file of txids ordered by tx_num, allowing quick txid retrieval. They also keep an in-memory array mapping block heights to cumulative transaction counts, enabling fast block height lookups. This approach trades increased storage (e.g., ElectrumX’s additional 21GB for txid lookup) for significantly improved query performance compared to Electrs’ minimal storage method. This design illustrates the balance between storage efficiency and query speed in database engineering, with Fulcrum and ElectrumX prioritizing performance over storage economy.