|
|
- # Light Client Protocol
-
- NOTE: This specification is under heavy development and is not yet complete nor
- accurate.
-
- ## Contents
-
- - [Motivation](#motivation)
- - [Structure](#structure)
- - [Core Verification](./verification.md)
- - [Fork Detection](./detection.md)
- - [Fork Accountability](./accountability.md)
-
- ## Motivation
-
- The Tendermint Light Client is motivated by the need for a light weight protocol
- to sync with a Tendermint blockchain, with the least processing necessary to
- securely verify a recent state. The protocol consists of managing trusted validator
- sets and trusted block headers, and is based primarily on checking hashes
- and verifying Tendermint commit signatures.
-
- Motivating use cases include:
-
- - Light Node: a daemon that syncs a blockchain to the latest committed header by making RPC requests to full nodes.
- - State Sync: a reactor that syncs a blockchain to a recent committed state by making P2P requests to full nodes.
- - IBC Client: an ABCI application library that syncs a blockchain to a recent committed header by receiving proof-carrying
- transactions from "IBC relayers", who make RPC requests to full nodes on behalf of the IBC clients.
-
- ## Structure
-
- ### Components
-
- The Tendermint Light Client consists of three primary components:
-
- - [Core Verification](./verification.md): verifying hashes, signatures, and validator set changes
- - [Fork Detection](./detection.md): talking to multiple peers to detect Byzantine behaviour
- - [Fork Accountability](./accountability.md): analyzing Byzantine behaviour to hold validators accountable.
-
- While every light client must perform core verification and fork detection
- to achieve their prescribed security level, fork accountability is expected to
- be done by full nodes and validators, and is thus more accurately a component of
- the full node consensus protocol, though it is included here since it is
- primarily concerned with providing security to light clients.
-
- A schematic of the core verification and fork detection components in
- a Light Node are depicted below. The schematic is quite similar for other use cases.
- Note that fork accountability is not depicted, as it is the responsibility of the
- full nodes.
-
- ![Light Client Diagram](./assets/light-node-image.png).
-
- ### Synchrony
-
- Light clients are fundamentally synchronous protocols,
- where security is restricted by the interval during which a validator can be punished
- for Byzantine behaviour. We assume here that such intervals have fixed and known minimal duration
- referred to commonly as a blockchain's Unbonding Period.
-
- A secure light client must guarantee that all three components -
- core verification, fork detection, and fork accountability -
- each with their own synchrony assumptions and fault model, can execute
- sequentially and to completion within the given Unbonding Period.
-
- TODO: define all the synchrony parameters used in the protocol and their
- relation to the Unbonding Period.
|