Implement SubmitEvidence for the mesh-slasher contract

[JakeHartnell]

When provided with evidence, mesh-slasher should be able to verify that a slashing event has occurred.

This may need to also make an IBC query on the other chain to verify? @ethanfrey could probably use a bit of guidance on this one.

https://docs.cosmos.network/main/modules/evidence/

[ethanfrey]

There are two versions, the easy and the "more correct".

The easy adds an IBC channel, where some (preauthorised) contract on the consumer chain can inform the slasher on the provider chain of the problem. This may be a good first-step solution and solve almost all cases, but is vulnerable to a Byzantine consumer slashing quite a bit of provider stake.

The "more correct" one based on Sunny's design is supposed to be hardened against a Byzantine consumer chain. This should be based on the x/evidence sdk module, and accept two signed headers on the same block height as evidence of double signing. It must verify signatures and maintain a map of tenderloin pubkey to consumer valoper address. This should work even with a broken IBC connection to the consumer.

[JakeHartnell]

There are two versions, the easy and the "more correct".

The easy adds an IBC channel, where some (preauthorised) contract on the consumer chain can inform the slasher on the provider chain of the problem. This may be a good first-step solution and solve almost all cases, but is vulnerable to a Byzantine consumer slashing quite a bit of provider stake.

The "more correct" one based on Sunny's design is supposed to be hardened against a Byzantine consumer chain. This should be based on the x/evidence sdk module, and accept two signed headers on the same block height as evidence of double signing. It must verify signatures and maintain a map of tenderloin pubkey to consumer valoper address. This should work even with a broken IBC connection to the consumer.

Cool! The second sounds way better, but would likely need help implementing as this is pretty advanced. @ethanfrey perhaps you could create an MVP version and we can add integration tests and such? Or even a detailed write up on how to implement this would be great.

[ethanfrey]

Evidence module is defined here

We only need to focus on one concrete type - equivocation. We actually don't need to implement it as the sdk does, but we can look at the logic there, as well as the transformation from Tendermint evidence. Ideally the contract should handle Tendermint evidence directly, or it includes a client side tool to convert from Tendermint evidence to any custom format

This is the original Tendermint Misbehaviour Evidence we should focus on (at least to start with): abci.DuplicateVoteEvidence

Check out the verification logic for this evidence. It includes:

// VerifyDuplicateVote verifies DuplicateVoteEvidence against the state of full node. This involves the
// following checks:
// - the validator is in the validator set at the height of the evidence
// - the height, round, type and validator address of the votes must be the same
// - the block ID's must be different
// - The signatures must both be valid

If we remove "the validator is in the validator set at the height of the evidence" this becomes stateless (wrt the remote chain). We need a lookup of the tendermint public key (the invalid signer) to the address (valoper one we use to stake/slash). This cannot be derived, as they are different keys for different things (first ed25519, second secp256k1), but need to be passed in (in ListValidators). We can simply assume any validator we know of and have staked to is in the active validator set