ICS 16: Interchain collaterization protocol #27
referenced this issue
Mar 5, 2019
The core idea to be implemented here is allowing IBC messages that instruct a validator to be slashed and how by what percentage.
The slashing event occurs when the IBC message is received and affects the current set of delegators.
There probably needs to be an IBC message that provides proofs that a validator has adjusted what chain-ids are allowed to send these slashing messages.
Interchain Collateralization in Cosmos
Implementation thoughts for consensus faults on other Cosmos chains
Implementation thoughts for non-consensus faults on other Cosmos chains.
Question on the rivalrous or non-rivalrous nature of atom collateral:
Should the Cosmos Hub allow the "same atom" to be pledged as collateral for validating two different chains, and be slash-able for penalties originating from both chains? Or is "each atom" only slash-able for faults on one particular chain.
Example - Chorus has 7 million atoms delegated on the Cosmos Hub. 5% (0.35 million) is slash-able for Hub faults. Let's say Chorus pledges the other 95% (6.65 million) for faults on the Regen Network zone. Should Chorus be able to re-use the the 6.65 million pledged to Regen for faults on the Lino zone?
If Chorus is not allowed to re-use the 6.65 million, that a non-rivalrous design - there cannot be a race condition (rivalry) between 2 zones to slash some atoms on the Hub.
If Chorus is allowed to re-use the 6.65 million, that's a rivalrous design - there can be a race condition (rivalry) between 2 zones to slash some atoms on the Hub.
To me, it appears that the design should be non-rivalrous. However, curious to hear thoughts.
There is also a big question around how this changes the relationship between validators and delegators. e.g. somebody delegates to Chorus One, do we then decide for what blockchains those atoms also get used for validation? Is there some kind of opt-in? Or opt-out?
Regarding censorship-resistance, it seems fine to me if a validator gets slashed on the hub based on an IBC packet from a zone. Why would the zone not be able to submit such a packet and thus the slashing proof?
It seems only if >1/3 of stake on that zone is malicious. Is that okay? I'm not totally sure, but it might be.
It's very interesting how what we are talking about looks so much like fractional reserve banking.
I think you are right that a system is more efficient if it can simultaneously use the collateral on various chains. But you could then have a 'bank-run' type of situation. If a validator double-signs on multiple chains at the same time, it could be that for later messages that deliver evidence of double signing, no atoms to slash are left.
Lots of scenario that we need to think through carefully here.
Another consideration should be how delegated security would play out under altered slashing conditions. @sunnya97 has suggested that slashing should be proportional to stake held. An alternative idea is that slashing should be proportional to the number of zones a validator is validating.
As @crainbf says - there are a lot of scenarios here.
Some thinking I've been doing about censorship.
Depending on the use case data availability may or may not be a problem.
here are some examples where data availability does not need to be considered.
There are use cases where data availability matters.
How about reuse rules with ratio restriction?
Atom collateral can be reusable but, sum of possible slashing percentages should be lower than X%
For example, if slashing percentage of each zone is 20%, and if X=100%, validator can validate one hub and maximum 4 zones.
Threshold X can be decided by parameter so that it can be decided by community (Like bank BIS ratio). Based on risk appetite of community members, X can be vary. 150~200% is reasonably conservative in my view.