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 ?: Validator Set Projection Protocol #76

Open
mossid opened this issue Apr 16, 2019 · 7 comments

Comments

Projects
None yet
4 participants
@mossid
Copy link
Collaborator

commented Apr 16, 2019

Overview

Chains on the Cosmos networks are hosting their own meta-chain modules, including staking. This is a good solution for self-sovereignty but in some cases, the chains may want to delegate meta-chain functionalities to a trusted chain and run only the services that the chain wants to provide. This is possible for example when the chain does not have enough economic value yet so they want to use already trusted chain's economic security.

The leader chain stores the validator set for each follower chain. Each time the stored validator set changes or some time has passed(as heartbeat), the stored validator set information packet is sent to the follower chain automatically. The follower chain has an obligation to update the validator set in a predefined period(in blocks). The leader chain updates its lightclient header to the follower chain as it declared, not as the follower chain reported(so we need an alternative connection update scheme in this part).

The IBC connections with the external network will pass the leader chain, so when the follower chain byzantine faults, an additional process(e.g. governance) can safely disconnect the connection between the chains, which will be recovered through the leader chain's decision. This is the same role as the Cosmos hub.

The validator set updating logic can be the existing one, staking, or any other. This protocol only defines how does the updated validator set information is sent to the follower chain.

Example use cases

Shared security

The leader chain can replicate its validator set to the follower chain, possibly using different private keys. Using this with ICS16 forms a shared security model where a chain is secured by the leader chain with the same degree of economic safety.

Fast/Slow chain

"Slow" chain is a chain where the meta-chain transactions happen, including staking, slashing, governance, with longer block time but more numbers of validators and higher safety, whereas "fast" chain is service transaction happen, including token sending, with shorter block time but lower safety. The slow chain manages validator set, so even if there is a byzantine behavior on the fast chain(censorship), the token holders can still change the validator set on the slow chain. Original idea @sunnya97

Sandboxed chain

Similar with fast/slow chain architecture but in this case the "fast" chain runs code with side effects, such as accessing to the exchange API to get price information, run external shell process, etc. These can frequently pause the chain, but since they are running on the sandbox chain, it does not pause the main chain where the decidable code is running. The result can be sent back to the master chain via IBC.

@jackzampolin

This comment has been minimized.

Copy link
Collaborator

commented Apr 23, 2019

Could this be used to build a shard-ed chain?

@zmanian

This comment has been minimized.

Copy link
Member

commented Apr 23, 2019

One of the implications of this is we expect that the staking a delegation module to have high level IBC packets that they can send to inform other of staking events on the top level chain.

@zmanian

This comment has been minimized.

Copy link
Member

commented Apr 23, 2019

@jackzampolin you can build sharding from this if you have a system for processing data availability proofs from the subchains.

@mossid

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 24, 2019

@jackzampolin Yes, we need a common vm running on the sdk additionally, which is required to build the fraud proofs

@mossid mossid changed the title ICS ?: Validator Set Synchronization Protocol ICS ?: Validator Set Projection Protocol Apr 24, 2019

@zmanian

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

@mossid can you change the terminology from slave-chain to leader | follower chain?

@mossid

This comment has been minimized.

Copy link
Collaborator Author

commented May 2, 2019

Semishared security

The leader zone has a power distribution LP, and the follower zone has a power distribution FP. Each power distribution is determined by BPoS in this example.

In a semishared security, the leader zone has the validator power distribution equal to LP, and the follower zone has the validator power distribution equal to LP*50%+FP*50%. Updating LP and FP is done on the leader zone, and the leader zone projects the validator set to the follower zone.

Liveness

  • FP*66% is byzantine: FP alone cannot mutate the state, it can only censor the transactions unlike fully sovereign chain. However, the token holders can still redelegate on the leader zone to change FP.
  • LP*66% is byzantine: LP is less likely to be corrupted, but even if it happens, it also cannot mutate the state unlike fully shared security. FP and the honest part of LP can hard fork the zone and connect it to a new leader zone, possibly forked from the previous one.

Safety

  • LP*100% && FP*33% is byzantine: The least possible scenario, but even if LP is fully corrupted it still needs FP*33% to mutate the state, so the follower chain can connect to another leader chain if it has a supermajority of honest validators.
  • LP*33% && FP*100% is byzantine: Fully corrupted FP still needs LP*33% to mutate the state. If more thenLP*33% is corrupted, then the fraud-proof from the follower chain can be censored anyway so fully shared security will also fail in this case. If less, redelegation on the leader chain can remove byzantine follower chain validators.

So in any case if an attacker wants to perform an invalid state transition on a semisecured chain, it has to occupy a significant portion of power on both power distribution, minimum requirements of 33%*LP, which is enough to sensor the fraud proofs anyway. Considering that the leader chain will provide security to multiple chains at once, the attack cost of LP will rise just like as in shared security model, but compared to fully shared security, it will have a decreased amount of cost for the leader chain validators to validate all other chains and increased sovereignty of each follower chain.

@dlguddus

This comment has been minimized.

Copy link

commented May 20, 2019

@mossid

It looks like very important protocol for enriching environment of Cosmos Hub.
I have some question around this proposed protocol.

The leader chain can replicate its validator set to the follower chain, possibly using different private keys.

  • Is the different private keys generated from the follower chain? Then, how can we validate the relationship with the validator in the leader chain and the validator in the follower chain?
  • What if the follower chain wants subset of the validators of leader chain?
  • Follower chain supposed to be halted when the validator set of leader chain is not updated for certain period?

In a semishared security, the leader zone has the validator power distribution equal to LP, and the follower zone has the validator power distribution equal to LP50%+FP50%.

  • It looks like the formula is an example. So can we use something like min(LP,FP)? Should the formula info be stored in the leader chain?(definitely should be stored in follower chain)

In general, this protocol looks like mostly off-chain utility. Do we need working IBC to deploy this feature? Or can we just build it without IBC or without any changes in Cosmos Hub? Maybe it depends whether or not the follower chain wants "atom slashing" on leader chain when double signing on follower chain happens?

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.