# Crate ethcore_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 mapping sealed into "canonical hash tries" which can later be used to verify historical block queries from peers.

## Reexports

`pub use self::provider::Provider;`

## Modules

cht | Canonical hash trie definitions and helper functions.
client | Light client implementation. Stores data from light sync
net | LES 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 LES protocol. This is typically a full node, who can give as much data as necessary to its peers.
request | LES request types.

# Help

## Keyboard Shortcuts

?
  Show this help dialog
S
  Focus the search field
⇤
  Move up in search results
⇥
  Move down in search results
⏎
  Go to active search result
+
  Collapse/expand all sections

## Search Tricks

Prefix searches with a type followed by a colon (e.g. `fn:`) to restrict the search to a given type.

Accepted types are: `fn`, `mod`, `struct`, `enum`, `trait`, `type`, `macro`, and `const`.

Search functions by type signature (e.g. `vec -> usize` or `* -> vec`)