CHIPs Specification phase: Partial Set Security

Our ADR for Partial Set Security is publsihed and work has already started on the implementation! Here’s a summary for the forum, but read the full thing if you have questions about it. Context • Problem with Current System: The current system, known as Replicated Security , requires all validators from a provider chain to secure consumer chains. This setup has several drawbacks, including forcing many validators to secure chains they might not be interested in, imposing high costs on small validators, and making it difficult for new consumer chains to adopt Replicated Security. • Solution: Introduces Partial Set Security (PSS), which allows consumer chains to be secured by only a subset of a provider’s validators, addressing the concerns with the current system. Decision • Changes in Security Approach: Unlike the current system where all validators must secure every consumer chain, PSS lets validators choose whether to participate in securing a specific consumer chain. However, a parameter `N` ensures that the top `N%` of validators by voting power must secure each consumer chain, with the rest having the option to join in. • Examples: If `N = 95%`, security is…

Excerpt (1194 of 3450 characters). Read the whole post on the forum ↗

This Partial Set Security (PSS) proposal, though well-intentioned, raises significant concerns regarding the potential for centralization and economic bias within the Cosmos ecosystem. The PSS proposal risks creating a scenario where validators might intentionally neglect less profitable chains, favoring those with higher economic returns. This could disrupt the balance of support across the Cosmos network, leading to a disproportionate concentration of power and resources among top validators. Such a bias towards economically beneficial chains undermines the principle of equitable treatment and could challenge the fundamental decentralized structure of the ecosystem. Moreover, the proposal seems to be predicated on the assumption of economic hardships faced by validators. However, this premise requires a more rigorous examination. Are validators truly struggling economically, or is this a perceived issue not grounded in empirical evidence? It is crucial to critically assess this assumption, as it forms the basis of the proposed changes. Introducing significant structural modifications based on unverified economic hardships could inadvertently destabilize the ecosystem’s…

Excerpt (1195 of 2711 characters). Read the whole post on the forum ↗

Thanks Jehan seems like there’s a lot of advantages over the current implementation and despite some drawbacks overall I think its worth pursuing.

Curious, have you thought of implementing contracts for minimum terms chains can opt in and out, and a “rage quit” option for a penalty should consumer chains decide to opt out early?

previous idea seems better … why this choice ?

Which previous idea?

Virtualised validators delegating their stake the others to run consumer chain

@CML I’ll address your two main threads of argument here, since many of your points address different facets of the same concerns. CML: Economic Bias and Validator Selection : What steps will be taken to prevent validators from favoring only high-economic-return consumer chains? How can we ensure equitable support across all consumer chains? This is a feature, not a bug. The rewards offered by each consumer chain will affect how many validators want to support them. I don’t think we need to worry about fairness here- consumer chains need to offer rewards that are attractive. CML: Centralization Risks : How will the PSS model prevent the centralization of power among top validators? What mechanisms will ensure that smaller validators are not disproportionately disadvantaged? I think this is a valid concern, but also that we shouldn’t over index on it. In theory, larger validators can run more consumer chains, potentially at a loss than smaller validators, putting smaller validators at a disadvantage. In practice, the number of consumer chains a validator can run is not so strongly correlated with their size. It’s more correlated with ability.…

Excerpt (1199 of 1956 characters). Read the whole post on the forum ↗

PSS is a game changer, we need to take our time. in my honest opinion, i prefer the idea of virtualised validators who delegate their stake to others coupled with fully permissionless consumer chain onboarding.

economic bias within the Cosmos ecosystem

This is something the Cosmos Hub has been chronically missing, some economic sense – bias even better.

In case of a Top N chain, we restrict the possible values of `top_N` from `(0, 100]` to `[50, 100]`. By having `top_N >= 50` we can guarantee that we cannot have a successful attack, assuming that at most `1/3` of provider validators can be malicious. This is because, a Top N chain with `N >= 50%` would have at least `1/3` honest validators, which is sufficient to stop attacks. Can you walk through this logic from the ADR? If, somehow, the top `1/3` of the Hub’s set is malicious, a Top N chain with `N >= 50%` would have that entire `33.3%` of malicious validators and `17.7%` honest. I’m not saying this is likely, just want to make sure I follow the logic in this paragraph. `N > (VetoThreshold = 33.4%)` is a great catch; I think that’s it’s important to avoid a situation where the top N of the Hub gets forced to run a chain. Because the `Tally` method deletes the votes after reading them, we cannot check the votes of the validators after the votes have been tallied. To circumvent this, we introduce a hook for `AfterProposalVote` and keep track of all the votes cast by a validator. If a validator casts more than one vote, we only consider the latest vote. Finally, we…

Excerpt (1195 of 1413 characters). Read the whole post on the forum ↗

I read a blog post from Informal System in late 2022 where they said that Partial Set Security had the inherent “subset problem” that could cause a risk to the security.

At the time in the blog they said :

“Opt-in security’s fatal flaw is that it is impossible to tell when the system might shift into an insecure state, and until a solution to the subset problem is found, we won’t build it.”

What has changed since then ?

Very good question. I wrote that post.

The short answer is that the solution to the subset problem is fraud votes, which will be used for opt-in security. Validators taking malicious action on an opt-in consumer chain will be slashable by a vote. This will not be necessary for top-n chains, since they will have enough of the validator set of the Hub that there won’t really be as much of a “subset”.

The long answer is that frankly, no other shared security products are addressing this issue. And given that the subset problem is a risk for consumer chains, not the provider chain, in some ways it’s smart for us to just give the people what they want. The market is telling us that consumer chains are OK risking it.

With fraud votes, I think that the Cosmos Hub’s ICS still has the best answer to the subset problem, and it is something that is hard to replicate elsewhere.

Heya…couple of q’s:

• Is there a release date scheduled?
• Is there a min/maximum number of validators that will be required for each consumer chain?

Thanks!

Partial Set Security (ICS 2.0) is already live on the Hub and there’s no min validator set for a consumer chain, technically speaking. Presently, the maximum is 180, the same as the Hub’s valset, but that may change as the feature for letting inactive validators validate consumer chains is developed.