github.com/badrootd/nibiru-cometbft@v0.37.5-0.20240307173500-2a75559eee9b/docs/architecture/adr-045-abci-evidence.md (about)

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