diff --git a/spec/consensus/fork-accountability.md b/spec/consensus/fork-accountability.md index 7509819d4..ea77fe87a 100644 --- a/spec/consensus/fork-accountability.md +++ b/spec/consensus/fork-accountability.md @@ -1,3 +1,3 @@ # Fork Accountability - MOVED! -Fork Accountability has moved to [light](./light). +Fork Accountability has moved to [light-client](./light-client/accountability). diff --git a/spec/consensus/light-client.md b/spec/consensus/light-client.md index db20d49b4..c3da2f79c 100644 --- a/spec/consensus/light-client.md +++ b/spec/consensus/light-client.md @@ -1,3 +1,3 @@ # Light Client - MOVED! -Light Client has moved to [light](./light). +Light Client has moved to [light-client](./light-client). diff --git a/spec/consensus/light/README.md b/spec/consensus/light-client/README.md similarity index 83% rename from spec/consensus/light/README.md rename to spec/consensus/light-client/README.md index 1747f9b6e..fe42e4972 100644 --- a/spec/consensus/light/README.md +++ b/spec/consensus/light-client/README.md @@ -15,9 +15,9 @@ accurate. 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 -primarily of checking hashes and verifying Tendermint commit signatures to -update trusted validator sets and committed block headers from the chain. +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: @@ -33,8 +33,8 @@ transactions from "IBC relayers", who make RPC requests to full nodes on behalf 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. +- [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 @@ -44,7 +44,7 @@ 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 fork accountability is not depicted, as it is the responsibility of the +Note that fork accountability is not depicted, as it is the responsibility of the full nodes. ![Light Client Diagram](./assets/light-node-image.png). @@ -53,7 +53,7 @@ full nodes. 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 minima +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 - diff --git a/spec/consensus/light/accountability.md b/spec/consensus/light-client/accountability.md similarity index 100% rename from spec/consensus/light/accountability.md rename to spec/consensus/light-client/accountability.md diff --git a/spec/consensus/light/assets/light-node-image.png b/spec/consensus/light-client/assets/light-node-image.png similarity index 100% rename from spec/consensus/light/assets/light-node-image.png rename to spec/consensus/light-client/assets/light-node-image.png diff --git a/spec/consensus/light/detection.md b/spec/consensus/light-client/detection.md similarity index 100% rename from spec/consensus/light/detection.md rename to spec/consensus/light-client/detection.md diff --git a/spec/consensus/light/verification.md b/spec/consensus/light-client/verification.md similarity index 51% rename from spec/consensus/light/verification.md rename to spec/consensus/light-client/verification.md index 66da23f12..55e87cd7c 100644 --- a/spec/consensus/light/verification.md +++ b/spec/consensus/light-client/verification.md @@ -1,17 +1,74 @@ # Core Verification -A lite client is a process that connects to Tendermint full node(s) and then tries to verify application -data using the Merkle proofs. - ## Problem statement -We assume that the lite client knows a (base) header *inithead* it trusts (by social consensus or because -the lite client has decided to trust the header before). The goal is to check whether another header -*newhead* can be trusted based on the data in *inithead*. +We assume that the light client knows a (base) header `inithead` it trusts (by social consensus or because +the light client has decided to trust the header before). The goal is to check whether another header +`newhead` can be trusted based on the data in `inithead`. -The correctness of the protocol is based on the assumption that *inithead* was generated by an instance of +The correctness of the protocol is based on the assumption that `inithead` was generated by an instance of Tendermint consensus. +### Failure Model + +For the purpose of the following definitions we assume that there exists a function +`validators` that returns the corresponding validator set for the given hash. + +The light client protocol is defined with respect to the following failure model: + +Given a known bound `TRUSTED_PERIOD`, and a block `b` with header `h` generated at time `Time` +(i.e. `h.Time = Time`), a set of validators that hold more than 2/3 of the voting power +in `validators(b.Header.NextValidatorsHash)` is correct until time `b.Header.Time + TRUSTED_PERIOD`. + +*Assumption*: "correct" is defined w.r.t. realtime (some Newtonian global notion of time, i.e., wall time), +while `Header.Time` corresponds to the [BFT time](./../bft-time.md). In this note, we assume that clocks of correct processes +are synchronized (for example using NTP), and therefore there is bounded clock drift (`CLOCK_DRIFT`) between local clocks and +BFT time. More precisely, for every correct light client process and every `header.Time` (i.e. BFT Time, for a header correctly +generated by the Tendermint consensus), the following inequality holds: `Header.Time < now + CLOCK_DRIFT`, +where `now` corresponds to the system clock at the light client process. + +Furthermore, we assume that `TRUSTED_PERIOD` is (several) order of magnitude bigger than `CLOCK_DRIFT` (`TRUSTED_PERIOD >> CLOCK_DRIFT`), +as `CLOCK_DRIFT` (using NTP) is in the order of milliseconds and `TRUSTED_PERIOD` is in the order of weeks. + +We expect a light client process defined in this document to be used in the context in which there is some +larger period during which misbehaving validators can be detected and punished (we normally refer to it as `UNBONDING_PERIOD` +due to the "bonding" mechanism in modern proof of stake systems). Furthermore, we assume that +`TRUSTED_PERIOD < UNBONDING_PERIOD` and that they are normally of the same order of magnitude, for example +`TRUSTED_PERIOD = UNBONDING_PERIOD / 2`. + +The specification in this document considers an implementation of the light client under the Failure Model defined above. +Mechanisms like `fork accountability` and `evidence submission` are defined in the context of `UNBONDING_PERIOD` and +they incentivize validators to follow the protocol specification defined in this document. If they don't, +and we have 1/3 (or more) faulty validators, safety may be violated. Our approach then is +to *detect* these cases (after the fact), and take suitable repair actions (automatic and social). +This is discussed in document on [Fork accountability](./accountability.md). + +The term "trusted" above indicates that the correctness of the protocol depends on +this assumption. It is in the responsibility of the user that runs the light client to make sure that the risk +of trusting a corrupted/forged `inithead` is negligible. + +*Remark*: This failure model might change to a hybrid version that takes heights into account in the future. + +### High Level Solution + +Upon initialization, the light client is given a header `inithead` it trusts (by +social consensus). When a light clients sees a new signed header `snh`, it has to decide whether to trust the new +header. Trust can be obtained by (possibly) the combination of three methods. + +1. **Uninterrupted sequence of headers.** Given a trusted header `h` and an untrusted header `h1`, +the light client trusts a header `h1` if it trusts all headers in between `h` and `h1`. + +2. **Trusted period.** Given a trusted header `h`, an untrusted header `h1 > h` and `TRUSTED_PERIOD` during which +the failure model holds, we can check whether at least one validator, that has been continuously correct +from `h.Time` until now, has signed `h1`. If this is the case, we can trust `h1`. + +3. **Bisection.** If a check according to 2. (trusted period) fails, the light client can try to +obtain a header `hp` whose height lies between `h` and `h1` in order to check whether `h` can be used to +get trust for `hp`, and `hp` can be used to get trust for `snh`. If this is the case we can trust `h1`; +if not, we continue recursively until either we found set of headers that can build (transitively) trust relation +between `h` and `h1`, or we failed as two consecutive headers don't verify against each other. + + ## Definitions ### Data structures @@ -22,6 +79,8 @@ In the following, only the details of the data structures needed for this specif type Header struct { Height int64 Time Time // the chain time when the header (block) was generated + + LastBlockID BlockID // prev block info ValidatorsHash []byte // hash of the validators for the current block NextValidatorsHash []byte // hash of the validators for the next block } @@ -49,7 +108,8 @@ In the following, only the details of the data structures needed for this specif ### Functions -For the purpose of this lite client specification, we assume that the Tendermint Full Node exposes the following functions over Tendermint RPC: +For the purpose of this light client specification, we assume that the Tendermint Full Node +exposes the following functions over Tendermint RPC: ```go // returns signed header: Header with Commit, for the given height func Commit(height int64) (SignedHeader, error) @@ -69,7 +129,7 @@ Furthermore, we assume the following auxiliary functions: // it assumes signature verification so it can be computationally expensive func signers(commit Commit, validatorSet ValidatorSet) []Validator - // return the voting power the validators in v1 have according to their voting power in set v2 + // returns the voting power the validators in v1 have according to their voting power in set v2 // it does not assume signature verification func votingPowerIn(v1 []Validator, v2 ValidatorSet) int64 @@ -77,50 +137,15 @@ Furthermore, we assume the following auxiliary functions: func hash(v2 ValidatorSet) []byte ``` -### Failure Model - -For the purpose of model definitions we assume that there exists a function -`validators` that returns the corresponding validator set for the given hash. -The lite client specification is defined with respect to the following failure model: - -Given a known bound `TRUSTED_PERIOD`, and a block `b` with header `h` generated at time `Time` -(i.e. `h.Time = Time`), a set of validators that hold more than 2/3 of the voting power -in `validators(b.Header.NextValidatorsHash)` is correct until time `b.Header.Time + TRUSTED_PERIOD`. - -*Assumption*: "correct" is defined w.r.t. realtime (some Newtonian global notion of time, i.e., wall time), -while `Header.Time` corresponds to the [BFT time](bft-time.md). In this note, we assume that clocks of correct processes -are synchronized (for example using NTP), and therefore there is bounded clock drift (`CLOCK_DRIFT`) between local clocks and -BFT time. More precisely, for every correct lite client process and every `header.Time` (i.e. BFT Time, for a header correctly -generated by the Tendermint consensus), the following inequality holds: `Header.Time < now + CLOCK_DRIFT`, -where `now` corresponds to the system clock at the lite client process. - -Furthermore, we assume that `TRUSTED_PERIOD` is (several) order of magnitude bigger than `CLOCK_DRIFT` (`TRUSTED_PERIOD >> CLOCK_DRIFT`), -as `CLOCK_DRIFT` (using NTP) is in the order of milliseconds and `TRUSTED_PERIOD` is in the order of weeks. - -We expect a lite client process defined in this document to be used in the context in which there is some -larger period during which misbehaving validators can be detected and punished (we normally refer to it as `PUNISHMENT_PERIOD`). -Furthermore, we assume that `TRUSTED_PERIOD < PUNISHMENT_PERIOD` and that they are normally of the same order of magnitude, for example -`TRUSTED_PERIOD = PUNISHMENT_PERIOD / 2`. Note that `PUNISHMENT_PERIOD` is often referred to as an -unbonding period due to the "bonding" mechanism in modern proof of stake systems. - -The specification in this document considers an implementation of the lite client under the Failure Model defined above. -Mechanisms like `fork accountability` and `evidence submission` are defined in the context of `PUNISHMENT_PERIOD` and -they incentivize validators to follow the protocol specification defined in this document. If they don't, -and we have 1/3 (or more) faulty validators, safety may be violated. Our approach then is -to *detect* these cases (after the fact), and take suitable repair actions (automatic and social). -This is discussed in document on [Fork accountability](fork-accountability.md). - -*Remark*: This failure model might change to a hybrid version that takes heights into account in the future. - ### Functions In the functions below we will be using `trustThreshold` as a parameter. For simplicity -we assume that `trustThreshold` is a float between 1/3 and 2/3 and we will not be checking it +we assume that `trustThreshold` is a float between `1/3` and `2/3` and we will not be checking it in the pseudo-code. **VerifySingle.** The function `VerifySingle` attempts to validate given untrusted header and the corresponding validator sets based on a given trusted state. It ensures that the trusted state is still within its trusted period, -and that the untrusted header is within assume `clockDrift` bound of the passed time `now`. +and that the untrusted header is within assumed `clockDrift` bound of the passed time `now`. Note that this function is not making external (RPC) calls to the full node; the whole logic is based on the local (given) state. This function is supposed to be used by the IBC handlers. @@ -159,7 +184,7 @@ func VerifySingle(untrustedSh SignedHeader, return (newTrustedState, nil) } -// return true if header is within its lite client trusted period; otherwise returns false +// return true if header is within its light client trusted period; otherwise returns false func isWithinTrustedPeriod(header Header, trustingPeriod Duration, now Time) bool { @@ -173,6 +198,7 @@ is successfully verified) then we have a guarantee that the transition of the tr from `trustedState` to `newTrustedState` happened during the trusted period of `trustedState.SignedHeader.Header`. +TODO: Explain what happens in case `VerifySingle` returns with an error. **verifySingle.** The function `verifySingle` verifies a single untrusted header against a given trusted state. It includes all validations and signature verification. @@ -250,7 +276,7 @@ func verifyCommitFull(vs ValidatorSet, commit Commit) error { ``` **VerifyHeaderAtHeight.** The function `VerifyHeaderAtHeight` captures high level -logic, i.e., application call to the lite client module to download and verify header +logic, i.e., application call to the light client module to download and verify header for some height. ```go @@ -290,6 +316,12 @@ is successfully verified) then we have a guarantee that the transition of the tr from `trustedState` to `newTrustedState` happened during the trusted period of `trustedState.SignedHeader.Header`. +In case `VerifyHeaderAtHeight` returns with an error, then either (i) the full node we are talking to is faulty +or (ii) the trusted header has expired (it is outside its trusted period). In case (i) the full node is faulty so +light client should disconnect and reinitialise with new peer. In the case (ii) as the trusted header has expired, +we need to reinitialise light client with a new trusted header (that is within its trusted period), +but we don't necessarily need to disconnect from the full node we are talking to (as we haven't observed full node misbehavior in this case). + **VerifyBisection.** The function `VerifyBisection` implements recursive logic for checking if it is possible building trust relationship between `trustedState` and untrusted header at the given height over @@ -369,217 +401,177 @@ func fatalError(err) bool { -### The case `untrusted_h.Header.height < trusted_h.Header.height` +### The case `untrustedHeader.Height < trustedHeader.Height` -In the use case where someone tells the lite client that application data that is relevant for it -can be read in the block of height `k` and the lite client trusts a more recent header, we can use the +In the use case where someone tells the light client that application data that is relevant for it +can be read in the block of height `k` and the light client trusts a more recent header, we can use the hashes to verify headers "down the chain." That is, we iterate down the heights and check the hashes in each step. -*Remark.* For the case were the lite client trusts two headers `i` and `j` with `i < k < j`, we should +*Remark.* For the case were the light client trusts two headers `i` and `j` with `i < k < j`, we should discuss/experiment whether the forward or the backward method is more effective. ```go -func Backwards(trusted_h,untrusted_h) error { - assert (untrusted_h.Header.height < trusted_h.Header.height) - if !isWithinTrustedPeriod(trusted_h) return ErrHeaderNotTrusted(trusted_h) - - old := trusted_h - for i := trusted_h.Header.height - 1; i > untrusted_h.Header.height; i-- { - new := Commit(i) - if (hash(new) != old.Header.hash) { +func VerifyHeaderBackwards(trustedHeader Header, + untrustedHeader Header, + trustingPeriod Duration, + clockDrift Duration) error { + + if untrustedHeader.Height >= trustedHeader.Height return ErrErrNonDecreasingHeight + if untrustedHeader.Time >= trustedHeader.Time return ErrNonDecreasingTime + + now := System.Time() + if !isWithinTrustedPeriod(trustedHeader, trustingPeriod, now) { + return ErrHeaderNotWithinTrustedPeriod + } + + old := trustedHeader + for i := trustedHeader.Height - 1; i > untrustedHeader.Height; i-- { + untrustedSh, error := Commit(i) + if error != nil return ErrRequestFailed + + if (hash(untrustedSh.Header) != old.LastBlockID.Hash) { return ErrInvalidAdjacentHeaders } - old := new - if !isWithinTrustedPeriod(trusted_h) return ErrHeaderNotTrusted(trusted_h) + + old := untrustedSh.Header + } + + if hash(untrustedHeader) != old.LastBlockID.Hash { + return ErrInvalidAdjacentHeaders } - if hash(untrusted_h) != old.Header.hash return ErrInvalidAdjacentHeaders + + now := System.Time() + if !isWithinTrustedPeriod(trustedHeader, trustingPeriod, now) { + return ErrHeaderNotWithinTrustedPeriod + } + return nil } ``` -In order to incentivize correct behavior of validators that run Tendermint consensus protocol, fork detection protocol (it will be explained in different document) is executed in case of a fork (conflicting -headers are detected). As detecting conflicting headers, its propagation through the network (by the gossip protocol) and execution of the fork accountability -protocol on the chain takes time, the lite client logic assumes conservative value for trusted period. More precisely, in the context of lite client we always -operate with a smaller trusted period that we call *lite client trusted period* (LITE_CLIENT_TRUSTED_PERIOD). If we assume that upper bound -for fork detection, propagation and processing on the chain is denoted with *fork procession period* (FORK_PROCESSING_PERIOD), then the following formula -holds: -```LITE_CLIENT_TRUSTED_PERIOD + FORK_PROCESSING_PERIOD < TRUSTED_PERIOD```, where TRUSTED_PERIOD comes from the Tendermint Failure Model. - *Assumption*: In the following, we assume that *untrusted_h.Header.height > trusted_h.Header.height*. We will quickly discuss the other case in the next section. We consider the following set-up: -- the lite client communicates with one full node -- the lite client locally stores all the headers that has passed basic verification and that are within lite client trust period. In the pseudo code below we +- the light client communicates with one full node +- the light client locally stores all the headers that has passed basic verification and that are within light client trust period. In the pseudo code below we write *Store.Add(header)* for this. If a header failed to verify, then the full node we are talking to is faulty and we should disconnect from it and reinitialise with new peer. -- If `CanTrust` returns *error*, then the lite client has seen a forged header or the trusted header has expired (it is outside its trusted period). - * In case of forged header, the full node is faulty so lite client should disconnect and reinitialise with new peer. If the trusted header has expired, - we need to reinitialise lite client with new trusted header (that is within its trusted period), but we don't necessarily need to disconnect from the full node +- If `CanTrust` returns *error*, then the light client has seen a forged header or the trusted header has expired (it is outside its trusted period). + * In case of forged header, the full node is faulty so light client should disconnect and reinitialise with new peer. If the trusted header has expired, + we need to reinitialise light client with new trusted header (that is within its trusted period), but we don't necessarily need to disconnect from the full node we are talking to (as we haven't observed full node misbehavior in this case). - -## Context of this document - -In order to make sure that full nodes have the incentive to follow the protocol, we have to address the -following three Issues - -1) The lite client needs a method to verify headers it obtains from a full node it connects to according to trust assumptions -- this document. - -2) The lite client must be able to connect to other full nodes to detect and report on failures in the trust assumptions (i.e., conflicting headers) -- a future document (see #4215). - -3) In the event the trust assumption fails (i.e., a lite client is fooled by a conflicting header), the Tendermint fork accountability protocol must account for the evidence -- a future document (see #3840). - -The term "trusting" above indicates that the correctness of the protocol depends on -this assumption. It is in the responsibility of the user that runs the lite client to make sure that the risk -of trusting a corrupted/forged *inithead* is negligible. - -* For each header *h* it has locally stored, the lite client stores whether - it trusts *h*. We write *trust(h) = true*, if this is the case. - -* signed header fields: contains a header and a *commit* for the current header; a "seen commit". - In Tendermint consensus the "canonical commit" is stored in header *height* + 1. - - - * Validator fields. We will write a validator as a tuple *(v,p)* such that - + *v* is the identifier (we assume identifiers are unique in each validator set) - + *p* is its voting power +## Correctness of the Light Client Protocols ### Definitions -* *TRUSTED_PERIOD*: trusting period -* for realtime *t*, the predicate *correct(v,t)* is true if the validator *v* - follows the protocol until time *t* (we will see about recovery later). - +* `TRUSTED_PERIOD`: trusted period +* for realtime `t`, the predicate `correct(v,t)` is true if the validator `v` + follows the protocol until time `t` (we will see about recovery later). +* Validator fields. We will write a validator as a tuple `(v,p)` such that + + `v` is the identifier (i.e., validator address; we assume identifiers are unique in each validator set) + + `p` is its voting power +* For each header `h`, we write `trust(h) = true` if the light client trusts `h`. -### Tendermint Failure Model +### Failure Model -If a block *b* is generated at time *Time* (and this time is stored in the block), then a set of validators that -hold more than 2/3 of the voting power in ```validators(b.Header.NextValidatorsHash)``` is correct until time -```b.Header.Time + TRUSTED_PERIOD```. +If a block `b` with a header `h` is generated at time `Time` (i.e. `h.Time = Time`), then a set of validators that +hold more than `2/3` of the voting power in `validators(h.NextValidatorsHash)` is correct until time +`h.Time + TRUSTED_PERIOD`. Formally, \[ -\sum_{(v,p) \in h.Header.NextV \wedge correct(v,h.Header.bfttime + TRUSTED_PERIOD)} p > -2/3 \sum_{(v,p) \in h.Header.NextV} p +\sum_{(v,p) \in validators(h.NextValidatorsHash) \wedge correct(v,h.Time + TRUSTED_PERIOD)} p > +2/3 \sum_{(v,p) \in validators(h.NextValidatorsHash)} p \] -## Lite Client Trusting Spec - -The lite client communicates with a full node and learns new headers. The goal is to locally decide whether to trust a header. Our implementation needs to ensure the following two properties: +The light client communicates with a full node and learns new headers. The goal is to locally decide whether to trust a header. Our implementation needs to ensure the following two properties: -- Lite Client Completeness: If header *h* was correctly generated by an instance of Tendermint consensus (and its age is less than the trusting period), then the lite client should eventually set *trust(h)* to true. +- *Light Client Completeness*: If a header `h` was correctly generated by an instance of Tendermint consensus (and its age is less than the trusted period), +then the light client should eventually set `trust(h)` to `true`. -- Lite Client Accuracy: If header *h* was *not generated* by an instance of Tendermint consensus, then the lite client should never set *trust(h)* to true. +- *Light Client Accuracy*: If a header `h` was *not generated* by an instance of Tendermint consensus, then the light client should never set `trust(h)` to true. -*Remark*: If in the course of the computation, the lite client obtains certainty that some headers were forged by adversaries (that is were not generated by an instance of Tendermint consensus), it may submit (a subset of) the headers it has seen as evidence of misbehavior. +*Remark*: If in the course of the computation, the light client obtains certainty that some headers were forged by adversaries +(that is were not generated by an instance of Tendermint consensus), it may submit (a subset of) the headers it has seen as evidence of misbehavior. -*Remark*: In Completeness we use "eventually", while in practice *trust(h)* should be set to true before *h.Header.bfttime + tp*. If not, the block cannot be trusted because it is too old. +*Remark*: In Completeness we use "eventually", while in practice `trust(h)` should be set to true before `h.Time + TRUSTED_PERIOD`. If not, the header +cannot be trusted because it is too old. -*Remark*: If a header *h* is marked with *trust(h)*, but it is too old (its bfttime is more than *tp* ago), then the lite client should set *trust(h)* to false again. +*Remark*: If a header `h` is marked with `trust(h)`, but it is too old at some point in time we denote with `now` (`h.Time + TRUSTED_PERIOD < now`), +then the light client should set `trust(h)` to `false` again at time `now`. -*Assumption*: Initially, the lite client has a header *inithead* that it trusts correctly, that is, *inithead* was correctly generated by the Tendermint consensus. +*Assumption*: Initially, the light client has a header `inithead` that it trusts, that is, `inithead` was correctly generated by the Tendermint consensus. To reason about the correctness, we may prove the following invariant. -*Verification Condition: Lite Client Invariant.* - For each lite client *l* and each header *h*: -if *l* has set *trust(h) = true*, - then validators that are correct until time *h.Header.bfttime + tp* have more than two thirds of the voting power in *h.Header.NextV*. +*Verification Condition: light Client Invariant.* + For each light client `l` and each header `h`: +if `l` has set `trust(h) = true`, + then validators that are correct until time `h.Time + TRUSTED_PERIOD` have more than two thirds of the voting power in `validators(h.NextValidatorsHash)`. Formally, \[ - \sum_{(v,p) \in h.Header.NextV \wedge correct(v,h.Header.bfttime + tp)} p > - 2/3 \sum_{(v,p) \in h.Header.NextV} p + \sum_{(v,p) \in validators(h.NextValidatorsHash) \wedge correct(v,h.Time + TRUSTED_PERIOD)} p > + 2/3 \sum_{(v,p) \in validators(h.NextValidatorsHash)} p \] -*Remark.* To prove the invariant, we will have to prove that the lite client only trusts headers that were correctly generated by Tendermint consensus, then the formula above follows from the Tendermint failure model. - - -## High Level Solution - -Upon initialization, the lite client is given a header *inithead* it trusts (by -social consensus). It is assumed that *inithead* satisfies the lite client invariant. (If *inithead* has been correctly generated by Tendermint consensus, the invariant follows from the Tendermint Failure Model.) -Note that the *inithead* should be within its trusted period during initialization. - -When a lite clients sees a signed new header *snh*, it has to decide whether to trust the new -header. Trust can be obtained by (possibly) the combination of three methods. - -1. **Uninterrupted sequence of proof.** If a block is appended to the chain, where the last block -is trusted (and properly committed by the old validator set in the next block), -and the new block contains a new validator set, the new block is trusted if the lite client knows all headers in the prefix. -Intuitively, a trusted validator set is assumed to only chose a new validator set that will obey the Tendermint Failure Model. - -2. **Trusting period.** Based on a trusted block *h*, and the lite client -invariant, which ensures the fault assumption during the trusting period, we can check whether at least one validator, that has been continuously correct from *h.Header.bfttime* until now, has signed *snh*. -If this is the case, similarly to above, the chosen validator set in *snh* does not violate the Tendermint Failure Model. - -3. **Bisection.** If a check according to the trusting period fails, the lite client can try to obtain a header *hp* whose height lies between *h* and *snh* in order to check whether *h* can be used to get trust for *hp*, and *hp* can be used to get trust for *snh*. If this is the case we can trust *snh*; if not, we may continue recursively. - -## How to use it - -We consider the following use case: - the lite client wants to verify a header for some given height *k*. Thus: - - it requests the signed header for height *k* from a full node - - it tries to verify this header with the methods described here. - -This can be used in several settings: - - someone tells the lite client that application data that is relevant for it can be read in the block of height *k*. - - the lite clients wants the latest state. It asks a full nude for the current height, and uses the response for *k*. - - in case of inter-blockchain communication protocol (IBC) the light client runs on a chain and someone feeds it - signed headers as input and it computes whether it can trust it. - +*Remark.* To prove the invariant, we will have to prove that the light client only trusts headers that were correctly generated by Tendermint consensus. +Then the formula above follows from the failure model. ## Details -**Observation 1.** If *h.Header.bfttime + tp > now*, we trust the old -validator set *h.Header.NextV*. - -When we say we trust *h.Header.NextV* we do *not* trust that each individual validator in *h.Header.NextV* is correct, -but we only trust the fact that less than 1/3 of them are faulty (more precisely, the faulty ones have less than 1/3 of the total voting power). - - - -*Correctness arguments* +**Observation 1.** If `h.Time + TRUSTED_PERIOD > now`, we trust the validator set `validators(h.NextValidatorsHash)`. -Towards Lite Client Accuracy: -- Assume by contradiction that `untrusted_h` was not generated correctly and the lite client sets trust to true because `CheckSupport` returns true. -- trusted_h is trusted and sufficiently new -- by Tendermint Fault Model, less than 1/3 of voting power held by faulty validators => at least one correct validator *v* has signed `untrusted_h`. -- as *v* is correct up to now, it followed the Tendermint consensus protocol at least up to signing `untrusted_h` => `untrusted_h` was correctly generated, we arrive at the required contradiction. +When we say we trust `validators(h.NextValidatorsHash)` we do `not` trust that each individual validator in `validators(h.NextValidatorsHash)` +is correct, but we only trust the fact that less than `1/3` of them are faulty (more precisely, the faulty ones have less than `1/3` of the total voting power). +*`VerifySingle` correctness arguments* -Towards Lite Client Completeness: -- The check is successful if sufficiently many validators of `trusted_h` are still validators in `untrusted_h` and signed `untrusted_h`. -- If *untrusted_h.Header.height = trusted_h.Header.height + 1*, and both headers were generated correctly, the test passes +Light Client Accuracy: +- Assume by contradiction that `untrustedHeader` was not generated correctly and the light client sets trust to true because `verifySingle` returns without error. +- `trustedState` is trusted and sufficiently new +- by the Failure Model, less than `1/3` of the voting power held by faulty validators => at least one correct validator `v` has signed `untrustedHeader`. +- as `v` is correct up to now, it followed the Tendermint consensus protocol at least up to signing `untrustedHeader` => `untrustedHeader` was correctly generated. +We arrive at the required contradiction. -*Verification Condition:* We may need a Tendermint invariant stating that if *untrusted_h.Header.height = trusted_h.Header.height + 1* then *signers(untrusted_h.Commit) \subseteq trusted_h.Header.NextV*. -*Remark*: The variable *trustThreshold* can be used if the user believes that relying on one correct validator is not sufficient. However, in case of (frequent) changes in the validator set, the higher the *trustThreshold* is chosen, the more unlikely it becomes that CheckSupport returns true for non-adjacent headers. +Light Client Completeness: +- The check is successful if sufficiently many validators of `trustedState` are still validators in the height `untrustedHeader.Height` and signed `untrustedHeader`. +- If `untrustedHeader.Height = trustedHeader.Height + 1`, and both headers were generated correctly, the test passes. +*Verification Condition:* We may need a Tendermint invariant stating that if `untrustedSignedHeader.Header.Height = trustedHeader.Height + 1` then +`signers(untrustedSignedHeader.Commit) \subseteq validators(trustedHeader.NextValidatorsHash)`. +*Remark*: The variable `trustThreshold` can be used if the user believes that relying on one correct validator is not sufficient. +However, in case of (frequent) changes in the validator set, the higher the `trustThreshold` is chosen, the more unlikely it becomes that +`verifySingle` returns with an error for non-adjacent headers. -*Correctness arguments (sketch)* +* `VerifyBisection` correctness arguments (sketch)* -Lite Client Accuracy: -- Assume by contradiction that `untrusted_h` was not generated correctly and the lite client sets trust to true because CanTrustBisection returns nil. -- CanTrustBisection returns true only if all calls to CheckSupport in the recursion return nil. -- Thus we have a sequence of headers that all satisfied the CheckSupport +Light Client Accuracy: +- Assume by contradiction that the header at `untrustedHeight` obtained from the full node was not generated correctly and +the light client sets trust to true because `VerifyBisection` returns without an error. +- `VerifyBisection` returns without error only if all calls to `verifySingle` in the recursion return without error (return `nil`). +- Thus we have a sequence of headers that all satisfied the `verifySingle` - again a contradiction -Lite Client Completeness: +light Client Completeness: -This is only ensured if upon *Commit(pivot)* the lite client is always provided with a correctly generated header. +This is only ensured if upon `Commit(pivot)` the light client is always provided with a correctly generated header. *Stalling* -With CanTrustBisection, a faulty full node could stall a lite client by creating a long sequence of headers that are queried one-by-one by the lite client and look OK, before the lite client eventually detects a problem. There are several ways to address this: -* Each call to ```Commit``` could be issued to a different full node -* Instead of querying header by header, the lite client tells a full node which header it trusts, and the height of the header it needs. The full node responds with the header along with a proof consisting of intermediate headers that the light client can use to verify. Roughly, Bisection would then be executed at the full node. -* We may set a timeout how long bisection may take. +With `VerifyBisection`, a faulty full node could stall a light client by creating a long sequence of headers that are queried one-by-one by the light client and look OK, +before the light client eventually detects a problem. There are several ways to address this: +* Each call to `Commit` could be issued to a different full node +* Instead of querying header by header, the light client tells a full node which header it trusts, and the height of the header it needs. The full node responds with +the header along with a proof consisting of intermediate headers that the light client can use to verify. Roughly, `VerifyBisection` would then be executed at the full node. +* We may set a timeout how long `VerifyBisection` may take. diff --git a/spec/consensus/light/verification-non-recursive.md b/spec/consensus/light/verification-non-recursive.md deleted file mode 100644 index 085f3f65c..000000000 --- a/spec/consensus/light/verification-non-recursive.md +++ /dev/null @@ -1,612 +0,0 @@ -# Lite client - -A lite client is a process that connects to Tendermint full node(s) and then tries to verify application -data using the Merkle proofs. - -## Problem statement - -We assume that the lite client knows a (base) header *inithead* it trusts (by social consensus or because -the lite client has decided to trust the header before). The goal is to check whether another header -*newhead* can be trusted based on the data in *inithead*. - -The correctness of the protocol is based on the assumption that *inithead* was generated by an instance of -Tendermint consensus. - -## Definitions - -### Data structures - -In the following, only the details of the data structures needed for this specification are given. - - ```go - type Header struct { - Height int64 - Time Time // the chain time when the header (block) was generated - - // hashes from the app output from the prev block - ValidatorsHash []byte // hash of the validators for the current block - NextValidatorsHash []byte // hash of the validators for the next block - - // hashes of block data - LastCommitHash []byte // hash of the commit from validators from the last block - } - - type SignedHeader struct { - Header Header - Commit Commit // commit for the given header - } - - type ValidatorSet struct { - Validators []Validator - TotalVotingPower int64 - } - - type Validator struct { - Address Address // validator address (we assume validator's addresses are unique) - VotingPower int64 // validator's voting power - } - - type TrustedState { - SignedHeader SignedHeader - ValidatorSet ValidatorSet - } - ``` - -### Functions - -For the purpose of this lite client specification, we assume that the Tendermint Full Node exposes the following functions over Tendermint RPC: -```go - // returns signed header: Header with Commit, for the given height - func Commit(height int64) (SignedHeader, error) - - // returns validator set for the given height - func Validators(height int64) (ValidatorSet, error) -``` - -Furthermore, we assume the following auxiliary functions: -```go - // returns the validator set for the given validator hash - func validators(validatorsHash []byte) ValidatorSet - - // returns true if commit corresponds to the block data in the header; otherwise false - func matchingCommit(header Header, commit Commit) bool - - // returns the set of validators from the given validator set that committed the block - // it does not assume signature verification - func signers(commit Commit, validatorSet ValidatorSet) []Validator - - // return the voting power the validators in v1 have according to their voting power in set v2 - // it assumes signature verification so it can be computationally expensive - func votingPowerIn(v1 []Validator, v2 ValidatorSet) int64 - - // add this state as trusted to the store - func add(store Store, trustedState TrustedState) error - - // retrieve the trusted state at given height if it exists (error = nil) - // return an error if there are no trusted state for the given height - // if height = 0, return the latest trusted state - func get(store Store, height int64) (TrustedState, error) -``` - - -**VerifyHeaderAtHeight.** TODO. -```go -func VerifyHeaderAtHeight(untrustedHeight int64, - trustThreshold TrustThreshold, - trustingPeriod Duration, - clockDrift Duration, - store Store) (error, (TrustedState, Time)) { - - now := System.Time() - initTrustedState, newTrustedState, err := VerifyAndUpdateNonRecursive(untrustedHeight, - trustThreshold, - trustingPeriod, - clockDrift, - now, - store Store) - - if err != nil return err - - now = System.Time() - if !isWithinTrustedPeriod(initTrustedState.SignedHeader.Header, trustingPeriod, now) { - return ErrHeaderNotWithinTrustedPeriod - } - return nil, (newTrustedState, now) -} -``` - -If we get some trustedState at time t (now = t), - - -**VerifyAndUpdateNonRecursive.** TODO. -```go -func VerifyAndUpdateNonRecursive(untrustedHeight int64, - trustThreshold TrustThreshold, - trustingPeriod Duration, - clockDrift Duration, - now Time, - store Store) error { - - // fetch the latest state and ensure it hasn't expired - trustedState, error = get(store, 0) - if error != nil return error - - trustedSh = trustedState.SignedHeader - trustedHeader = trustedSh.Header - assert trustedHeader.Height < untrustedHeight AND - trustedHeader.Time < now - - if !isWithinTrustedPeriod(trustedHeader, trustingPeriod, now) { - return ErrHeaderNotWithinTrustedPeriod - } - - th := trustedHeader // th is trusted header - - untrustedSh, error := Commit(untrustedHeight) - if error != nil return error - - untrustedHeader = untrustedSh.Header - assert untrustedHeader.Time < now + clockDrift - - untrustedVs, error := Validators(untrustedHeight) - if error != nil return error - - untrustedNextVs, error := Validators(untrustedHeight + 1) - if error != nil return error - - // untrustedHeader is a list of headers that have not passed verifySingle - untrustedHeaders := [untrustedHeader] - - while true { - for h in untrustedHeaders { - // we assume here that iteration is done in the order of header heights - error = verifySingle( - trustedState, - untrustedSh, - untrustedVs, - untrustedNextVs, - trustThreshold) - - if err == nil { - // the untrusted header is now trusted. update the store - trustedState = TrustedState(untrustedSh, untrustedNextVs) - add(store, trustedState) - - untrustedHeaders.RemoveHeadersSmallerOrEqual(h.Header.Height) - if trustedState.SignedHeader.Header == untrustedSh.Header { - return nil - } - } - if fatalError(err) { return err } - } - - endHeight = min(untrustedHeaders) - while true { - trustedSh = trustedState.SignedHeader - trustedHeader = trustedSh.Header - pivotHeight := ceil((trustedHeader.Height + endHeight) / 2) - - untrustedSh, error := Commit(pivotHeight) - if error != nil return error - - untrustedHeader = untrustedSh.Header - assert untrustedHeader.Time < now + clockDrift - - untrustedVs, error := Validators(untrustedHeight) - if error != nil return error - - untrustedNextVs, error := Validators(untrustedHeight + 1) - if error != nil return error - - error = verifySingle( - trustedState, - untrustedSh, - untrustedVs, - untrustedNextVs, - trustThreshold) - - if fatalError(error) return error - - if err == nil { - trustedState = TrustedState(untrustedSh, untrustedNextVs) - add(store, trustedState) - break - } - - untrustedHeaders.add(untrustedHeader) - endHeight = pivot - } - } - return nil // this line should never be reached -} -``` - - - -The function `CanTrust` checks whether to trust header `untrusted_h` based on the trusted header `trusted_h` It does so by (potentially) -building transitive trust relation between `trusted_h` and `untrusted_h`, over some intermediate headers. For example, in case we cannot trust -header `untrusted_h` based on the trusted header `trusted_h`, the function `CanTrust` will try to find headers such that we can transition trust -from `trusted_h` over intermediate headers to `untrusted_h`. We will give two implementations of `CanTrust`, the one based -on bisection that is recursive and the other that is non-recursive. We give two implementations as recursive version might be easier -to understand but non-recursive version might be simpler to formally express and verify using TLA+/TLC. - -Both implementations of `CanTrust` function are based on `CheckSupport` function that implements the skipping conditions under which we can trust a -header `untrusted_h` given the trust in the header `trusted_h` as a single step, -i.e., it does not assume ensuring transitive trust relation between headers through some intermediate headers. - - -```go -// return nil in case we can trust header untrusted_h based on header trusted_h; otherwise return error -// where error captures the nature of the error. -// Note that untrusted_h must have been verified by the caller, i.e. verify(untrusted_h) was successful. -func CanTrust(trusted_h,untrusted_h,trustThreshold) error { - assert trusted_h.Header.Height < untrusted_h.header.Height - - th := trusted_h // th is trusted header - // untrustedHeader is a list of (?) verified headers that have not passed CheckSupport() - untrustedHeaders := [untrusted_h] - - while true { - for h in untrustedHeaders { - // we assume here that iteration is done in the order of header heights - err = CheckSupport(th,h,trustThreshold) - if err == nil { - if !verify(h) { return ErrInvalidHeader(h) } - th = h - Store.Add(h) - untrustedHeaders.RemoveHeadersSmallerOrEqual(h.Header.Height) - if th == untrusted_h { return nil } - } - if fatalCheckSupportError(err) { return err } - } - - endHeight = min(untrustedHeaders) - while true { - pivot := ceil((th.Header.height + endHeight) / 2) - hp := Commit(pivot) - // try to move trusted header forward to hp - err = CheckSupport(th,hp,trustThreshold) - if fatalCheckSupportError(err) return err - if err == nil { - if !verify(hp) { return ErrInvalidHeader(hp) } - th = hp - Store.Add(th) - break - } - untrustedHeaders.add(hp) - endHeight = pivot - } - } - return nil // this line should never be reached -} - -func CheckSupport(trusted_h,untrusted_h,trustThreshold) error { - assert trusted_h.Header.Height < untrusted_h.header.Height and - trusted_h.Header.bfttime < untrusted_h.Header.bfttime and - untrusted_h.Header.bfttime < now - - if !isWithinTrustedPeriod(trusted_h) return ErrHeaderNotWithinTrustedPeriod(trusted_h) - - // Although while executing the rest of CheckSupport function, trusted_h can expire based - // on the lite client trusted period, this is not problem as lite client trusted - // period is smaller than trusted period of the header based on Tendermint Failure - // model, i.e., there is a significant time period (measure in days) during which - // validator set that has signed trusted_h can be trusted. Furthermore, CheckSupport function - // is not doing expensive operation (neither rpc nor signature verification), so it - // should execute fast. - - // check for adjacent headers - if untrusted_h.Header.height == trusted_h.Header.height + 1 { - if trusted_h.Header.NextV == untrusted_h.Header.V - return nil - return ErrInvalidAdjacentHeaders - } - - // total sum of voting power of validators in trusted_h.NextV - vp_all := totalVotingPower(trusted_h.Header.NextV) - - // check for non-adjacent headers - if votingPowerIn(signers(untrusted_h.Commit),trusted_h.Header.NextV) > max(1/3,trustThreshold) * vp_all { - return nil - } - return ErrTooMuchChange -} - -func fatalCheckSupportError(err) bool { - return err == ErrHeaderNotWithinTrustedPeriod or err == ErrInvalidAdjacentHeaders -``` - -```go -func CanTrustBisection(trusted_h,untrusted_h,trustThreshold) error { - assume trusted_h.Header.Height < untrusted_h.header.Height - - err = CheckSupport(trusted_h,untrusted_h,trustThreshold) - if err == nil { - Store.Add(untrusted_h) - return nil - } - if err != ErrTooMuchChange return err - - pivot := (trusted_h.Header.height + untrusted_h.Header.height) / 2 - hp := Commit(pivot) - if !verify(hp) return ErrInvalidHeader(hp) - - err = CanTrustBisection(trusted_h,hp,trustThreshold) - if err == nil { - Store.Add(hp) - err2 = CanTrustBisection(hp,untrusted_h,trustThreshold) - if err2 == nil { - Store.Add(untrusted_h) - return nil - } - return err2 - } - return err -} -``` - -**CheckSupport.** The following function defines skipping condition under the Tendermint Failure model, i.e., it defines when we can trust the header untrusted_h based on header trusted_h. -Time validity of a header is captured by the ```isWithinTrustedPeriod``` function that depends on lite client trusted period (`LITE_CLIENT_TRUSTED_PERIOD`) and it returns -true in case the header is within its lite client trusted period. -```verify``` function is capturing basic header verification, i.e., it ensures that the header is signed by more than 2/3 of the voting power of the corresponding validator set. - -```go - // Captures skipping condition. trusted_h and untrusted_h have already passed basic validation - // (function `verify`). - // Returns nil in case untrusted_h can be trusted based on trusted_h, otherwise returns error. - // ErrHeaderNotWithinTrustedPeriod is used when trusted_h has expired with respect to lite client trusted period, - // ErrInvalidAdjacentHeaders when that adjacent headers are not consistent and - // ErrTooMuchChange when there is not enough intersection between validator sets to have - // skipping condition true. - func CheckSupport(trusted_h,untrusted_h,trustThreshold) error { - assert trusted_h.Header.Height < untrusted_h.header.Height and - trusted_h.Header.bfttime < untrusted_h.Header.bfttime and - untrusted_h.Header.bfttime < now - - if !isWithinTrustedPeriod(trusted_h) return ErrHeaderNotWithinTrustedPeriod(trusted_h) - - // Although while executing the rest of CheckSupport function, trusted_h can expire based - // on the lite client trusted period, this is not problem as lite client trusted - // period is smaller than trusted period of the header based on Tendermint Failure - // model, i.e., there is a significant time period (measure in days) during which - // validator set that has signed trusted_h can be trusted. Furthermore, CheckSupport function - // is not doing expensive operation (neither rpc nor signature verification), so it - // should execute fast. - - // check for adjacent headers - if untrusted_h.Header.height == trusted_h.Header.height + 1 { - if trusted_h.Header.NextV == untrusted_h.Header.V - return nil - return ErrInvalidAdjacentHeaders - } - - // total sum of voting power of validators in trusted_h.NextV - vp_all := totalVotingPower(trusted_h.Header.NextV) - - // check for non-adjacent headers - if votingPowerIn(signers(untrusted_h.Commit),trusted_h.Header.NextV) > max(1/3,trustThreshold) * vp_all { - return nil - } - return ErrTooMuchChange - } -``` - - -### The case `untrusted_h.Header.height < trusted_h.Header.height` - -In the use case where someone tells the lite client that application data that is relevant for it -can be read in the block of height `k` and the lite client trusts a more recent header, we can use the -hashes to verify headers "down the chain." That is, we iterate down the heights and check the hashes in each step. - -*Remark.* For the case were the lite client trusts two headers `i` and `j` with `i < k < j`, we should -discuss/experiment whether the forward or the backward method is more effective. - -```go -func Backwards(trusted_h,untrusted_h) error { - assert (untrusted_h.Header.height < trusted_h.Header.height) - if !isWithinTrustedPeriod(trusted_h) return ErrHeaderNotTrusted(trusted_h) - - old := trusted_h - for i := trusted_h.Header.height - 1; i > untrusted_h.Header.height; i-- { - new := Commit(i) - if (hash(new) != old.Header.hash) { - return ErrInvalidAdjacentHeaders - } - old := new - if !isWithinTrustedPeriod(trusted_h) return ErrHeaderNotTrusted(trusted_h) - } - if hash(untrusted_h) != old.Header.hash return ErrInvalidAdjacentHeaders - return nil - } -``` - - - -In order to incentivize correct behavior of validators that run Tendermint consensus protocol, fork detection protocol (it will be explained in different document) is executed in case of a fork (conflicting -headers are detected). As detecting conflicting headers, its propagation through the network (by the gossip protocol) and execution of the fork accountability -protocol on the chain takes time, the lite client logic assumes conservative value for trusted period. More precisely, in the context of lite client we always -operate with a smaller trusted period that we call *lite client trusted period* (LITE_CLIENT_TRUSTED_PERIOD). If we assume that upper bound -for fork detection, propagation and processing on the chain is denoted with *fork procession period* (FORK_PROCESSING_PERIOD), then the following formula -holds: -```LITE_CLIENT_TRUSTED_PERIOD + FORK_PROCESSING_PERIOD < TRUSTED_PERIOD```, where TRUSTED_PERIOD comes from the Tendermint Failure Model. - - -*Assumption*: In the following, we assume that *untrusted_h.Header.height > trusted_h.Header.height*. We will quickly discuss the other case in the next section. - -We consider the following set-up: -- the lite client communicates with one full node -- the lite client locally stores all the headers that has passed basic verification and that are within lite client trust period. In the pseudo code below we -write *Store.Add(header)* for this. If a header failed to verify, then -the full node we are talking to is faulty and we should disconnect from it and reinitialise with new peer. -- If `CanTrust` returns *error*, then the lite client has seen a forged header or the trusted header has expired (it is outside its trusted period). - * In case of forged header, the full node is faulty so lite client should disconnect and reinitialise with new peer. If the trusted header has expired, - we need to reinitialise lite client with new trusted header (that is within its trusted period), but we don't necessarily need to disconnect from the full node - we are talking to (as we haven't observed full node misbehavior in this case). - - - -## Context of this document - -In order to make sure that full nodes have the incentive to follow the protocol, we have to address the -following three Issues - -1) The lite client needs a method to verify headers it obtains from a full node it connects to according to trust assumptions -- this document. - -2) The lite client must be able to connect to other full nodes to detect and report on failures in the trust assumptions (i.e., conflicting headers) -- a future document (see #4215). - -3) In the event the trust assumption fails (i.e., a lite client is fooled by a conflicting header), the Tendermint fork accountability protocol must account for the evidence -- a future document (see #3840). - -The term "trusting" above indicates that the correctness of the protocol depends on -this assumption. It is in the responsibility of the user that runs the lite client to make sure that the risk -of trusting a corrupted/forged *inithead* is negligible. - -* For each header *h* it has locally stored, the lite client stores whether - it trusts *h*. We write *trust(h) = true*, if this is the case. - -* signed header fields: contains a header and a *commit* for the current header; a "seen commit". - In Tendermint consensus the "canonical commit" is stored in header *height* + 1. - - - * Validator fields. We will write a validator as a tuple *(v,p)* such that - + *v* is the identifier (we assume identifiers are unique in each validator set) - + *p* is its voting power - -### Definitions - -* *TRUSTED_PERIOD*: trusting period -* for realtime *t*, the predicate *correct(v,t)* is true if the validator *v* - follows the protocol until time *t* (we will see about recovery later). - - -### Tendermint Failure Model - -If a block *b* is generated at time *Time* (and this time is stored in the block), then a set of validators that -hold more than 2/3 of the voting power in ```validators(b.Header.NextValidatorsHash)``` is correct until time -```b.Header.Time + TRUSTED_PERIOD```. - -Formally, -\[ -\sum_{(v,p) \in h.Header.NextV \wedge correct(v,h.Header.bfttime + TRUSTED_PERIOD)} p > -2/3 \sum_{(v,p) \in h.Header.NextV} p -\] - - -## Lite Client Trusting Spec - -The lite client communicates with a full node and learns new headers. The goal is to locally decide whether to trust a header. Our implementation needs to ensure the following two properties: - -- Lite Client Completeness: If header *h* was correctly generated by an instance of Tendermint consensus (and its age is less than the trusting period), then the lite client should eventually set *trust(h)* to true. - -- Lite Client Accuracy: If header *h* was *not generated* by an instance of Tendermint consensus, then the lite client should never set *trust(h)* to true. - -*Remark*: If in the course of the computation, the lite client obtains certainty that some headers were forged by adversaries (that is were not generated by an instance of Tendermint consensus), it may submit (a subset of) the headers it has seen as evidence of misbehavior. - -*Remark*: In Completeness we use "eventually", while in practice *trust(h)* should be set to true before *h.Header.bfttime + tp*. If not, the block cannot be trusted because it is too old. - -*Remark*: If a header *h* is marked with *trust(h)*, but it is too old (its bfttime is more than *tp* ago), then the lite client should set *trust(h)* to false again. - -*Assumption*: Initially, the lite client has a header *inithead* that it trusts correctly, that is, *inithead* was correctly generated by the Tendermint consensus. - -To reason about the correctness, we may prove the following invariant. - -*Verification Condition: Lite Client Invariant.* - For each lite client *l* and each header *h*: -if *l* has set *trust(h) = true*, - then validators that are correct until time *h.Header.bfttime + tp* have more than two thirds of the voting power in *h.Header.NextV*. - - Formally, - \[ - \sum_{(v,p) \in h.Header.NextV \wedge correct(v,h.Header.bfttime + tp)} p > - 2/3 \sum_{(v,p) \in h.Header.NextV} p - \] - -*Remark.* To prove the invariant, we will have to prove that the lite client only trusts headers that were correctly generated by Tendermint consensus, then the formula above follows from the Tendermint failure model. - - -## High Level Solution - -Upon initialization, the lite client is given a header *inithead* it trusts (by -social consensus). It is assumed that *inithead* satisfies the lite client invariant. (If *inithead* has been correctly generated by Tendermint consensus, the invariant follows from the Tendermint Failure Model.) -Note that the *inithead* should be within its trusted period during initialization. - -When a lite clients sees a signed new header *snh*, it has to decide whether to trust the new -header. Trust can be obtained by (possibly) the combination of three methods. - -1. **Uninterrupted sequence of proof.** If a block is appended to the chain, where the last block -is trusted (and properly committed by the old validator set in the next block), -and the new block contains a new validator set, the new block is trusted if the lite client knows all headers in the prefix. -Intuitively, a trusted validator set is assumed to only chose a new validator set that will obey the Tendermint Failure Model. - -2. **Trusting period.** Based on a trusted block *h*, and the lite client -invariant, which ensures the fault assumption during the trusting period, we can check whether at least one validator, that has been continuously correct from *h.Header.bfttime* until now, has signed *snh*. -If this is the case, similarly to above, the chosen validator set in *snh* does not violate the Tendermint Failure Model. - -3. **Bisection.** If a check according to the trusting period fails, the lite client can try to obtain a header *hp* whose height lies between *h* and *snh* in order to check whether *h* can be used to get trust for *hp*, and *hp* can be used to get trust for *snh*. If this is the case we can trust *snh*; if not, we may continue recursively. - -## How to use it - -We consider the following use case: - the lite client wants to verify a header for some given height *k*. Thus: - - it requests the signed header for height *k* from a full node - - it tries to verify this header with the methods described here. - -This can be used in several settings: - - someone tells the lite client that application data that is relevant for it can be read in the block of height *k*. - - the lite clients wants the latest state. It asks a full nude for the current height, and uses the response for *k*. - - in case of inter-blockchain communication protocol (IBC) the light client runs on a chain and someone feeds it - signed headers as input and it computes whether it can trust it. - - -## Details - -**Observation 1.** If *h.Header.bfttime + tp > now*, we trust the old -validator set *h.Header.NextV*. - -When we say we trust *h.Header.NextV* we do *not* trust that each individual validator in *h.Header.NextV* is correct, -but we only trust the fact that less than 1/3 of them are faulty (more precisely, the faulty ones have less than 1/3 of the total voting power). - - - -*Correctness arguments* - -Towards Lite Client Accuracy: -- Assume by contradiction that `untrusted_h` was not generated correctly and the lite client sets trust to true because `CheckSupport` returns true. -- trusted_h is trusted and sufficiently new -- by Tendermint Fault Model, less than 1/3 of voting power held by faulty validators => at least one correct validator *v* has signed `untrusted_h`. -- as *v* is correct up to now, it followed the Tendermint consensus protocol at least up to signing `untrusted_h` => `untrusted_h` was correctly generated, we arrive at the required contradiction. - - -Towards Lite Client Completeness: -- The check is successful if sufficiently many validators of `trusted_h` are still validators in `untrusted_h` and signed `untrusted_h`. -- If *untrusted_h.Header.height = trusted_h.Header.height + 1*, and both headers were generated correctly, the test passes - -*Verification Condition:* We may need a Tendermint invariant stating that if *untrusted_h.Header.height = trusted_h.Header.height + 1* then *signers(untrusted_h.Commit) \subseteq trusted_h.Header.NextV*. - -*Remark*: The variable *trustThreshold* can be used if the user believes that relying on one correct validator is not sufficient. However, in case of (frequent) changes in the validator set, the higher the *trustThreshold* is chosen, the more unlikely it becomes that CheckSupport returns true for non-adjacent headers. - - - - -*Correctness arguments (sketch)* - -Lite Client Accuracy: -- Assume by contradiction that `untrusted_h` was not generated correctly and the lite client sets trust to true because CanTrustBisection returns nil. -- CanTrustBisection returns true only if all calls to CheckSupport in the recursion return nil. -- Thus we have a sequence of headers that all satisfied the CheckSupport -- again a contradiction - -Lite Client Completeness: - -This is only ensured if upon *Commit(pivot)* the lite client is always provided with a correctly generated header. - -*Stalling* - -With CanTrustBisection, a faulty full node could stall a lite client by creating a long sequence of headers that are queried one-by-one by the lite client and look OK, before the lite client eventually detects a problem. There are several ways to address this: -* Each call to ```Commit``` could be issued to a different full node -* Instead of querying header by header, the lite client tells a full node which header it trusts, and the height of the header it needs. The full node responds with the header along with a proof consisting of intermediate headers that the light client can use to verify. Roughly, Bisection would then be executed at the full node. -* We may set a timeout how long bisection may take. - - - - - diff --git a/spec/consensus/non-recursive-light-client.md b/spec/consensus/non-recursive-light-client.md deleted file mode 100644 index b95815f47..000000000 --- a/spec/consensus/non-recursive-light-client.md +++ /dev/null @@ -1,3 +0,0 @@ -# Non Recursive Verification - MOVED! - -Non Recursive verification has moved to [light](./light).