ICS ?: Validator Set Projection Protocol

[mossid]

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 cross chain validation 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]

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

[zmanian]

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]

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

[mossid]

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

[zmanian]

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

[mossid]

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.

[Hyung-bharvest]

@mossid

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

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

2.

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)

3. 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?

[mossid]

@dlguddus

1. The projected validator set is generated in a fully programmable way, on the leader chain. The leader chain can generate the validator set either related with the leader chain's validator set or not or somewhere between the two extremes. The leader chain will have the underlying information of the valset generation, so it can figure out which validator is responsible when the misbehavior information comes from the follower chain. The follower chain can have a subset of the leader chain's validator set, and it can choose to halt if the valset update heartbeat does not come from the leader chain(in this case the interchain slahsing also need to reflect that).

2. Everything is calculated first on the leader chain and then projected into the follower chain, so both will have the information. The formula is, as you said, one of the possible validator set formation, and could be different.

3. It can be built without IBC but most of the requirements are covered by IBC. The follower chain has to verify whether the new valset info is coming from the leader chain correctly and IBC/TAO is exactly for that use case.

[cwgoes]

Closing in favour of more recent work in https://github.com/informalsystems/cross-chain-validation/pull/4.

@mossid If there's anything here that you think should be incorporated into Informal's design, open issues on that repo.