ICS 16: Interchain collaterization protocol

[cwgoes]

Specification for simple delegated security over IBC ("slashing over IBC")

Will cover

• Packet types, semantics, encodings
• Provided security properties
• Requirements of validator set
• Required consensus integration

[alexanderbez]

This will be critical for Ethermint!

[cwgoes]

Renamed "Interchain collaterization protocol" per @zmanian suggestion.

Another thing to consider here could be a marketplace for chain developers to hire validators.

[zmanian]

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.

[zmanian]

I'm still thinking about how to do fee distribution for interchain collateralization.

Also how to think about censorship from the source chain.

[zmanian]

Interchain Collateralization in Cosmos

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:

1. Allow Atoms to be used as collateral against consensus faults on many blockchains
2. Allow Atoms to be used as collateral against other faults like signing against the protocol of peg zone etc.

Implementation thoughts for consensus faults on other Cosmos chains

1. We need to introduce a transaction type for byzantine evidence.
2. Validators need to be able to have a transaction that opts them into and out of consensus faults.
3. Portions of the evidence handler will be need to duplicated in the SDK.
4. This should share state with IBC root of trust
5. It should be possible for another chain to slash a validator for liveness faults on another chain.

Implementation thoughts for non-consensus faults on other Cosmos chains.

1. There is a non-censorship and censorship resistant version.
2. The non-censorship resistant version is basically an IBC packet that allows a specific chain to request that a validator be slashed.
3. The censorship resistant version will need some form of onchain code/scripting so that ad hoc slashing evidence can be processed.

[MeherRoy]

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.

[crainbf]

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.

[zmanian]

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.

[crainbf]

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.

[chtmorris]

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.

[ethanfrey]

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 👍 👎 or another suggestion

[zmanian]

Cross-chain validation from Asmodat was also suggested and I like it it.

[zmanian]

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.

1. 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.

2. 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.

1. Collateralizing against general state machine faults

[Hyung-bharvest]

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.

[ethanfrey]

Or to use a term from @asmodat

Cross chain validation

[zmanian]

@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.

[cwgoes]

I think this can be merged with #76 - what say you @mossid?

[Hyung-bharvest]

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.

[Hyung-bharvest]

My thoughts on comparison with different namings.

• shared security, delegated security
  • security is too broad wording
  • does not explain the characteristic of interchain protocol
  • does not represent the fact that it is an application on IBC
• interchain collaterization
  • interchain seems adaquate wording to explain that it is a protocol between different chains, and also it implies it is an application on IBC
  • collaterization seems too broad concept compared to what it really serves because many defi applications also use the word collaterization in different range
• cross-chain validation
  • cross-chain and interchain seems very similar description but it is better because cross-chain emphasizes the meaning of "across over other blockchain". "interchain" seems too abstract and vague.
  • the word validation seems correctly describe the role of the protocol

So, in conclusion, I think "cross-chain validation" is the best name so far.

[Hyung-bharvest]

Below is a suggestion on cross-chain validation definition.
Please feel free to drop any opinions!
  

1. naming of the protocol
   • shared security, delegated security
     • security is too broad wording
     • does not explain the characteristic of interchain protocol
     • does not represent the fact that it is an application on IBC
   • interchain collaterization
     • interchain seems adaquate wording to explain that it is a protocol between different chains, and also it implies it is an application on IBC
     • collaterization seems too broad concept compared to what it really serves because many defi applications also use the word collaterization in different range
   • cross-chain validation
     • cross-chain and interchain seems very similar description
     • the word validation seems correctly describe the role of the protocol
   • conclusion
     • we will use the word "cross-chain validation" as now
         
2. naming of each blockchain
   • leader/follower chain
     • the roles are not related to front and behind so it is not adaquate
   • control/controlled(?) chain
     • the role is to validate but not control(it is too much wording than its role)
   • mother(parent)/child chain
     • looks like very intuitive definition, which is also widely used in capital market
     • it might gives wrong impression of too strong belonging
   • conclusion
     • we will use mother/child chain as now
         
3. must roles
   • validator set projection via IBC
     • reasoning
       • each mother/child chain should be informed about other chain's validator set
       • mother chain and child chain both needs to know recent entire validator set on both chains to correctly process consensus procedure
     • process of validator set projection
       • the mother chain transfers its validator set information to the child chain via IBC
       • the child chain commits the state of entire validator set including validators on both chains
       • the child chain transfers the committed entire validator set to the mother chain via IBC
     • periodic heartbeat
       • validator set should be shared on both chains like a heartbeat to inform most recent validator set information
       • what if relayer cannot relay mother chain validator set into child chain for significantly long time?
         • is it okay for child chain to continue producing blocks even though the mother chain validator set has not been updated for long time?
         • the child chain should safety-stop when mother chain validator set has not been updated for certain number of blocks
   • mother chain validators operate full-validator setup on child chain
     • mother chain validators participate on all child chain validation process
       • to fully participate on child chain validation, mother chain validators should operate full setup child chain validator node
   • consensus fault punishment on mother chain
     • mother chain validators will be slashed or jailed if they do consensus fault behavior on child chain consensus process
     • this feature needs an IBC protocol called "evidence relay"
   • evidence relay
     • relayer should relay consensus fault evidence on child chain to the mother chain to allow mother chain validators to punish the mother chain validator who did consensus fault behavior on child chain consensus process
     • manual evidence reporting on mother chain is additional feature
   • hybrid cross-chain validation
     • hybrid validation means mother chain validators and child chain validators having proportional consensus voting power so that they participate on consensus with given power
     • for example
       • mother chain proportional power = 50%
       • child chain proportional power =50%
       • if a mother chain validator has 10% of total mother chain validators who participate on the child chain, he/she will possess 50%*10%=5% of entire power on child chain
     • the parameter is defined in the state of child chain
   • cross-chain reward/fee distribution from child chain to mother chain
     • mother chain validators can choose which child chains to participate
     • process
       • rewards for mother chain delegators are accumulated in a module account in child chain
       • a mother chain delegator request a “cross-chain reward withdrawal”
       • IBC distribution protocol transfer such request to the child chain
       • withdrawal amount is transferred from child chain to mother chain
       • distribute withdrawal amount to requestor on mother chain
   • optional participation of mother chain validators into each child chain
     • mother chain validators can choose which child chains to participate
     • methodology
       • on mother chain, mother chain validators create a new validator for participating on a specific child chain
       • there exists an activation flag on the validator which implies the validator's intention to participate on the child chain consensus process
       • when the activation flag is on, the validator is subject to responsibility of consensus fault punishment, uptime, and beneficiary of rewards
       • delegators of the validator will automatically follow the setup of the validator
   • role of relayers for cross-chain validation
     • validator set projection heartbeat
     • evidence relay
     • IBC peg : for cross-chain reward distribution
     • IBC distribution : for transfer information about reward distribution of mother chain delegators and validators
         
4. optional roles(future roadmaps)
   • governance voting power projection
     • to allow delegators on mother chain participate in governance on child chain
     • with predefined proportional governance voting power
     • we need additional IBC governance protocol to share governance power and votes

[hxrts]

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.

[cwgoes]

I've written up my understanding of the latest thinking here at #448.

[cwgoes]

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.