Crate vapcore_light

Light client logic and implementation.

A “light” client stores very little chain-related data locally unlike a full node, which stores all blocks, headers, receipts, and more.

This enables the client to have a much lower resource footprint in exchange for the cost of having to ask the network for state data while responding to queries. This makes a light client unsuitable for low-latency applications, but perfectly suitable for simple everyday use-cases like sending transactions from a personal account.

The light client performs a header-only sync, doing verification and pruning historical blocks. Upon pruning, batches of 2048 blocks have a number => (hash, TD) mapping sealed into “canonical hash tries” which can later be used to verify historical block queries from peers.

Re-exports

pub use self::cache::Cache;

pub use self::provider::Provider;

pub use self::provider::MAX_HEADERS_PER_REQUEST;

pub use self::transaction_queue::TransactionQueue;

Modules

cache	Cache for data fetched from the network.
cht	Canonical hash trie definitions and helper functions.
client	Light client implementation. Stores data from light sync
net	PLP Protocol Version 1 implementation.
on_demand	On-demand chain requests over LES. This is a major building block for RPCs. The request service is implemented using Futures. Higher level request handlers will take the raw data received here and extract meaningful results from it.
provider	A provider for the PIP protocol. This is typically a full node, who can give as much data as necessary to its peers.
request	Light protocol request types.
transaction_queue	Light Transaction Queue.