Signaling Proposal - ICS with Inactive Hub Validators

We are combining the CHIPs discussion and signaling phase for this feature since we already have a detailed architecture draft that we want to propose. You can view the ADR here.

Starting with the introduction of ICS 2.0 (aka Partial Set Security) in the v17 upgrade, only validators from the Cosmos Hub’s active validator set can opt-in to validate on consumer chains. This signaling proposal enables validators from outside the Cosmos Hub’s active validator set to validate on consumer chains.

This signaling proposal will not immediately enable the feature, but instead signal the community’s interest in having it. If the proposal passes, the feature will be included in a software update in the next few months.

Benefits

This feature brings benefits to both consumer chains (or projects wanting to launch as a consumer chain in the Cosmos Hub) and Hub validators. First, it reduces the entry barrier for new projects with lower security budgets, especially given their potential lower security needs. Second, it enables validators from outside the Hub’s active set to compete by opting in to validate on promising new projects.

In addition, the feature addresses an existing concern of ICS 2.0 — what happens if all the validators running a consumer chain are opting out. One solution is for the team behind the consumer chain to run their own validator node. However, at the time of writing, the last validator in the Hub’s active set has around 91k ATOMs bonded. By extending the pool of available validators, the amount of bonded ATOMs needed to validate on a consumer chain would be lowered.

Risks and Mitigations

The main risk behind this proposal is that it might let validators with little stake and reputation validate consumer chains. This also brings an additional risk of sybil attacks (i.e. a single entity controlling many validator nodes), which could make the validator set of consumer chains appear decentralized, when it is in reality controlled by a single entity.

We plan to mitigate this risk by going in small steps and, for the first iteration, only allowing the first 20 validators outside the Cosmos Hub’s active validator set to validate on consumer chains. We expect that this will still be a relatively competitive set.

Additionally, we plan to introduce a per-consumer-chain parameter which sets the minimum amount of stake a validator must have to be eligible to validate on the consumer. This parameter is set by each consumer chain individually according to their preferences. If a consumer leaves the parameter unset, the Hub will set it to the amount of stake bonded by the bottom validator in its active set; in other words, if the parameter is unset, only validators from the Hub’s active set are allowed to validate the consumer.

How the feature will work

Currently, the validator set flows to consumer chains (via the provider module) and the consensus engine (CometBFT) separately, and in both cases is taken from the staking module, see this figure:

For this feature, we will increase the size of the active set on the Cosmos Hub to include more validators. However, to ensure that these extra validators are not impacting the network operations, we route the validator set through the provider module, filtering the set of validators to a smaller set (which will be exactly what the active set is today). This means rewards, slashing for infractions on the Cosmos Hub, etc stay as they are today: They take into account only the first 180 validators (the size of the active set at the time of writing). The new flow of the validator set to CometBFT and consumer chains looks like this:

For all modules, we will set them up to either utilize the full set of validators from the staking module, or the filtered set of validators from the provider module, as appropriate.

For more details, checkout out the ADR.

Proposal Outcomes

The following items summarize the voting options and what they mean for this proposal:

Upon a YES vote:

Starting when the feature is included in an upcoming Cosmos Hub upgrade, the first 20 validators outside the Cosmos Hub’s active validator set will be able to opt-in to validate on consumer chains.

Upon a NO vote:

Only validators from the Hub’s active validator set will be able to opt-in to validate on consumer chains.

NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned

ABSTAIN - You wish to contribute to quorum but you formally decline to vote either for or against the proposal

References: