The idea here is to use the same mechanism ICS is using to transmit slashing events from the Consumer to the Provider chain.
Namely, instead of relying on the Consumer chain to forward those messages to the Provider through a sudo message to the virtual-staking contract, that then sends it to the converter contract, that then sends it to the Provider side external-staking contract over IBC, we rely on a relayer (hermes, typically) that monitors the Consumer chain for slashing events, and broadcast them on the Provider.
Then, a Mesh Security SDK on the Provider (mesh-security-provider-sdk or so) monitors for those txs, and forward them (through a sudo) to the external-staking contract for processing.
This has the advantage of being independent of the Consumer blockchain. It can also leverage existing work at the relayer level, that was done for Inter Chain Security.
Another advantage is that these messages contain the slashing evidence (double signed blocks, signatures, validator public keys, etc.) which can then be verified before being honoured, adding an important extra layer of safety to the slashing mechanism.
This requires some investigation and proper planning, as there may be some complexities. Perhaps as well, there's extra data that would need to be gathered and forwarded ((historical, i.e. at misbehaviour) slash amounts, infraction time, infraction height, etc.), in order to accomplish the same slashing functionality that is in the current implementation.
The idea here is to use the same mechanism ICS is using to transmit slashing events from the Consumer to the Provider chain.
Namely, instead of relying on the Consumer chain to forward those messages to the Provider through a sudo message to the
virtual-stakingcontract, that then sends it to theconvertercontract, that then sends it to the Provider sideexternal-stakingcontract over IBC, we rely on a relayer (hermes, typically) that monitors the Consumer chain for slashing events, and broadcast them on the Provider.Then, a Mesh Security SDK on the Provider (
mesh-security-provider-sdkor so) monitors for those txs, and forward them (through a sudo) to theexternal-stakingcontract for processing.This has the advantage of being independent of the Consumer blockchain. It can also leverage existing work at the relayer level, that was done for Inter Chain Security. Another advantage is that these messages contain the slashing evidence (double signed blocks, signatures, validator public keys, etc.) which can then be verified before being honoured, adding an important extra layer of safety to the slashing mechanism.
This requires some investigation and proper planning, as there may be some complexities. Perhaps as well, there's extra data that would need to be gathered and forwarded ((historical, i.e. at misbehaviour) slash amounts, infraction time, infraction height, etc.), in order to accomplish the same slashing functionality that is in the current implementation.