You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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 theconverter
contract, that then sends it to the Provider sideexternal-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 theexternal-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 text was updated successfully, but these errors were encountered: