Crate vapcore_light[][src]

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.


pub use self::cache::Cache;
pub use self::provider::Provider;
pub use self::provider::MAX_HEADERS_PER_REQUEST;
pub use self::transaction_queue::TransactionQueue;



Cache for data fetched from the network.


Canonical hash trie definitions and helper functions.


Light client implementation. Stores data from light sync


PLP Protocol Version 1 implementation.


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.


A provider for the PIP protocol. This is typically a full node, who can give as much data as necessary to its peers.


Light protocol request types.


Light Transaction Queue.