This repository has been archived by the owner on Feb 23, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 59
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #61 from tendermint/zm_lite_client_algo
Update specification of light client algorithm to align with the code
- Loading branch information
Showing
8 changed files
with
995 additions
and
635 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,66 @@ | ||
# Tendermint 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. | ||
|
Large diffs are not rendered by default.
Oops, something went wrong.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
# Detection | ||
|
||
TODO |
Oops, something went wrong.