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 equivalent to Replicated Security. If N = 0%, this is a pure Opt-in chain, and no validator is forced to participate, but they can choose to do so.
How do consumer chains join?
Through Governance Proposal: Consumer chains can join PSS by a governance vote, not permissionlessly, to prevent chain ID squatting. Pure opt-in consumer chains use a special governance proposal with a lower quorum requirement.
Proposal Requirements: The ConsumerAdditionProposal is extended to include an Top-N parameter, determining the percentage of top validators required to secure the chain.
How do validators opt in?
Opting In and Out: Validators can opt in or out of securing a consumer chain via specific messages. For Top N chains, the top N% of validators are automatically opted in but can opt out if they drop below the threshold.
How do validators opt out?
Opt-Out Mechanism: Validators that have opted in can opt out through a specific message, except for those in the top N% of a Top N chain.
When does a consumer chain start?
Starting Conditions: A Top N chain starts on a specified date if approved. An Opt In chain starts once at least one validator opts in.
How do we send partial validator sets to consumer chains?
Validator Set Updates: The document outlines a plan to send updates to consumer chains about which validators are participating, ensuring only opted-in validators are involved.
How do we distribute rewards?
Rewards Distribution: Rewards from consumer chains will be distributed only to validators that actively participate in securing them, based on their involvement duration.
Misbehaviour Handling
Addressing Misconduct: The document discusses mechanisms for handling validator misconduct, including fraud votes for attacks in Opt In chains and existing slashing for double signing and downtime.
Consequences
Positive Outcomes: Makes it easier for new consumer chains to join, relieves smaller validators from the obligation to validate unwanted chains, and deprecates the soft opt-out feature.
Negative Outcomes: Consumer chains might not receive the same level of economic security as with the current system, except for Top N chains with N >= 95%.
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 integrity and foundational values.
In light of these concerns raised about the Partial Set Security (PSS) proposal, I propose the following direct questions be answered explaining how these critical issues can be avoided:
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?
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?
Economic Hardship Validation: Can we obtain concrete data to substantiate the claim of economic hardships faced by validators? How will this data be used to inform and adjust the PSS proposal?
Mitigating Preferential Treatment: What checks and balances will be introduced to mitigate the risk of preferential treatment among validators towards certain consumer chains?
Long-term Ecosystem Health: How does the PSS proposal align with the long-term vision of the Cosmos ecosystem, particularly in terms of maintaining decentralization and fairness?
Addressing these questions is critical for ensuring that the PSS proposal aligns with the core principles of the Cosmos ecosystem. Keeping in mind the paramount importance of maintaining decentralization and equitable treatment across all consumer chains, irrespective of their perceived economic value.
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?
@CML I’ll address your two main threads of argument here, since many of your points address different facets of the same concerns.
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.
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. Smaller validators like @Polkachu (getting bigger now though) run any Cosmo chain binary they can get their hands on. Meanwhile, some very large validators in the set seem to struggle. Validators who can run many consumer chains and especially those who can pick the right ones to run will win out. This could even become a differentiator for small validators.
That being said, a solution like the one that @Guinch_Roze mentions, where validators can delegate to each other could help smaller validators close the gaps. That got cut from this version for simplicity, but I am not opposed to it at all. This might be a good upgrade, and if we prioritize it could be out relatively soon. However, I don’t necessarily want to delay the launch of PSS for it.
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.
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 only consider a validator has opted in if it casts a 100% Yes vote in case of a weighted vote.
We investigated ways to fetch validator votes for finished proposals a few weeks ago on the testnet – maybe useful?
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.”
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.