davideandClaude Sonnet 5.5
3d05c37feb
index, features, HOWTO (node requirements, sizes and sync time measured on Palladium, real startup log, clone URL), environment, peer discovery and architecture; rpc-interface examples (getinfo, peers, query with real data); release_process rewritten without tags/PyPI; changelog gets a plm-electrumx 1.0.0 entry above the upstream history. Links point to this repository. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
57 lines
2.7 KiB
ReStructuredText
57 lines
2.7 KiB
ReStructuredText
Features
|
|
========
|
|
|
|
- Efficient, lightweight reimplementation of electrum-server
|
|
- Fast synchronization of Palladium mainnet from Genesis: about a
|
|
minute to height 542k on a modern development machine with RocksDB.
|
|
- 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 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.
|