ICS FAQ
Last updated
Last updated
VSR simply means that the same validator set is used to secure both the provider and consumer chains. VSR is ensured through Replicated Security protocol which keeps consumers up to date with the validator set of the provider.
A consumer chain is blockchain operated by the same validator operators as the provider chain. The RS protocol ensures the validator set replication properties (informs consumer chain about the current state of the validator set on the provider)
Consumer chains are run on infrastructure (virtual or physical machines) distinct from the provider, have their own configurations and operating requirements.
In case the provider chain halts or experiences difficulties the consumer chain will keep operating - the provider chain and consumer chains represent different networks, which only share the validator set.
The consumer chain will not halt if the provider halts because they represent distinct networks and distinct infrastructures. Provider chain liveness does not impact consumer chain liveness.
However, if the trusting_period (currently 5 days for protocol safety reasons) elapses without receiving any updates from the provider, the consumer chain will essentially transition to a Proof of Authority chain. This means that the validator set on the consumer will be the last validator set of the provider that the consumer knows about.
Steps to recover from this scenario and steps to "release" the validators from their duties will be specified at a later point. At the very least, the consumer chain could replace the validator set, remove the ICS module and perform a genesis restart.
Consumer chains do not impact the provider chain. The RS protocol is concerned only with validator set replication and the only communication that the provider requires from the consumer is information about validator activity (essentially keeping the provider informed about slash events).
Yes, but you should favor running them in separate environments so failure of one machine does not impact your whole operation.
As any other cosmos-sdk chain the consumer chain can issue its own token, manage inflation parameters and use them to pay gas fees.
The consumer chain operates as any other cosmos-sdk chain. The ICS protocol does not impact the normal chain operations.
No. Consumer chains are free to choose how they wish to operate, which modules to include, use CosmWASM in a permissioned or a permissionless way. The only thing that separates consumer chains from standalone chains is that they share their validator set with the provider chain.
The consumer chains sends a portion of its fees and inflation as reward to the provider chain as defined by consumer_redistribution_fraction. The rewards are distributed (sent to the provider) every blocks_per_distribution_transmission.
consumer_redistribution_fraction and blocks_per_distribution_transmission are parameters defined in the ConsumerAdditionProposal used to create the consumer chain. These parameters can be changed via consumer chain governance.
Yes.
In that case the validators are not necessarily part of the governance structure. Instead, their place in governance is replaced by "representatives" (governors). The representatives do not need to run validators, they simply represent the interests of a particular interest group on the consumer chain.
Validators can also be representatives but representatives are not required to run validator nodes.
This feature discerns between validator operators (infrastructure) and governance representatives which further democratizes the ecosystem. This also reduces the pressure on validators to be involved in on-chain governance.
At present, the validators cannot opt-out of validating consumer chains.
To avoid potential attacks directed at provider chain validators, a new mechanism was introduced:
When a validator double-signs on the consumer chain, a special type of slash packet is relayed to the provider chain. The provider will store information about the double signing validator and allow a governance proposal to be submitted. If the double-signing proposal passes, the offending validator will be slashed on the provider chain and tombstoned. Tombstoning will permanently exclude the validator from the active set of the provider.
An equivocation proposal cannot be submitted for a validator that did not double sign on any of the consumer chains.
Consumer chains are standalone chains, in the sense that they can run arbitrary logic and use any modules they want (ie CosmWASM).
Consumer chain upgrades are unlikely to impact the provider chain, as long as there are no changes to the RS module.
