EPIC: Cryptographic verification of equivocation

[jtremback]

Problem

We would like the provider chain to be able to verify equivocation evidence on its own, instead of trusting consumers, or needing evidence to go through governance. For this, we can look at the code in Tendermint which does this, but it will need heavy changes.

Problem details

To keep things simple at first, we should design this code to be used by an accuser who would like to cause an equivocating validator to be slashed by submitting a message to the chain containing all necessary evidence. Later, we can adapt this to be used automatically for packets coming from a consumer chain.

Fortunately, almost all the code used by Tendermint to verify equivocation evidence is in one file: https://github.com/cometbft/cometbft/blob/main/evidence/verify.go. A lot of this code should be possible to reuse, however, it depends on state stored by Tendermint nodes, most of which will not be available on the provider chain.

There are two basic types of equivocation: Double signing and light client attacks.

Double signing

This is trivial, you can see the function that does it here. The only complicated thing is that it requires the validator set and powers at the height of the evidence. But we should be able to store these on the provider. Also, the evidence will have the height of the consumer which will need to be mapped to the height of the provider to get the validator powers at that height. But I think we already have code to do that.

Light client attacks

This is much more complicated, and it requires more state. The additional state that is required is the true header of the block in question, known as the "trustedHeader" or the "commonHeader". In Tendermint, this is loaded from the node's state. On the provider chain, we will not be able to access this. Instead, it should be possible to have the accuser supply the trusted header along with the rest of the evidence. The provider chain can then use the record of validator powers from that block to check that the trusted header is real.

Task list

Must have

Preview Give feedback

1. Create ADR for Cryptographic Verification of Equivocation #1124
   scope: docs +1
   
2. Create a new endpoint for ICS misbehaviour handling #825
   ccv-core type: feature-request +2
   
3. Add jailing and tombstoning to the ICS misbehaviour handling #827
   ccv-core type: feature-request +2
   
4. Address race conditions in ICS misbehaviour handling #1147
   +0
   
5. Add E2E tests to the ICS misbehaviour handling feature #1065
   scope: testing +1
   
6. Improve coverage of ICS misbehaviour E2E tests #1224
   scope: testing +1
   
7. Add consumer double voting handling #1227
   +0
   
8. Fix consumer public keys retrieval in double voting evidence handling: The key assignment feature can't be used to verify equivocation #1261 fix: make HandleConsumerDoubleVoting works with provider pubkeys #1254
9. Wait on the Hermes relayer fix to detect both ICS misbehaviour and double voting handling; blocking Add E2E tests for consumer double voting #1255
10. Update E2E tests to work with last Hermes version #1277
    S: NewThings +1
    
11. Support Hypha with the Gaia v13 tests
12. Add E2E tests for consumer double voting #1255
    S: NewThings scope: testing +2
    
13. Update ADR with consumer double voting #1266
    S: NewThings scope: docs +2
    
14. Explore approaches to enable slashing in ICS misbehaviour handling #1026
    +0
    
15. Slashing in the provider chain for consumer chain infractions #1222
    +0
    
16. Implement slashing functionality on the provider (ADR-013) #1274
    S: NewThings +1
    
17. Wait on the slashing to be integrated; putting Upgrade feat/ics-misbehaviour-handling branch to SDK v47 #1302 temporarlily on hold
18. Upgrade feat/ics-misbehaviour-handling branch to SDK v47 #1302
    2 of 2
    S: KTLO type: feature-request +2
    
19. Update misbehaviour handling to work with IBC 7 #1400
    +0
    
20. refactor: remove equivocation proposal #1294
    +0
21. backport ics-misbehaviour-handling to SDK v45 (ICS 2.x) #1346
    ccv-core type: feature-request +2
    
22. Drop Amnesia attacks #1387
    S: KTLO +1
    
23. Drop nil voters when handling misbehaviour #1403
    +0
    
24. add height-base filter for consumer equivocation evidence Filter feat!: add height-base filter for consumer equivocation evidence #1435

Nice to have

Preview Give feedback

1. Update ICS misbehaviour msg definition #1125
   S: NewThings +1
   
2. Cover light client equivocation attacks in E2E tests #1180
   S: NewThings scope: testing +2
   

[sainoe]

Summarizing our last discussion with @mpoke, we can separate the work into two main concerns:

1. Define the requirements to migrate the equivocation evidence verification from Tendermint to the ICS module.

2. Figure out what it implies to get an equivocation evidence from a malicous consumer and how we can leverage the information stored by IBC.

[tbruyelle]

About 2.

Also, the evidence will have the height of the consumer which will need to be mapped to the height of the provider to get the validator powers at that height. But I think we already have code to do that.

What we have currently is a mapping that uses the valset update id. On the provider chain, this id maps a block height. If we decide to use it, that means the equivocation evidence message must contain the valset id, so the provider can determine the height, and then determine the voting power at this height.

My concern is how do we verify that valset id passed in the message is correct ? I don't think we can use IBC client for that.

Maybe instead the message should contain the entire valset, instead of just the ID. At least the entire valset can be verified if I'm not wrong. But then the message is harder to create for the user.

[ancazamfir]

Had a discussion with @sainoe regarding the light client evidence handling. I think it is fairly complex, the code as is in tendermint cannot really be used.

You will also need some implementation that monitors chains and submits three light blocks (the conflicting block si not enough, you need common and trusted) as part of the new type of evidence. This doesn't exist.
We discussed that maybe a better approach would be laveraging the IBC Misbehavior message (maybe duplicate most behavior in a new message). In either case this seems to be a lot of work.

Later, we can adapt this to be used automatically for packets coming from a consumer chain.

Wondering if we should consider this now as it looks like it's harder to do all the earlier phase work instead of this.

For duplicate vote I think we still need a trigger from the consumer chain evidence module,
since it is detected by consensus on consumer chain, added to the tendermint evidence pool, then included in the next block and handled on the BeginBlock of that block, hitting the evidence module.

Then not sure why we cannot use that for both light client attacks and conflicting votes.
SDK evidence module stores the evidence, so in theory we can get a light client proof for it and include it in a new ICS message together with the evidence (triggered from some ICS Begin blocker?). Or have a different evidence module on consumer chain to handle it the way it is required for the consumer.

Not sure though this is along the lines of "used automatically for packets coming from a consumer chain." And I may be missing something fundamental.

[ancazamfir]

Or we do not trust that consumer chain validators run the proper tendemint protocols, for example they may drop the evidence or duplicate votes?

[cason]

I would suggest to update the links to the CometBFT repository. The code should be the same, but the Tendermint Core (old) repository is now obsolete.