Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
ICS ?: Validator Set Projection Protocol #76
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
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.
"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
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.
The leader zone has a power distribution
In a semishared security, the leader zone has the validator power distribution equal to
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
It looks like very important protocol for enriching environment of Cosmos Hub.
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?