Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ICS 16: Interchain collaterization protocol #27

Open
cwgoes opened this issue Mar 5, 2019 · 17 comments

Comments

Projects
None yet
8 participants
@cwgoes
Copy link
Collaborator

commented Mar 5, 2019

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

@cwgoes cwgoes self-assigned this Mar 5, 2019

@cwgoes cwgoes changed the title ICS ?: Delegated security protocol ICS 16: Delegated security protocol Mar 5, 2019

@alexanderbez

This comment has been minimized.

Copy link
Collaborator

commented Mar 5, 2019

This will be critical for Ethermint!

@cwgoes cwgoes changed the title ICS 16: Delegated security protocol ICS 16: Interchain collaterization protocol Mar 28, 2019

@cwgoes

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 28, 2019

Renamed "Interchain collaterization protocol" per @zmanian suggestion.

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

@zmanian

This comment has been minimized.

Copy link
Member

commented Mar 29, 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.

@zmanian

This comment has been minimized.

Copy link
Member

commented Mar 31, 2019

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

Also how to think about censorship from the source chain.

@zmanian

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

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

This comment has been minimized.

Copy link

commented Apr 10, 2019

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

This comment has been minimized.

Copy link

commented Apr 11, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 11, 2019

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

This comment has been minimized.

Copy link

commented Apr 14, 2019

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

This comment has been minimized.

Copy link

commented May 2, 2019

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

This comment has been minimized.

Copy link

commented May 3, 2019

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

This comment has been minimized.

Copy link
Member

commented May 3, 2019

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

@zmanian

This comment has been minimized.

Copy link
Member

commented May 3, 2019

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

This comment has been minimized.

Copy link

commented May 3, 2019

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

This comment has been minimized.

Copy link

commented May 3, 2019

Or to use a term from @asmodat

Cross chain validation

@zmanian

This comment has been minimized.

Copy link
Member

commented May 4, 2019

@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

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 9, 2019

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

@cwgoes cwgoes removed their assignment Jun 29, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.