davide
384d907c65
Unmodified source tree of upstream commit 280cb339aa158e099eb936033eecd15719770651
("Merge pull request #389 from SomberNight/202607_release_2_0",
https://github.com/spesmilo/electrumx, release 2.0.0, 3 July 2026).
All Palladium-specific changes are in the commits that follow.
60 lines
2.9 KiB
ReStructuredText
60 lines
2.9 KiB
ReStructuredText
Features
|
|
========
|
|
|
|
- Efficient, lightweight reimplementation of electrum-server
|
|
- Fast synchronization of bitcoin mainnet from Genesis. Recent
|
|
hardware should synchronize in well under 24 hours. The fastest
|
|
time to height 448k (mid January 2017) reported is under 4h 30m. On
|
|
the same hardware JElectrum would take around 4 days and
|
|
electrum-server probably around 1 month.
|
|
- Various configurable means of controlling resource consumption and
|
|
handling bad clients and denial of service attacks. These include
|
|
maximum connection counts, subscription limits per-connection and
|
|
across all connections, maximum response size, per-session bandwidth
|
|
limits, and session timeouts.
|
|
- Minimal resource usage once caught up and serving clients; tracking the
|
|
transaction mempool appears to be the most expensive part.
|
|
- Mostly asynchronous processing of new blocks, mempool updates, and
|
|
client requests. Busy clients should not noticeably impede other
|
|
clients' requests and notifications, nor the processing of incoming
|
|
blocks and mempool updates.
|
|
- Daemon failover. More than one daemon can be specified, and
|
|
ElectrumX will failover round-robin style if the current one fails
|
|
for any reason.
|
|
- Peer discovery protocol removes need for IRC
|
|
- Coin abstraction makes compatible altcoin and testnet support easy.
|
|
|
|
Implementation
|
|
==============
|
|
|
|
ElectrumX does not do any pruning or throwing away of history. I want
|
|
to retain this property for as long as it is feasible, and it appears
|
|
efficiently achievable for the foreseeable future with plain Python.
|
|
|
|
The following all play a part in making it efficient as a Python
|
|
blockchain indexer:
|
|
|
|
- aggressive caching and batching of DB writes
|
|
- more compact and efficient representation of UTXOs, address index,
|
|
and history. Electrum Server stores full transaction hash and
|
|
height for each UTXO, and does the same in its pruned history. In
|
|
contrast ElectrumX just stores the transaction number in the linear
|
|
history of transactions. ElectrumX can determine block
|
|
height from a simple binary search of tx counts stored on disk.
|
|
ElectrumX stores historical transaction hashes in a linear array on
|
|
disk.
|
|
- placing static append-only metadata indexable by position on disk
|
|
rather than in levelDB. It would be nice to do this for histories
|
|
but I cannot think of a way.
|
|
- avoiding unnecessary or redundant computations, such as converting
|
|
address hashes to human-readable ASCII strings with expensive bignum
|
|
arithmetic, and then back again.
|
|
- better choice of Python data structures giving lower memory usage as
|
|
well as faster traversal
|
|
- leveraging asyncio for asynchronous prefetch of blocks to mostly
|
|
eliminate CPU idling. As a Python program ElectrumX is unavoidably
|
|
single-threaded in its essence; we must keep that CPU core busy.
|
|
|
|
Python's :mod:`asyncio` means ElectrumX has no (direct) use for threads
|
|
and associated complications.
|