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.

254 lines
13 KiB

  1. # ADR 047: Handling evidence from light client
  2. ## Changelog
  3. * 18-02-2020: Initial draft
  4. * 24-02-2020: Second version
  5. * 13-04-2020: Add PotentialAmnesiaEvidence and a few remarks
  6. * 31-07-2020: Remove PhantomValidatorEvidence
  7. * 14-08-2020: Introduce light traces (listed now as an alternative approach)
  8. * 20-08-2020: Light client produces evidence when detected instead of passing to full node
  9. * 16-09-2020: Post-implementation revision
  10. * 15-03-2020: Ammends for the case of a forward lunatic attack
  11. ### Glossary of Terms
  12. - a `LightBlock` is the unit of data that a light client receives, verifies and stores.
  13. It is composed of a validator set, commit and header all at the same height.
  14. - a **Trace** is seen as an array of light blocks across a range of heights that were
  15. created as a result of skipping verification.
  16. - a **Provider** is a full node that a light client is connected to and serves the light
  17. client signed headers and validator sets.
  18. - `VerifySkipping` (sometimes known as bisection or verify non-adjacent) is a method the
  19. light client uses to verify a target header from a trusted header. The process involves verifying
  20. intermediate headers in between the two by making sure that 1/3 of the validators that signed
  21. the trusted header also signed the untrusted one.
  22. - **Light Bifurcation Point**: If the light client was to run `VerifySkipping` with two providers
  23. (i.e. a primary and a witness), the bifurcation point is the height that the headers
  24. from each of these providers are different yet valid. This signals that one of the providers
  25. may be trying to fool the light client.
  26. ## Context
  27. The bisection method of header verification used by the light client exposes
  28. itself to a potential attack if any block within the light clients trusted period has
  29. a malicious group of validators with power that exceeds the light clients trust level
  30. (default is 1/3). To improve light client (and overall network) security, the light
  31. client has a detector component that compares the verified header provided by the
  32. primary against witness headers. This ADR outlines the process of mitigating attacks
  33. on the light client by using witness nodes to cross reference with.
  34. ## Alternative Approaches
  35. A previously discussed approach to handling evidence was to pass all the data that the
  36. light client had witnessed when it had observed diverging headers for the full node to
  37. process.This was known as a light trace and had the following structure:
  38. ```go
  39. type ConflictingHeadersTrace struct {
  40. Headers []*types.SignedHeader
  41. }
  42. ```
  43. This approach has the advantage of not requiring as much processing on the light
  44. client side in the event that an attack happens. Although, this is not a significant
  45. difference as the light client would in any case have to validate all the headers
  46. from both witness and primary. Using traces would consume a large amount of bandwidth
  47. and adds a DDOS vector to the full node.
  48. ## Decision
  49. The light client will be divided into two components: a `Verifier` (either sequential or
  50. skipping) and a `Detector` (see [Informal's Detector](https://github.com/informalsystems/tendermint-rs/blob/master/docs/spec/lightclient/detection/detection.md))
  51. . The detector will take the trace of headers from the primary and check it against all
  52. witnesses. For a witness with a diverging header, the detector will first verify the header
  53. by bisecting through all the heights defined by the trace that the primary provided. If valid,
  54. the light client will trawl through both traces and find the point of bifurcation where it
  55. can proceed to extract any evidence (as is discussed in detail later).
  56. Upon successfully detecting the evidence, the light client will send it to both primary and
  57. witness before halting. It will not send evidence to other peers nor continue to verify the
  58. primary's header against any other header.
  59. ## Detailed Design
  60. The verification process of the light client will start from a trusted header and use a bisectional
  61. algorithm to verify up to a header at a given height. This becomes the verified header (does not
  62. mean that it is trusted yet). All headers that were verified in between are cached and known as
  63. intermediary headers and the entire array is sometimes referred to as a trace.
  64. The light client's detector then takes all the headers and runs the detect function.
  65. ```golang
  66. func (c *Client) detectDivergence(primaryTrace []*types.LightBlock, now time.Time) error
  67. ```
  68. The function takes the last header it received, the target header and compares it against all the witnesses
  69. it has through the following function:
  70. ```golang
  71. func (c *Client) compareNewHeaderWithWitness(errc chan error, h *types.SignedHeader,
  72. witness provider.Provider, witnessIndex int)
  73. ```
  74. The err channel is used to send back all the outcomes so that they can be processed in parallel.
  75. Invalid headers result in dropping the witness, lack of response or not having the headers is ignored
  76. just as headers that have the same hash. Headers, however,
  77. of a different hash then trigger the detection process between the primary and that particular witness.
  78. This begins with verification of the witness's header via skipping verification which is run in tande
  79. with locating the Light Bifurcation Point
  80. ![](../imgs/light-client-detector.png)
  81. This is done with:
  82. ```golang
  83. func (c *Client) examineConflictingHeaderAgainstTrace(
  84. trace []*types.LightBlock,
  85. targetBlock *types.LightBlock,
  86. source provider.Provider,
  87. now time.Time,
  88. ) ([]*types.LightBlock, *types.LightBlock, error)
  89. ```
  90. which performs the following
  91. 1. Checking that the trusted header is the same. Currently, they should not theoretically be different
  92. because witnesses cannot be added and removed after the client is initialized. But we do this any way
  93. as a sanity check. If this fails we have to drop the witness.
  94. 2. Querying and verifying the witness's headers using bisection at the same heights of all the
  95. intermediary headers of the primary (In the above example this is A, B, C, D, F, H). If bisection fails
  96. or the witness stops responding then we can call the witness faulty and drop it.
  97. 3. We eventually reach a verified header by the witness which is not the same as the intermediary header
  98. (In the above example this is E). This is the point of bifurcation (This could also be the last header).
  99. 4. There is a unique case where the trace that is being examined against has blocks that have a greater
  100. height than the targetBlock. This can occur as part of a forward lunatic attack where the primary has
  101. provided a light block that has a height greater than the head of the chain (see Appendix B). In this
  102. case, the light client will verify the sources blocks up to the targetBlock and return the block in the
  103. trace that is directly after the targetBlock in height as the `ConflictingBlock`
  104. This function then returns the trace of blocks from the witness node between the common header and the
  105. divergent header of the primary as it is likely, as seen in the example to the right, that multiple
  106. headers where required in order to verify the divergent one. This trace will
  107. be used later (as is also described later in this document).
  108. ![](../imgs/bifurcation-point.png)
  109. Now, that an attack has been detected, the light client must form evidence to prove it. There are
  110. three types of attacks that either the primary or witness could have done to try fool the light client
  111. into verifying the wrong header: Lunatic, Equivocation and Amnesia. As the consequence is the same and
  112. the data required to prove it is also very similar, we bundle these attack styles together in a single
  113. evidence:
  114. ```golang
  115. type LightClientAttackEvidence struct {
  116. ConflictingBlock *LightBlock
  117. CommonHeight int64
  118. }
  119. ```
  120. The light client takes the stance of first suspecting the primary. Given the bifurcation point found
  121. above, it takes the two divergent headers and compares whether the one from the primary is valid with
  122. respect to the one from the witness. This is done by calling `isInvalidHeader()` which looks to see if
  123. any one of the deterministically derived header fields differ from one another. This could be one of
  124. `ValidatorsHash`, `NextValidatorsHash`, `ConsensusHash`, `AppHash`, and `LastResultsHash`.
  125. In this case we know it's a Lunatic attack and to help the witness verify it we send the height
  126. of the common header which is 1 in the example above or C in the example above that. If all these
  127. hashes are the same then we can infer that it is either Equivocation or Amnesia. In this case we send
  128. the height of the diverged headers because we know that the validator sets are the same, hence the
  129. malicious nodes are still bonded at that height. In the example above, this is height 10 and the
  130. example above that it is the height at E.
  131. The light client now has the evidence and broadcasts it to the witness.
  132. However, it could have been that the header the light client used from the witness against the primary
  133. was forged, so before halting the light client swaps the process and thus suspects the witness and
  134. uses the primary to create evidence. It calls `examineConflictingHeaderAgainstTrace` this time using
  135. the witness trace found earlier.
  136. If the primary was malicious it is likely that it will not respond but if it is innocent then the
  137. light client will produce the same evidence but this time the conflicting
  138. block will come from the witness node instead of the primary. The evidence is then formed and sent to
  139. the primary node.
  140. This then ends the process and the verify function that was called at the start returns the error to
  141. the user.
  142. For a detailed overview of how each of these three attacks can be conducted please refer to the
  143. [fork accountability spec]((https://github.com/tendermint/spec/blob/master/spec/consensus/light-client/accountability.md)).
  144. ## Full Node Verification
  145. When a full node receives evidence from the light client it will need to verify
  146. it for itself before gossiping it to peers and trying to commit it on chain. This process is outlined
  147. in [ADR-059](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-059-evidence-composition-and-lifecycle.md).
  148. ## Status
  149. Implemented.
  150. ## Consequences
  151. ### Positive
  152. * Light client has increased security against Lunatic, Equivocation and Amnesia attacks.
  153. * Do not need intermediate data structures to encapsulate the malicious behavior
  154. * Generalized evidence makes the code simpler
  155. ### Negative
  156. * Breaking change on the light client from versions 0.33.8 and below. Previous
  157. versions will still send `ConflictingHeadersEvidence` but it won't be recognized
  158. by the full node. Light clients will however still refuse the header and shut down.
  159. * Amnesia attacks although detected, will not be able to be punished as it is not
  160. clear from the current information which nodes behaved maliciously.
  161. * Evidence module must handle both individual and grouped evidence.
  162. ### Neutral
  163. ## References
  164. * [Fork accountability spec](https://github.com/tendermint/spec/blob/master/spec/consensus/light-client/accountability.md)
  165. * [ADR 056: Light client amnesia attacks](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-056-light-client-amnesia-attacks.md)
  166. * [ADR-059: Evidence Composition and Lifecycle](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-059-evidence-composition-and-lifecycle.md)
  167. * [Informal's Light Client Detector](https://github.com/informalsystems/tendermint-rs/blob/master/docs/spec/lightclient/detection/detection.md)
  168. ## Appendix A
  169. PhantomValidatorEvidence was used to capture when a validator that was still staked
  170. (i.e. within the bonded period) but was not in the current validator set had voted for a block.
  171. In later discussions it was argued that although possible to keep phantom validator
  172. evidence, any case a phantom validator that could have the capacity to be involved
  173. in fooling a light client would have to be aided by 1/3+ lunatic validators.
  174. It would also be very unlikely that the new validators injected by the lunatic attack
  175. would be validators that currently still have something staked.
  176. Not only this but there was a large degree of extra computation required in storing all
  177. the currently staked validators that could possibly fall into the group of being
  178. a phantom validator. Given this, it was removed.
  179. ## Appendix B
  180. A unique flavor of lunatic attack is a forward lunatic attack. This is where a malicious
  181. node provides a header with a height greater than the height of the blockchain. Thus there
  182. are no witnesses capable of rebutting the malicious header. Such an attack will also
  183. require an accomplice, i.e. at least one other witness to also return the same forged header.
  184. Although such attacks can be any arbitrary height ahead, they must still remain within the
  185. clock drift of the light clients real time. Therefore, to detect such an attack, a light
  186. client will wait for a time
  187. ```
  188. 2 * MAX_CLOCK_DRIFT + LAG
  189. ```
  190. for a witness to provide the latest block it has. Given the time constraints, if the witness
  191. is operating at the head of the blockchain, it will have a header with an earlier height but
  192. a later timestamp. This can be used to prove that the primary has submitted a lunatic header
  193. which violates monotonically increasing time.