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.
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.