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.

186 lines
7.0 KiB

  1. # ADR 047: Handling evidence from light client
  2. ## Changelog
  3. * 18-02-2020: Initial draft
  4. * 24-02-2020: Second version
  5. ## Context
  6. If the light client is under attack, either directly -> lunatic/phantom
  7. validators (light fork) or indirectly -> full fork, it's supposed to halt and
  8. send evidence of misbehavior to a correct full node. Upon receiving an
  9. evidence, the full node should punish malicious validators (if possible).
  10. ## Decision
  11. When a light client sees two conflicting headers (`H1.Hash() != H2.Hash()`,
  12. `H1.Height == H2.Height`), both having 1/3+ of the voting power of the
  13. currently trusted validator set, it will submit a `ConflictingHeadersEvidence`
  14. to all full nodes it's connected to. Evidence needs to be submitted to all full
  15. nodes since there's no way to determine which full node is correct (honest).
  16. ```go
  17. type ConflictingHeadersEvidence struct {
  18. H1 types.SignedHeader
  19. H2 types.SignedHeader
  20. }
  21. ```
  22. When a full node receives the `ConflictingHeadersEvidence` evidence, it should
  23. a) validate it b) figure out if malicious behaviour is obvious (immediately
  24. slashable) or the fork accountability protocol needs to be started.
  25. ### Validating headers
  26. Check both headers are valid (`ValidateBasic`), have the same height, and
  27. signed by 1/3+ of the validator set that the full node had at height
  28. `H1.Height-1`.
  29. - Q: What if light client validator set is not equal to full node's validator
  30. set (i.e. from full node's point of view both headers are not properly signed;
  31. this includes the case where none of the two headers were committed on the
  32. main chain)
  33. Reject the evidence. It means light client is following a fork, but, hey, at
  34. least it will halt.
  35. - Q: Don't we want to punish validators who signed something else even if they
  36. have less or equal than 1/3?
  37. No consensus so far. Ethan said no, Zarko said yes.
  38. https://github.com/tendermint/spec/pull/71#discussion_r374210533
  39. ### Figuring out if malicious behaviour is immediately slashable
  40. Let's say H1 was committed from this full node's perspective (see Appendix A).
  41. Intersect validator sets of H1 and H2.
  42. * if there are signers(H2) that are not part of validators(H1), they misbehaved as
  43. they are signing protocol messages in heights they are not validators =>
  44. immediately slashable (#F4).
  45. * if `H1.Round == H2.Round`, and some signers signed different precommit
  46. messages in both commits, then it is an equivocation misbehavior => immediately
  47. slashable (#F1).
  48. * if `H1.Round != H2.Round` we need to run full detection procedure => not
  49. immediately slashable.
  50. * if `ValidatorsHash`, `NextValidatorsHash`, `ConsensusHash`,
  51. `AppHash`, and `LastResultsHash` in H2 are different (incorrect application
  52. state transition), then it is a lunatic misbehavior => immediately slashable (#F5).
  53. If evidence is not immediately slashable, fork accountability needs to invoked
  54. (ADR does not yet exist).
  55. It's unclear if we should further break up `ConflictingHeadersEvidence` or
  56. gossip and commit it directly. See
  57. https://github.com/tendermint/tendermint/issues/4182#issuecomment-590339233
  58. If we'd go without breaking evidence, all we'll need to do is to strip the
  59. committed header from `ConflictingHeadersEvidence` (H1) and leave only the
  60. uncommitted header (H2):
  61. ```go
  62. type ConflictingHeaderEvidence struct {
  63. H types.SignedHeader
  64. }
  65. ```
  66. If we'd go with breaking evidence, here are the types we'll need:
  67. ### F1. Equivocation
  68. Existing `DuplicateVoteEvidence` needs to be created and gossiped.
  69. ### F4. Phantom validators
  70. A new type of evidence needs to be created:
  71. ```go
  72. type PhantomValidatorEvidence struct {
  73. PubKey crypto.PubKey
  74. Vote types.Vote
  75. }
  76. ```
  77. It contains a validator's public key and a vote for a block, where this
  78. validator is not part of the validator set.
  79. ### F5. Lunatic validator
  80. ```go
  81. type LunaticValidatorEvidence struct {
  82. Header types.Header
  83. Vote types.Vote
  84. }
  85. ```
  86. To punish this attack, we need support for a new Evidence type -
  87. `LunaticValidatorEvidence`. This type includes a vote and a header. The header
  88. must contain fields that are invalid with respect to the previous block, and a
  89. vote for that header by a validator that was in a validator set within the
  90. unbonding period. While the attack is only possible if +1/3 of some validator
  91. set colludes, the evidence should be verifiable independently for each
  92. individual validator. This means the total evidence can be split into one piece
  93. of evidence per attacking validator and gossipped to nodes to be verified one
  94. piece at a time, reducing the DoS attack surface at the peer layer.
  95. Note it is not sufficient to simply compare this header with that committed for
  96. the corresponding height, as an honest node may vote for a header that is not
  97. ultimately committed. Certain fields may also be variable, for instance the
  98. `LastCommitHash` and the `Time` may depend on which votes the proposer includes.
  99. Thus, the header must be explicitly checked for invalid data.
  100. For the attack to succeed, VC must sign a header that changes the validator set
  101. to consist of something they control. Without doing this, they can not
  102. otherwise attack the light client, since the client verifies commits according
  103. to validator sets. Thus, it should be sufficient to check only that
  104. `ValidatorsHash` and `NextValidatorsHash` are correct with respect to the
  105. header that was committed at the corresponding height.
  106. That said, if the attack is conducted by +2/3 of the validator set, they don't
  107. need to make an invalid change to the validator set, since they already control
  108. it. Instead they would make invalid changes to the `AppHash`, or possibly other
  109. fields. In order to punish them, then, we would have to check all header
  110. fields.
  111. Note some header fields require the block itself to verify, which the light
  112. client, by definition, does not possess, so it may not be possible to check
  113. these fields. For now, then, `LunaticValidatorEvidence` must be checked against
  114. all header fields which are a function of the application at previous blocks.
  115. This includes `ValidatorsHash`, `NextValidatorsHash`, `ConsensusHash`,
  116. `AppHash`, and `LastResultsHash`. These should all match what's in the header
  117. for the block that was actually committed at the corresponding height, and
  118. should thus be easy to check.
  119. ## Status
  120. Proposed.
  121. ## Consequences
  122. ### Positive
  123. * Tendermint will be able to detect & punish new types of misbehavior
  124. * light clients connected to multiple full nodes can help full nodes notice a
  125. fork faster
  126. ### Negative
  127. * Accepting `ConflictingHeadersEvidence` from light clients opens up a DDOS
  128. attack vector (same is fair for any RPC endpoint open to public; remember that
  129. RPC is not open by default).
  130. ### Neutral
  131. ## References
  132. * [Fork accountability spec](https://github.com/tendermint/spec/blob/master/spec/consensus/light-client/accountability.md)
  133. ## Appendix A
  134. If there is an actual fork (full fork), a full node may follow either one or
  135. another branch. So both H1 or H2 can be considered committed depending on which
  136. branch the full node is following. It's supposed to halt if it notices an
  137. actual fork, but there's a small chance it doesn't.