You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

329 lines
18 KiB

Updated lite client spec (#3841) * updates lite cline spec based on Zarko's and my previous specs * updates spec incorporating comments from Aug 8 meeting * added check of validators * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * fix typos & improve formatting Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anton Kaliaev <anton.kalyaev@gmail.com> * incorporated some of Anca's and Anton's comments * addressed all current comments * highlight assumptions/verification conditions * added remark on checks * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * fixes * addressed Ethan's comments from Aug 18 * trustlevel * description of 3 docs fixed * added comment on justification asked for by Anca * bla * removed trustlevel for adjacent headers. Added bisection order. * added comment in bisection * fixed comment in checksupport * added comment on bisection timeout
5 years ago
Updated lite client spec (#3841) * updates lite cline spec based on Zarko's and my previous specs * updates spec incorporating comments from Aug 8 meeting * added check of validators * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * fix typos & improve formatting Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anton Kaliaev <anton.kalyaev@gmail.com> * incorporated some of Anca's and Anton's comments * addressed all current comments * highlight assumptions/verification conditions * added remark on checks * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * fixes * addressed Ethan's comments from Aug 18 * trustlevel * description of 3 docs fixed * added comment on justification asked for by Anca * bla * removed trustlevel for adjacent headers. Added bisection order. * added comment in bisection * fixed comment in checksupport * added comment on bisection timeout
5 years ago
Updated lite client spec (#3841) * updates lite cline spec based on Zarko's and my previous specs * updates spec incorporating comments from Aug 8 meeting * added check of validators * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * fix typos & improve formatting Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anton Kaliaev <anton.kalyaev@gmail.com> * incorporated some of Anca's and Anton's comments * addressed all current comments * highlight assumptions/verification conditions * added remark on checks * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * fixes * addressed Ethan's comments from Aug 18 * trustlevel * description of 3 docs fixed * added comment on justification asked for by Anca * bla * removed trustlevel for adjacent headers. Added bisection order. * added comment in bisection * fixed comment in checksupport * added comment on bisection timeout
5 years ago
Updated lite client spec (#3841) * updates lite cline spec based on Zarko's and my previous specs * updates spec incorporating comments from Aug 8 meeting * added check of validators * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * fix typos & improve formatting Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anton Kaliaev <anton.kalyaev@gmail.com> * incorporated some of Anca's and Anton's comments * addressed all current comments * highlight assumptions/verification conditions * added remark on checks * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * fixes * addressed Ethan's comments from Aug 18 * trustlevel * description of 3 docs fixed * added comment on justification asked for by Anca * bla * removed trustlevel for adjacent headers. Added bisection order. * added comment in bisection * fixed comment in checksupport * added comment on bisection timeout
5 years ago
Updated lite client spec (#3841) * updates lite cline spec based on Zarko's and my previous specs * updates spec incorporating comments from Aug 8 meeting * added check of validators * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * fix typos & improve formatting Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anton Kaliaev <anton.kalyaev@gmail.com> * incorporated some of Anca's and Anton's comments * addressed all current comments * highlight assumptions/verification conditions * added remark on checks * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * fixes * addressed Ethan's comments from Aug 18 * trustlevel * description of 3 docs fixed * added comment on justification asked for by Anca * bla * removed trustlevel for adjacent headers. Added bisection order. * added comment in bisection * fixed comment in checksupport * added comment on bisection timeout
5 years ago
Updated lite client spec (#3841) * updates lite cline spec based on Zarko's and my previous specs * updates spec incorporating comments from Aug 8 meeting * added check of validators * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * fix typos & improve formatting Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anton Kaliaev <anton.kalyaev@gmail.com> * incorporated some of Anca's and Anton's comments * addressed all current comments * highlight assumptions/verification conditions * added remark on checks * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * fixes * addressed Ethan's comments from Aug 18 * trustlevel * description of 3 docs fixed * added comment on justification asked for by Anca * bla * removed trustlevel for adjacent headers. Added bisection order. * added comment in bisection * fixed comment in checksupport * added comment on bisection timeout
5 years ago
Updated lite client spec (#3841) * updates lite cline spec based on Zarko's and my previous specs * updates spec incorporating comments from Aug 8 meeting * added check of validators * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * fix typos & improve formatting Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anton Kaliaev <anton.kalyaev@gmail.com> * incorporated some of Anca's and Anton's comments * addressed all current comments * highlight assumptions/verification conditions * added remark on checks * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * fixes * addressed Ethan's comments from Aug 18 * trustlevel * description of 3 docs fixed * added comment on justification asked for by Anca * bla * removed trustlevel for adjacent headers. Added bisection order. * added comment in bisection * fixed comment in checksupport * added comment on bisection timeout
5 years ago
Updated lite client spec (#3841) * updates lite cline spec based on Zarko's and my previous specs * updates spec incorporating comments from Aug 8 meeting * added check of validators * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * fix typos & improve formatting Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com> * Update docs/spec/consensus/light-client.md Co-Authored-By: Anton Kaliaev <anton.kalyaev@gmail.com> * incorporated some of Anca's and Anton's comments * addressed all current comments * highlight assumptions/verification conditions * added remark on checks * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/consensus/light-client.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * fixes * addressed Ethan's comments from Aug 18 * trustlevel * description of 3 docs fixed * added comment on justification asked for by Anca * bla * removed trustlevel for adjacent headers. Added bisection order. * added comment in bisection * fixed comment in checksupport * added comment on bisection timeout
5 years ago
  1. # Lite client
  2. A lite client is a process that connects to Tendermint full nodes and then tries to verify application data using the Merkle proofs.
  3. ## Context of this document
  4. In order to make sure that full nodes have the incentive to follow the protocol, we have to address the following three Issues
  5. 1) The lite client needs a method to verify headers it obtains from full nodes according to trust assumptions -- this document.
  6. 2) The lite client must be able to connect to one correct full node to detect and report on failures in the trust assumptions (i.e., conflicting headers) -- a future document.
  7. 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 -- see #3840
  8. ## Problem statement
  9. 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*.
  10. The correctness of the protocol is based on the assumption that *inithead* was generated by an instance of Tendermint consensus. The term "trusting" above indicates that the correctness on 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.
  11. ## Definitions
  12. ### Data structures
  13. In the following, only the details of the data structures needed for this specification are given.
  14. * header fields
  15. - *height*
  16. - *bfttime*: the chain time when the header (block) was generated
  17. - *V*: validator set containing validators for this block.
  18. - *NextV*: validator set for next block.
  19. - *commit*: evidence that block with height *height* - 1 was committed by a set of validators (canonical commit). We will use ```signers(commit)``` to refer to the set of validators that committed the block.
  20. * signed header fields: contains a header and a *commit* for the current header; a "seen commit". In the Tendermint consensus the "canonical commit" is stored in header *height* + 1.
  21. * For each header *h* it has locally stored, the lite client stores whether
  22. it trusts *h*. We write *trust(h) = true*, if this is the case.
  23. * Validator fields. We will write a validator as a tuple *(v,p)* such that
  24. + *v* is the identifier (we assume identifiers are unique in each validator set)
  25. + *p* is its voting power
  26. ### Functions
  27. For the purpose of this lite client specification, we assume that the Tendermint Full Node exposes the following function over Tendermint RPC:
  28. ```go
  29. func Commit(height int64) (SignedHeader, error)
  30. // returns signed header: header (with the fields from
  31. // above) with Commit that include signatures of
  32. // validators that signed the header
  33. type SignedHeader struct {
  34. Header Header
  35. Commit Commit
  36. }
  37. ```
  38. ### Definitions
  39. * *tp*: trusting period
  40. * for realtime *t*, the predicate *correct(v,t)* is true if the validator *v*
  41. follows the protocol until time *t* (we will see about recovery later).
  42. ### Tendermint Failure Model
  43. If a block *h* is generated at time *bfttime* (and this time is stored in the block), then a set of validators that hold more than 2/3 of the voting power in h.Header.NextV is correct until time h.Header.bfttime + tp.
  44. Formally,
  45. \[
  46. \sum_{(v,p) \in h.Header.NextV \wedge correct(v,h.Header.bfttime + tp)} p >
  47. 2/3 \sum_{(v,p) \in h.Header.NextV} p
  48. \]
  49. *Assumption*: "correct" is defined w.r.t. realtime (some Newtonian global notion of time, i.e., wall time), while *bfttime* corresponds to the reading of the local clock of a validator (how this time is computed may change when the Tendermint consensus is modified). In this note, we assume that all clocks are synchronized to realtime. We can make this more precise eventually (incorporating clock drift, accuracy, precision, etc.). Right now, we consider this assumption sufficient, as clock synchronization (under NTP) is in the order of milliseconds and *tp* is in the order of weeks.
  50. *Remark*: This failure model might change to a hybrid version that takes heights into account in the future.
  51. The specification in this document considers an implementation of the lite client under this assumption. Issues like *counter-factual signing* and *fork accountability* and *evidence submission* are mechanisms that justify this assumption by incentivizing validators to follow the protocol.
  52. If they don't, and we have more that 1/3 faults, 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 an upcoming document on "Fork accountability". (These safety violations include the lite client wrongly trusting a header, a fork in the blockchain, etc.)
  53. ## Lite Client Trusting Spec
  54. 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:
  55. - 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.
  56. - 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.
  57. *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.
  58. *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.
  59. *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.
  60. *Assumption*: Initially, the lite client has a header *inithead* that it trusts correctly, that is, *inithead* was correctly generated by the Tendermint consensus.
  61. To reason about the correctness, we may prove the following invariant.
  62. *Verification Condition: Lite Client Invariant.*
  63. For each lite client *l* and each header *h*:
  64. if *l* has set *trust(h) = true*,
  65. then validators that are correct until time *h.Header.bfttime + tp* have more than two thirds of the voting power in *h.Header.NextV*.
  66. Formally,
  67. \[
  68. \sum_{(v,p) \in h.Header.NextV \wedge correct(v,h.Header.bfttime + tp)} p >
  69. 2/3 \sum_{(v,p) \in h.Header.NextV} p
  70. \]
  71. *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.
  72. ## High Level Solution
  73. Upon initialization, the lite client is given a header *inithead* it trusts (by
  74. 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.)
  75. When a lite clients sees a signed new header *snh*, it has to decide whether to trust the new
  76. header. Trust can be obtained by (possibly) the combination of three methods.
  77. 1. **Uninterrupted sequence of proof.** If a block is appended to the chain, where the last block
  78. is trusted (and properly committed by the old validator set in the next block),
  79. and the new block contains a new validator set, the new block is trusted if the lite client knows all headers in the prefix.
  80. Intuitively, a trusted validator set is assumed to only chose a new validator set that will obey the Tendermint Failure Model.
  81. 2. **Trusting period.** Based on a trusted block *h*, and the lite client
  82. 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*.
  83. If this is the case, similarly to above, the chosen validator set in *snh* does not violate the Tendermint Failure Model.
  84. 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.
  85. ## How to use it
  86. We consider the following use case:
  87. the lite client wants to verify a header for some given height *k*. Thus:
  88. - it requests the signed header for height *k* from a full node
  89. - it tries to verify this header with the methods described here.
  90. This can be used in several settings:
  91. - someone tells the lite client that application data that is relevant for it can be read in the block of height *k*.
  92. - the lite clients wants the latest state. It asks a full nude for the current height, and uses the response for *k*.
  93. ## Details
  94. *Assumptions*
  95. 1. *tp < unbonding period*.
  96. 2. *snh.Header.bfttime < now*
  97. 3. *snh.Header.bfttime < h.Header.bfttime+tp*
  98. 4. *trust(h)=true*
  99. **Observation 1.** If *h.Header.bfttime + tp > now*, we trust the old
  100. validator set *h.Header.NextV*.
  101. 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 at most 1/3 of them are faulty (more precisely, the faulty ones have at most 1/3 of the total voting power).
  102. ### Functions
  103. The function *Bisection* checks whether to trust header *h2* based on the trusted header *h1*. It does so by calling
  104. the function *CheckSupport* in the process of
  105. bisection/recursion. *CheckSupport* implements the trusted period method and, for two adjacent headers (in term of heights), it checks uninterrupted sequence of proof.
  106. *Assumption*: In the following, we assume that *h2.Header.height > h1.Header.height*. We will quickly discuss the other case in the next section.
  107. We consider the following set-up:
  108. - the lite client communicates with one full node
  109. - the lite client locally stores all the signed headers it obtained (trusted or not). In the pseudo code below we write *Store(header)* for this.
  110. - If *Bisection* returns *false*, then the lite client has seen a forged header.
  111. * However, it does not know which header(s) is/are the problematic one(s).
  112. * In this case, the lite client can submit (some of) the headers it has seen as evidence. As the lite client communicates with one full node only when executing Bisection, there are two cases
  113. - the full node is faulty
  114. - the full node is correct and there was a fork in Tendermint consensus. Header *h1* is from a different branch than the one taken by the full node. This case is not focus of this document, but will be treated in the document on fork accountability.
  115. - the lite client must retry to retrieve correct headers from another full node
  116. * it picks a new full node
  117. * it restarts *Bisection*
  118. * there might be optimizations; a lite client may not need to call *Commit(k)*, for a height *k* for which it already has a signed header it trusts.
  119. * how to make sure that a lite client can communicate with a correct full node will be the focus of a separate document (recall Issue 3 from "Context of this document").
  120. **Auxiliary Functions.** We will use the function ```votingpower_in(V1,V2)``` to compute the voting power the validators in set V1 have according to their voting power in set V2;
  121. we will write ```totalVotingPower(V)``` for ```votingpower_in(V,V)```, which returns the total voting power in V.
  122. We further use the function ```signers(Commit)``` that returns the set of validators that signed the Commit.
  123. **CheckSupport.** The following function checks whether we can trust the header h2 based on header h1 following the trusting period method.
  124. ```go
  125. func CheckSupport(h1,h2,trustlevel) bool {
  126. if h1.Header.bfttime + tp < now { // Observation 1
  127. return false // old header was once trusted but it is expired
  128. }
  129. vp_all := totalVotingPower(h1.Header.NextV)
  130. // total sum of voting power of validators in h2
  131. if h2.Header.height == h1.Header.height + 1 {
  132. // specific check for adjacent headers; everything must be
  133. // properly signed.
  134. // also check that h2.Header.V == h1.Header.NextV
  135. // Plus the following check that 2/3 of the voting power
  136. // in h1 signed h2
  137. return (votingpower_in(signers(h2.Commit),h1.Header.NextV) >
  138. 2/3 * vp_all)
  139. // signing validators are more than two third in h1.
  140. }
  141. return (votingpower_in(signers(h2.Commit),h1.Header.NextV) >
  142. max(1/3,trustlevel) * vp_all)
  143. // get validators in h1 that signed h2
  144. // sum of voting powers in h1 of
  145. // validators that signed h2
  146. // is more than a third in h1
  147. }
  148. ```
  149. *Remark*: Basic header verification must be done for *h2*. Similar checks are done in:
  150. https://github.com/tendermint/tendermint/blob/master/types/validator_set.go#L591-L633
  151. *Remark*: There are some sanity checks which are not in the code:
  152. *h2.Header.height > h1.Header.height* and *h2.Header.bfttime > h1.Header.bfttime* and *h2.Header.bfttime < now*.
  153. *Remark*: ```return (votingpower_in(signers(h2.Commit),h1.Header.NextV) > max(1/3,trustlevel) * vp_all)``` may return false even if *h2* was properly generated by Tendermint consensus in the case of big changes in the validator sets. However, the check ```return (votingpower_in(signers(h2.Commit),h1.Header.NextV) >
  154. 2/3 * vp_all)``` must return true if *h1* and *h2* were generated by Tendermint consensus.
  155. *Remark*: The 1/3 check differs from a previously proposed method that was based on intersecting validator sets and checking that the new validator set contains "enough" correct validators. We found that the old check is not suited for realistic changes in the validator sets. The new method is not only based on cardinalities, but also exploits that we can trust what is signed by a correct validator (i.e., signed by more than 1/3 of the voting power).
  156. *Correctness arguments*
  157. Towards Lite Client Accuracy:
  158. - Assume by contradiction that *h2* was not generated correctly and the lite client sets trust to true because *CheckSupport* returns true.
  159. - h1 is trusted and sufficiently new
  160. - by Tendermint Fault Model, less than 1/3 of voting power held by faulty validators => at least one correct validator *v* has signed *h2*.
  161. - as *v* is correct up to now, it followed the Tendermint consensus protocol at least up to signing *h2* => *h2* was correctly generated, we arrive at the required contradiction.
  162. Towards Lite Client Completeness:
  163. - The check is successful if sufficiently many validators of *h1* are still validators in *h2* and signed *h2*.
  164. - If *h2.Header.height = h1.Header.height + 1*, and both headers were generated correctly, the test passes
  165. *Verification Condition:* We may need a Tendermint invariant stating that if *h2.Header.height = h1.Header.height + 1* then *signers(h2.Commit) \subseteq h1.Header.NextV*.
  166. *Remark*: The variable *trustlevel* 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 *trustlevel* is chosen, the more unlikely it becomes that CheckSupport returns true for non-adjacent headers.
  167. **Bisection.** The following function uses CheckSupport in a recursion to find intermediate headers that allow to establish a sequence of trust.
  168. ```go
  169. func Bisection(h1,h2,trustlevel) bool{
  170. if CheckSupport(h1,h2,trustlevel) {
  171. return true
  172. }
  173. if h2.Header.height == h1.Header.height + 1 {
  174. // we have adjacent headers that are not matching (failed
  175. // the CheckSupport)
  176. // we could submit evidence here
  177. return false
  178. }
  179. pivot := (h1.Header.height + h2.Header.height) / 2
  180. hp := Commit(pivot)
  181. // ask a full node for header of height pivot
  182. Store(hp)
  183. // store header hp locally
  184. if Bisection(h1,hp,trustlevel) {
  185. // only check right branch if hp is trusted
  186. // (otherwise a lot of unnecessary computation may be done)
  187. return Bisection(hp,h2,trustlevel)
  188. }
  189. else {
  190. return false
  191. }
  192. }
  193. ```
  194. *Correctness arguments (sketch)*
  195. Lite Client Accuracy:
  196. - Assume by contradiction that *h2* was not generated correctly and the lite client sets trust to true because Bisection returns true.
  197. - Bisection returns true only if all calls to CheckSupport in the recursion return true.
  198. - Thus we have a sequence of headers that all satisfied the CheckSupport
  199. - again a contradiction
  200. Lite Client Completeness:
  201. This is only ensured if upon *Commit(pivot)* the lite client is always provided with a correctly generated header.
  202. *Stalling*
  203. With Bisection, 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:
  204. * Each call to ```Commit``` could be issued to a different full node
  205. * 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.
  206. * We may set a timeout how long bisection may take.
  207. ### The case *h2.Header.height < h1.Header.height*
  208. 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.
  209. *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.
  210. ```go
  211. func Backwards(h1,h2) bool {
  212. assert (h2.Header.height < h1.Header.height)
  213. old := h1
  214. for i := h1.Header.height - 1; i > h2.Header.height; i-- {
  215. new := Commit(i)
  216. Store(new)
  217. if (hash(new) != old.Header.hash) {
  218. return false
  219. }
  220. old := new
  221. }
  222. return (hash(h2) == old.Header.hash)
  223. }
  224. ```