ICS evidence handling

[ancazamfir]

cc @jtremback @mpoke @romac @sainoe @MSalopek @josef-widder
Details of the proposal (work in progress) can be found here.

What is required:

• ICS: Create test scripts/ CI that spawn provider and consumer chains and perform the double voting and light client attacks.

  • Manually create evidence for
    • Light client attacks
    • Double voting

• Create test scripts/CI for

  • Light client attacks
  • Double voting

• ICS: Define two new messages, let's call them MsgIcsMisbehaviourLightClient and MsgMisbehaviourDuplicateVoting. Work together with ibc-go team. Involve informal protocol team.

• ICS: Handling of MsgIcsMisbehaviourLightClient

  • for CheckTx: Implement validateBasic() in a similar way done here or just call this function
  • for DeliverTx:
    • Implement CheckMisbehaviourAndUpdateState() in a similar way done here or just call this function. Note: it is important to freeze the client before next step.
    • Retrieve the byzantine validators like it is done in comet light client
    • For each byzantine validator take action (slash, jail, etc)

• ICS: Handling of MsgIcsMisbehaviourDoubleVote

• IBC/ Hermes: Create an evidence relaying worker or separate agent that extracts evidence from Comet blocks on consumer chain and submits the MsgMisbehaviour... messages to the provider (see tracking issue).

  • Temporary (PoC): Use block or commit RPC to check evidence at give height
  • Ideally: Use new evidence notification from Comet or new RPC that checks for presence of evidence (see comet issue)
  • Nice to have: check that the SDK evidence module stored the evidence and alert otherwise

• ICS: Ideally we move the ICS dependency to an official cosmos-sdk version, e.g. v0.47.x
  - [ ] ICS: Don't allow validators to use the same consensus key on multiple chains

• Operations:

  • Ensure light client agent runs with at least one consumer witness node different than the primary one
  • Ensure hermes/evidence relayer runs for each consumer client