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.

140 lines
7.0 KiB

  1. # ADR 45 - ABCI Evidence Handling
  2. ## Changelog
  3. * 21-09-2019: Initial draft
  4. ## Context
  5. Evidence is a distinct component in a Tendermint block and has it's own reactor
  6. for high priority gossipping. Currently, Tendermint supports only a single form of evidence, an explicit
  7. equivocation, where a validator signs conflicting blocks at the same
  8. height/round. It is detected in real-time in the consensus reactor, and gossiped
  9. through the evidence reactor. Evidence can also be submitted through the RPC.
  10. Currently, Tendermint does not gracefully handle a fork on the main chain.
  11. If a fork is detected, the node panics. At this point manual intervention and
  12. social consensus are required to reconfigure. We'd like to do something more
  13. graceful here, but that's for another day.
  14. It's possible to fool lite clients without there being a fork on the
  15. main chain - so called Fork-Lite. See the
  16. [fork accountability](https://docs.tendermint.com/master/spec/light-client/accountability/)
  17. document for more details. For a sequential lite client, this can happen via
  18. equivocation or amnesia attacks. For a skipping lite client this can also happen
  19. via lunatic validator attacks. There must be some way for applications to punish
  20. all forms of misbehaviour.
  21. The essential question is whether Tendermint should manage the evidence
  22. verification, or whether it should treat evidence more like a transaction (ie.
  23. arbitrary bytes) and let the application handle it (including all the signature
  24. checking).
  25. Currently, evidence verification is handled by Tendermint. Once committed,
  26. [evidence is passed over
  27. ABCI](https://github.com/tendermint/tendermint/blob/master/proto/tendermint/abci/types.proto#L354)
  28. in BeginBlock in a reduced form that includes only
  29. the type of evidence, its height and timestamp, the validator it's from, and the
  30. total voting power of the validator set at the height. The app trusts Tendermint
  31. to perform the evidence verification, as the ABCI evidence does not contain the
  32. signatures and additional data for the app to verify itself.
  33. Arguments in favor of leaving evidence handling in Tendermint:
  34. 1) Attacks on full nodes must be detectable by full nodes in real time, ie. within the consensus reactor.
  35. So at the very least, any evidence involved in something that could fool a full
  36. node must be handled natively by Tendermint as there would otherwise be no way
  37. for the ABCI app to detect it (ie. we don't send all votes we receive during
  38. consensus to the app ... ).
  39. 2) Amensia attacks can not be easily detected - they require an interactive
  40. protocol among all the validators to submit justification for their past
  41. votes. Our best notion of [how to do this
  42. currently](https://github.com/tendermint/tendermint/blob/c67154232ca8be8f5c21dff65d154127adc4f7bb/docs/spec/consensus/fork-detection.md)
  43. is via a centralized
  44. monitor service that is trusted for liveness to aggregate data from
  45. current and past validators, but which produces a proof of misbehaviour (ie.
  46. via amnesia) that can be verified by anyone, including the blockchain.
  47. Validators must submit all the votes they saw for the relevant consensus
  48. height to justify their precommits. This is quite specific to the Tendermint
  49. protocol and may change if the protocol is upgraded. Hence it would be awkward
  50. to co-ordinate this from the app.
  51. 3) Evidence gossipping is similar to tx gossipping, but it should be higher
  52. priority. Since the mempool does not support any notion of priority yet,
  53. evidence is gossipped through a distinct Evidence reactor. If we just treated
  54. evidence like any other transaction, leaving it entirely to the application,
  55. Tendermint would have no way to know how to prioritize it, unless/until we
  56. significantly upgrade the mempool. Thus we would need to continue to treat evidence
  57. distinctly and update the ABCI to either support sending Evidence through
  58. CheckTx/DeliverTx, or to introduce new CheckEvidence/DeliverEvidence methods.
  59. In either case we'd need to make more changes to ABCI then if Tendermint
  60. handled things and we just added support for another evidence type that could be included
  61. in BeginBlock.
  62. 4) All ABCI application frameworks will benefit from most of the heavy lifting
  63. being handled by Tendermint, rather than each of them needing to re-implement
  64. all the evidence verification logic in each language.
  65. Arguments in favor of moving evidence handling to the application:
  66. 5) Skipping lite clients require us to track the set of all validators that were
  67. bonded over some period in case validators that are unbonding but still
  68. slashable sign invalid headers to fool lite clients. The Cosmos-SDK
  69. staking/slashing modules track this, as it's used for slashing.
  70. Tendermint does not currently track this, though it does keep track of the
  71. validator set at every height. This leans in favour of managing evidence in
  72. the app to avoid redundantly managing the historical validator set data in
  73. Tendermint
  74. 6) Applications supporting cross-chain validation will be required to process
  75. evidence from other chains. This data will come in the form of a transaction,
  76. but it means the app will be required to have all the functionality to process
  77. evidence, even if the evidence for its own chain is handled directly by
  78. Tendermint.
  79. 7) Evidence from lite clients may be large and constitute some form of DoS
  80. vector against full nodes. Putting it in transactions allows it to engage the application's fee
  81. mechanism to pay for cost of executions in the event the evidence is false.
  82. This means the evidence submitter must be able to afford the fees for the
  83. submission, but of course it should be refunded if the evidence is valid.
  84. That said, the burden is mostly on full nodes, which don't necessarily benefit
  85. from fees.
  86. ## Decision
  87. The above mostly seems to suggest that evidence detection belongs in Tendermint.
  88. (5) does not impose particularly large obligations on Tendermint and (6) just
  89. means the app can use Tendermint libraries. That said, (7) is potentially
  90. cause for some concern, though it could still attack full nodes that weren't associated with validators
  91. (ie. that don't benefit from fees). This could be handled out of band, for instance by
  92. full nodes offering the light client service via payment channels or via some
  93. other payment service. This can also be mitigated by banning client IPs if they
  94. send bad data. Note the burden is on the client to actually send us a lot of
  95. data in the first place.
  96. A separate ADR will describe how Tendermint will handle these new forms of
  97. evidence, in terms of how it will engage the monitoring protocol described in
  98. the [fork
  99. detection](https://github.com/tendermint/tendermint/blob/c67154232ca8be8f5c21dff65d154127adc4f7bb/docs/spec/consensus/fork-detection.md) document,
  100. and how it will track past validators and manage DoS issues.
  101. ## Status
  102. Proposed.
  103. ## Consequences
  104. ### Positive
  105. - No real changes to ABCI
  106. - Tendermint handles evidence for all apps
  107. ### Neutral
  108. - Need to be careful about denial of service on the Tendermint RPC
  109. ### Negative
  110. - Tendermint duplicates data by tracking all pubkeys that were validators during
  111. the unbonding period