search

osmosis-labs / mesh-security

Other
62 stars 8 forks source link

Slashing design considerations #113

Closed maurolacy closed 1 year ago

maurolacy commented 1 year ago

Part of #11. Maybe closes #84.

JakeHartnell commented 1 year ago

One high level note that @sunnya97 mentioned to me priviously is that slashing should ideally be implemented as separate contract on the provider side that handles the evidence. This allows for people to build custom slashers in the future (for example, a slasher based on Celestia Data Availability, or some other custom functionality). I think this important to keep as a design goal as it makes Mesh more flexible.

Different providers may choose to use different slashers, but we should definitely ship with a default slasher.

maurolacy commented 1 year ago

One high level note that @sunnya97 mentioned to me priviously is that slashing should ideally be implemented as separate contract on the provider side that handles the evidence. This allows for people to build custom slashers in the future (for example, a slasher based on Celestia Data Availability, or some other custom functionality). I think this important to keep as a design goal as it makes Mesh more flexible.

Different providers may choose to use different slashers, but we should definitely ship with a default slasher.

This is a good point. Also, in terms of auditing and complexity control, it makes sense to separate the slashing impl, on the Consumer at least, from the rest of the mesh security impl.

Problem with supporting a different contract for slashing initially is, it will make the setup more complex: a different contract will require another IBC channel setup, and a counterparty contract on the Provider just to handle the communication.

Perhaps we can go with a single contract impl initially, but make the mesh-security-sdk ready to support a different contract address for submitting misbehaviour evidence and validator set updates. It'll then become a setup / configuration issue, that we can address later. Will think about it.

maurolacy commented 1 year ago

One high level note that @sunnya97 mentioned to me priviously is that slashing should ideally be implemented as separate contract on the provider side that handles the evidence. This allows for people to build custom slashers in the future (for example, a slasher based on Celestia Data Availability, or some other custom functionality). I think this important to keep as a design goal as it makes Mesh more flexible. Different providers may choose to use different slashers, but we should definitely ship with a default slasher.

This is a good point. Also, in terms of auditing and complexity control, it makes sense to separate the slashing impl, on the Consumer at least, from the rest of the mesh security impl.

Problem with supporting a different contract for slashing initially is, it will make the setup more complex: a different contract will require another IBC channel setup, and a counterparty contract on the Provider just to handle the communication.

Perhaps we can go with a single contract impl initially, but make the mesh-security-sdk ready to support a different contract address for submitting misbehaviour evidence and validator set updates. It'll then become a setup / configuration issue, that we can address later. Will think about it.

We have decided to go with a single contract impl first, for simplicity. The code can be modular, both in mesh-security-sdk and the contracts, so that it can be refactored later into a separate contract for slashing evidence handling.

maurolacy commented 1 year ago

Added a couple of sections on native chain slashing and slashing propagation.

Will refine it and extend it. The case of jailing (leaving the active validator set) and tombstoning (permanent jailing) need to be considered and documented as well.