The next major update of Interchain Security will introduce Partial Set Security. Partial Set Security increases the flexibility available to consumer chains, allowing them to dial in the right mix of economics, validator set agility, and security. Additionally, it will let validators choose whether or not they want to validate on any given consumer chain in most cases. It will also allow consumer chains to launch permissionlessly- no governance proposal required!
These changes will allow consumer chains to launch much more quickly and reduce the workload on Hub validators while allowing consumer chains to choose how much security they need.
Currently, consumer chains are created with a governance proposal, and then get the entire security of the Hub’s validator set. This is a simple system, with guaranteed high security, but it lacks flexibility. Running more chains puts more work on validators, without necessarily increasing their rewards by much. This is not a problem for large validators who earn millions in commission, but it is a strain on smaller validators.
It also puts a lot of pressure on consumer chains generate enough in rewards to pay the validators for their work. It does not allow consumer chains to select the level of security that they need, or to scale security as they grow their TVL.
Finally, the need to get a governance proposal to pass to create a consumer chain limits the rate of growth of ICS, due to the friction involved.
Partial Set Security will enable consumer chains to be launched permissionlessly, without a governance proposal. A consumer chain can be added with a simple transaction, as long as the chain ID is not currently in use (details on anti-squatting measures to follow).
Once a consumer chain has been created in this way, validators can opt in to validate it if they want to. We expect many consumer chains will be launched this way, and will be able to grow their validator sets organically.
Validators (and their delegators) are only entitled to rewards from a consumer chain if they are opted in. Some validators may only opt in to consumer chains with attractive rewards, and some may still opt into every consumer chain so that their delegators never have to worry about missing out.
While most consumer chains will likely launch permissionlessly, some high profile consumers may want a guaranteed level of security. This is what top-n provides.
The top-n for a consumer chain specifies what percentage of the Hub’s security that consumer chain would like to guarantee. When the consumer chain starts, the top n percent of the Hub’s validator set will be obligated to run the consumer chain.
Even though validators outside of that top-n percent are not obligated to run the consumer chain, they can still choose to run it if they want. Many probably still will so that they don’t miss out on rewards, and as a selling point to consumers.
Let’s look at a few scenarios:
On a permissionless consumer chain, when a validator is jailed, they are simply opted out of that consumer chain automatically, and cannot opt back in for a time period. There is no jailing on the Hub.