Explore approaches to enable slashing in ICS misbehaviour handling

[sainoe]

Problem

The ongoing work on cryptographic equivocation verification doesn't include the slashing operation. The reason behind this limitation is described in the ADR-005 draft.

Closing criteria

Figure out how to enable the slashing in the untrusted consumer chain context.

Problem details

The proposed solution below, although not viable, can serve as a starting point for further exploration.

In ICS, the equivocation verification uses an IBC misbehaviour message to transmit a consumer evidence to the provider. This message type contains two conflicting block headers from the consumer, which can be utilized to derive an infraction height on the provider’s side. In brief, the solution involves mapping each validator set to a corresponding block height on the provider. Upon receiving a consumer evidence, the provider can then map the received validator set to the associated infraction height, enabling the slashing of misbehaving validators.
However, a limitation of this solution arises from the fact that non-consecutive blocks can possess the exact same validator set. Consequently, the mapping becomes obsolete in situations where different unique block heights share an identical validator set.

[mpoke]

Closing in favour of #1222