CHIPs discussion phase: Partial Set Security (updated)

Click to open previous draft discussion post Partial Set Security is a reimagining of Opt-in Security (thanks to @effortcapital for the idea), which would allow only a subset of Hub validators to run a physical node for each consumer chain, while still allowing each consumer chain to be secured by the full stake of the Hub. This would work by allowing validators who were not running a physical node to delegate to a validator running a physical node. The implementation of this feature should be straightforward (while still being a lot of work), but before it is started, several questions need to be answered. We’re posting this to get all of the questions we have identified into one place where they can be discussed, as well as soliciting the community to ask any questions that we may have missed. High level questions Is token toxicity a good analytical framework? The design of Partial Set Security revolves around the idea that if the entire stake of a provider chain does not secure a consumer chain, it may not be secure against attacks that validators cannot be slashed for. These types of attacks may be incorrect execution in the absence of fraud or validity proofs, and…

Excerpt (1197 of 14330 characters). Read the whole post on the forum ↗

jtremback:

Validators must make a periodic commitment to run a physical node

So, I just wanted to see how you define “physical node”. At notional we are defining that as an on site machine. Commitments from validators to do that would frankly improve hub security a great deal.

jtremback:

Is running physical nodes the main cost?

Does this mean that we’re going to try to prohibit vaas on the cosmos hub? Personally I think that is a good idea, though there are of course challenges with that, like the fact that it isn’t currently possible to prove the existence of self-operated hardware or softeware.

Sorry, maybe something isn’t clear in the explanation here.

In Partial Set Security, if a validator does not want to run a node for a given consumer chain, they can delegate their stake to another validator who runs the node. We refer to this as a “physical node”.

I bet you explained it totally fine and I missed that.

Thanks for clearing that up!

Also, I think this is elegant.

Note: I scrolled up and actually it was pretty confusing. Suggest that physical be taken out of the above description, since we can just call it a node and it won’t be ambiguous anymore.

Yea I agree. We had at one point been calling them “physical nodes” and “virtual nodes” but that was confusing and unnecessary and this is just a vestige of that. Another problem with this post is that it is a post about a linked paper so if you just read the post it might not be clear.

I will drop a comment in tomorrow with a glossary and brief description and maybe reformat the paper and this post to make it clearer.

jtremback: The simplest approach is to make it so that validators which delegate to other validators receive no commission for that consumer chain, with the validator running the physical node receiving it all. The delegating validator’s reward is simply not being penalized for downtime. Thanks for sharing this idea but it seems there are many similarities with the soft opt-out idea? The top validators are ok running consumer chains and they have the resources for that, soft opt-out gives an option to the bottom 5% by voting power to soft opt-out, this idea gives the option to the top validators as well. In soft-opt out the validators who choose this option at the bottom 5% still receive the rewards from consumer chains (although still negligable anyway) and are part of the validator set, just liveness would be affected slightly hence why 5% bottom voting power was chosen and not a larger value like 10%. This new idea removes the rewards from the validators who ‘soft opt-out’. Then it is mentioned ‘The delegating validator’s reward is simply not being penalized for downtime.’ this is also similar to Soft opt-out for the bottom 5%, there is no jailing for downtime…

Excerpt (1196 of 3005 characters). Read the whole post on the forum ↗

I think we might sunset soft opt out if we added partial set security, since it provides another way for small validators to opt out. The difference with this is that validators are required to either run a node, or delegate to another validator who runs a node, instead of just letting the smallest validators have no involvement with ICS at all. Cosmic_Validator: The issues that we are trying to prevent are liveness failures with one third of voting power down, and two thirds of voting power malicious. For these two issues I think that we should pay more attention to uptime and governance participation of validators. I don’t think that these are factors that we would want to take into account in-protocol. They are easy to game. However, they are definitely factors that validators who aren’t running a physical node should take into account when choosing which other validator to delegate to. One of the interesting things about this is that I think that validators are actually better equipped to judge other validators than delegators are. This could have a minor decentralizing effect if validators prefer to delegate to small validators to run physical consumer…

Excerpt (1197 of 1231 characters). Read the whole post on the forum ↗

jtremback: They are easy to game Let’s analyse, how could governance participation rate in non-spam proposals be gamed? Some validators have over 90% overall governance participation, how could some new malicious validators game this? Firstly, they would need to put many spam proposals, and if the validators who previously had 90% governance participation vote in all the spam proposals, they will still have much higher governance participation rate than the malicious validators. How could uptime be gamed by some new malicious validators? If only long-term average uptime performance over many months or years is taken into account, the malicious validators’ uptime wouldn’t be considered until after a reasonable amount of time. Also, the malicious validators wouldn’t try to game it by having bad uptime, but instead by having great uptime and then when selected attack with downtime. But having really great uptime is not so easy even if they try, there are only a handful of validators with fewer than 100 blocks missed in the last 3 months. But the other idea of EffortCapital about the vote power tax is even better than this idea, because it provides revenue to the small…

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

Hey, we’ve changed a lot of how PSS will work, and updated this post. All comments above this one are on the old post.

So, if i get this correctly:

• A new ICS chain arrives, lets call her BettyX
• BettyX puts a prop onchain
• Validator 1-10 vote, yes, validator 11 votes abstain and validator 12 votes no
• Does this mean that validators 10 and 11 will be allowed to do a soft opt out and validators 1-10, will not be allowed to soft opt out?

Any validator can opt out at any time. The validators who voted yes go into the consumer chain’s starting validator set.

Ty! One last clarification: validators can opt out after already running an ICS chain? I.E. Validator bob runs 3 ICS chains. Bob realizes that its too much for them and decided to opt out mid way from chain ICS 1 and 2.

What do you think about PSS vs a rollup centric model with decentralized sequencers
I think we are making it too complex with all these jargons like Top-n, opt-in, permissionless, permission-lite. Sometimes less is more. If a consumer chain has to think about so many paradigms, I think they will get confused and will add unnecessary friction to adoption.
I also don’t feel like top-n validators should be forced to run a consumer chain. Many of these top validators don’t vote for regulatory concerns etc why should they be forced to run a consumer chain?
Also if a top n validator does not want to run such consumer chains, they will likely split the validator. Hence this mechanism actively promotes sybilling in some sense?

I also feel like this top down approach of PSS is not right where delegators are locked with their validators on all PSS chains if I understand correctly?
Mesh security got it right to have delegators under control for choosing their validators on other mesh chains. I think a similar mechanism should be applied to PSS where some n no of validators opt in as a decentralized sequencer and delegators can chose to stake some derivative of ATOM to them to provide economic security?
In such a model, no one is forced to do something which they don’t want and there can be all sorts of consumer chains ranging from single sequencer rollups(Ethereum style) to entire Hub validator set acting as sequencers to a consumer chain(current Replicated Security style)
This also lets smaller validators keep their delegators on base chain without being forced to run unnecessary consumer chains, hence maintains decentralization
I am just thinking out loud on this and its not necessarily a solid point

Wouldn’t this start a FOMO among validators to be part of the new chains and vote yes?

jtremback:

Let’s look at a few scenarios:

• A top-n of 100% is equivalent to Replicated Security.
• With a top-n of 65%, a consumer chain gets more than half of the Hub’s economic security, but with only 23 validators.
• A top-n below 33% is not possible. This is important for incentive reasons, so that the top validators can never be forced to run a consumer chain they don’t want (with 33% they could veto the proposal).

Maybe it gives the flexibility to consumer chains to select what level of security they need to start, but is it limiting the other validators to even join? meaning if a CS starts with 65% TopN. Now Top 23 validators need to join the set to start the chain but, is this everything the CS needs or validators below in the ranks can also join?

Regarding the latest update on the thread, we wanted to express our support for this CHIP implementation. Very elegant and flexible design whilst keeping features as simple as possible . Thanks for this qualitative work. We see no particular improvement recommendations here.

@Ghazni_Stakecito • On the subject of jargon, you’re seeing all of it because we’ve opened up the design process here on the forum and are weighing different options against each other. When this is in production, we will have settled on a much smaller set of options and simplified the messaging to make it understandable. • On the subject of top-n, top validators (and all other validators as well) are currently forced to run Replicated Security consumer chains. Top-n gives us the ability to transition these to Partial Set Security without changing their security properties too much. Ghazni_Stakecito: I also feel like this top down approach of PSS is not right where delegators are locked with their validators on all PSS chains if I understand correctly? This is definitely a key difference between PSS and Mesh. I personally think that there is somewhat of a benefit in the simplicity of PSS. Delegators choose a validator and let them handle decisions of risk/reward of validation, as they specialize in it. Consumer chains get validators signing up and get their full stake immediately. Validators get to leverage their knowledge of the space, and finally have…

Excerpt (1197 of 1432 characters). Read the whole post on the forum ↗

That was a question I actually posed in another thread, and on twitter, and the consensus was that we want to let lower ranked validators opt into top-n chains as well.

Ty! One last clarification: validators can opt out after already running an ICS chain? I.E. Validator bob runs 3 ICS chains. Bob realizes that its too much for them and decided to opt out mid way from chain ICS 1 and 2.

Yes, that’s correct

I missed that thread, but i would have voted in favor of lower ranked validators to join on top-n chains. Thankyou for answering.

jtremback: Partial Set Security could enable consumer chains to be launched permissionlessly, without a governance proposal jtremback: A top-n of 100% is equivalent to Replicated Security. Replicated security so far has been great for consumer chains benefiting from the security of the Cosmos Hub. After two consumer chains were approved and revenues were not covering the infra costs of validators, other potential consumer chains stopped/delayed their plans or merged with existing consumer chains. A new consumer chain would always prefer replicated security or top-n of 100% vs any lower security provided. In the feature A, many consumer chains could launch but attracting negligable security from the Cosmos hub. Even with the voting option, while some spam could be avoided, likely most of these consumer chains would attract negligable security and the serious project would opt for Replicated security to get the same security as Neutron or Stride. For the Top-n is confusing, I guess for this a governance proposal is required? And if the proposal is approved then the top-n in that case needs to run that consumer chain? The main issue since the launch…

Excerpt (1197 of 2065 characters). Read the whole post on the forum ↗

Hi @jtremback . With PSS, is it possible to let validators outside from the Cosmos Hub to validate a consumer chain?

Cosmic_Validator:

Permisionless opt-in consumer chains: since validators can choose or not to join for them it is better, but for consumer chains it is an issue if they can only attract negligable security and hence may not find this interesting

The economics at play here are more complex than that. We are currently in the process of building a comprehensive model to show the financial aspects of the agreements underlying PSS for both validators and project willing to deploy using the Top-N and Opt-in systems. We hope this will help the community and projects to better understand the complex factors underlying the agreements.