Closed cwgoes closed 3 years ago
This will be critical for Ethermint!
Renamed "Interchain collaterization protocol" per @zmanian suggestion.
Another thing to consider here could be a marketplace for chain developers to hire validators.
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.
I'm still thinking about how to do fee distribution for interchain collateralization.
Also how to think about censorship from the source chain.
Non-Goals: Shared security is not an attempt to produce a unified secure state machine across many blockchains in vein of sharding or Polkadot.
Goals:
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.
So IMO it should be possible to have the same atom to be potentially slashable across multiple blockchains.
Or I believe a system with these properties will outcompete a system without them.
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.
Interchain collateralization is very hard word to say.
I understand wanting a new term. But maybe it needs a bit more brainstorming on that new phrase.
I would propose Interchain staking. Please :+1: :-1: or another suggestion
Cross-chain validation
from Asmodat was also suggested and I like it it.
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.
Cross Chain validation protects a a Bitcoin or Ethereum peg zone. Malicious behavior is a deposit to the peg that is not credited with an IBC packet to the hub, a withdrawal that was not caused by an IBC packet or an amount mismatch. The pegged chain can be assumed to available to relayers.
Cross Chain validation protects against consensus faults against a chain connected to the Hub over IBC. This operates within the IBC threat model and only just adds slashing to detected equivocation vs just channel closure.
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.
Or to use a term from @asmodat
Cross chain validation
@dlguddus
@sunnya97 has provided some good arguments why cross chain validation needs to be registered on the leader chain. This is mostly because it makes fee distribution much easier. Doing ratio restrictions mean that the maximum slashing amount will need to be registered as well.
I think this can be merged with https://github.com/cosmos/ics/issues/76 - what say you @mossid?
Or to use a term from @asmodat
Cross chain validation
I think cross chain validation is not accurate description because in current definition, it does not cover validation of each transaction or state change, but only validation of consensus fault behavior. I think the coverage is still not clearly confirmed yet, but the word "validation" seems to promise too much than its role.
EDIT) now I think cross-chain validation is the best naming because, the scope of validation can be expanded with the configuration on the protocol. Below comment describes the pros/cons of each naming.
My thoughts on comparison with different namings.
So, in conclusion, I think "cross-chain validation" is the best name so far.
Below is a suggestion on cross-chain validation definition. Please feel free to drop any opinions!
There is an interesting design space for responsive forms of interchain collateralization in which one chain rents added validation service for a limited time to counteract transitory attack. Insuring contracts or conditional auctions for rented service could act as deterrents and combined with block space attenuation / protocol quiescence to form blended security strategy.
I've written up my understanding of the latest thinking here at https://github.com/cosmos/ics/issues/448.
Closing in favour of more up-to-date work in https://github.com/informalsystems/cross-chain-validation/pull/4; please direct further comments to that repository.
Specification for simple delegated security over IBC ("slashing over IBC")
Will cover