In the current implementation (V1) we slash the delegators associated with a validator with a nominal slash ratio, that is either the one for double signing (for tombstone events) or for being offline (for jailing events).
The problem is (and this was an oversight of the original (MVP) and V1 versions), that on the blockchain, the slashing amount is also being computed based on the nominal slash ratios, but, applied over the validator's power at the misbehaviour's height.
If we apply the nominal slash ratios directly, without any further correction, we'll be applying them to the delegator amounts at the time of the slash processing event; not at the time of the misbehaviour event.
And this can introduce a significant discrepancy: Since validator slashing is usually the result of a proposal's voting, a significant amount of time (max 3 weeks) could have elapsed since the misbehaviour event up to the slashing event. And the incumbent validator power could have changed in between.
To solve this there a number of options:
Introduce an effective slash ratio per slashed validator. This is just the nominal slash ratio, times the ratio of the validator power at misbehaviour height, divided by the validator's power at the slashing event's height (the current validator power, that is).
Introduce a slash correction factor to the nominal slash ratio. This is similar to 1., but instead of sending an effective slash ratio per validator with the valset update jailing and tombstoning values, we send a slash correction factor instead.
Send the validator power at height with the valset jailings and tombstone addresses. The Consumer chain contracts would then need to have a way to query the chain for the current validator power; in order to compute the slash correction factor.
Allow the Consumer contracts to query both, the current validator power, and the validator's power at height; the correction factor would then be just their ratio.
Store the historical amount of tokens each delegator has per validator on the Provider. This will allow the Provider side slashing to apply the slashing over amount at height, instead of the current amount.
This is doable, but will require something similar (a historical record) on the Consumer's virtual-staking contract; so that bonded amounts can be adjusted based on the historical bonded amount at misbehaviour's height as well.
Store the historical amount of validator shares each delegator has on the Provider. This will allow the Provider side slashing to apply the same logic than the Consumer's blockchain slashing. This is in principle possible, but requires more investigation. It will also be affected by price swings and price conversion between Provider and Consumer tokens. Listed here just for completeness.
The solutions based on a correction factor (1. to 4.) are simpler to implement, and would require significant less storage and resources. Particularly, for a relatively rare event like slashing.
The current slashing logic and workflow could be easily modified to support one of these methods. These methods are also impervious or independent of price swings and price conversion factors, as they are based on an adjustment through a factor, not an amount.
maurolacy
commented
9 months ago
In the current implementation (V1) we slash the delegators associated with a validator with a nominal slash ratio, that is either the one for double signing (for tombstone events) or for being offline (for jailing events).
The problem is (and this was an oversight of the original (MVP) and V1 versions), that on the blockchain, the slashing amount is also being computed based on the nominal slash ratios, but, applied over the validator's power at the misbehaviour's height.
If we apply the nominal slash ratios directly, without any further correction, we'll be applying them to the delegator amounts at the time of the slash processing event; not at the time of the misbehaviour event. And this can introduce a significant discrepancy: Since validator slashing is usually the result of a proposal's voting, a significant amount of time (max 3 weeks) could have elapsed since the misbehaviour event up to the slashing event. And the incumbent validator power could have changed in between.
To solve this there a number of options:
virtual-stakingcontract; so that bonded amounts can be adjusted based on the historical bonded amount at misbehaviour's height as well.The solutions based on a correction factor (1. to 4.) are simpler to implement, and would require significant less storage and resources. Particularly, for a relatively rare event like slashing. The current slashing logic and workflow could be easily modified to support one of these methods. These methods are also impervious or independent of price swings and price conversion factors, as they are based on an adjustment through a factor, not an amount.