[PROPOSAL ##] [DRAFT] Signaling Proposal - ICS 2.0: Partial Set Security

Partial Set Security Signaling Prop This is a signaling proposal for the Partial Set Security update to Interchain Security. PSS will allow a subset of the Cosmos Hub’s validator set to run consumer chains, as well as bringing several other features to make ICS more flexible. This signaling proposal will not immediately deploy the feature set but it will be included in a software update in the next few months. This feature set will manifest in two main ways- opt-in consumer chains, and top-n consumer chains. It will completely supersede the current ICS implementation, known as Replicated Security. Opt-in consumer chains With opt-in consumer chains, unlike with Replicated Security, every validator can choose whether or not they want to run the chain. This means that no validator is obligated to run a consumer chain, and can make their own choices about how profitable it is likely to be. Additionally, validators will be able to choose a different commission rate per consumer chain, helping them to cover expenses on the consumer chains that they run without changing their main Cosmos Hub commission rate. Several “validator set shaping” features will be available to…

Excerpt (1192 of 3590 characters). Read the whole post on the forum ↗

We could spend hours discussing this major milestone in the Hub’s history, which is Partial Set Security (PSS). From all the discussions we’ve had with projects and teams building in the Cosmos, there is a lot of interest in this new frontier. It’s expected to be market-fit and bring new blood into the AEZ. Every new partner joining the economy will create 2^n opportunities to collaborate in the space. jtremback: However, for the first version, consumer chains will need to be “cleared for launch” by governance. Of course, this is absolutely required in the initial stage. Regarding the design itself, we have already commented on the CHIP proposition and fully support the composability offered by the Opt-in and Top-n solutions. CHIPs discussion phase: Partial Set Security (updated) CHIPs Click to open previous draft discussion post <a href="https://docs.google.com/document/d/1Oq2oaqaZe_MHWkscMFeVIo8ITKf4p19jwdYkvMEzcFs/edit">Partial Set Security</a> is a reimagining of Opt-in Security (thanks to <a class="mention" href="/u/effortcapital">@effortcapital</a> for the idea), which would allow only a subset of Hub validators to run a physical node for…

Excerpt (1198 of 1617 characters). Read the whole post on the forum ↗

Govmos:

Of course, this is absolutely required in the initial stage. Regarding the design itself, we have already commented on the CHIP proposition and fully support the composability offered by the Opt-in and Top-n solutions.

Thanks for your support! The reason it’s required is actually kind of a random technical thing- consumer chains are currently stored in the DB under a key of their chain id. This means that chain ids must be unique, and that someone could “squat” them if chain creation was permissionless.

To enable full permissionlessness, we simply need to refactor the database code to store consumer chains under a unique incrementing ID. Pretty trivial, but we thought it would be best to leave it for the second release in order to ship fast.

We support it. Thanks for all that you and Informal do for the Hub.

Thank you @jtremback for your work and everyone behind this.

jtremback:

Active set: A consumer chain can choose to have an active set smaller than the Hub’s active set, for better performance.

If I get it right, this is not in favor of smaller validators. let’s run a hypothetical scenario, BOB chain launches with an opt-in consumer chain, and they set a validator set of 75. The product was good and the BOB chain started to make a profit for cosmos delegators now there is a race to be in the active set. Because bigger validators have more VP they will cash the benefit, now small validators will start to lose the delegations and VP more and it will start to concentrate the VP towards bigger validators.

Now, the argument against it can be; that it is the same race case for profitable independent App-Chains. That’s right but it doesn’t hurt the existing VP of validator’s on Cosmos HUB.

In this case, smaller validators will get to run only loss-making ICS chains, and bigger validators will get bigger because they now have the inherited right to join the opt-in consumer chains that are making a profit.

jtremback: The reason it’s required is actually kind of a random technical thing- consumer chains are currently stored in the DB under a key of their chain id. This means that chain ids must be unique, and that someone could “squat” them if chain creation was permissionless. Well, it may extend beyond just the technical requirements. Currently, we’re inundated with spam proposals hitting the hub consistently. We’re in the process of going on-chain to raise the minDeposit to try to tackle the issue. The last thing we want is to have PSS-equivalent worthless proposals without clear value added. I can easily imagine people submitting pointless propositions to the chain’s validators. I think we need to define a clear governance framework for submissions. This involves setting minimum technical requirements, guidelines, and basic elements of information to help each validator make informed decisions. It’s also necessary to define criteria under which proposals are deemed spam and vetoed. The chain’s governance can’t be called for pointless votes. Moreover, you need to remember that validators will put their stake at risk. Filtering the valuable elements from the riskier…

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

jtremback:

Opt-in consumer chains will be able to launch permissionlessly, without the governance proposal currently required by Replicated Security. After launch, once validators start opting in, the consumer chain starts running.

Do the validators are “forced” to opt-in? Or they will have a choice to opt-in or not?

If they have a choice, then consumer chains need to do some kind of lobbying to validators?

How does this work for the new projects coming online with PSS? What if that is the route they want to go, but cannot secure enough validator support?

I don’t understand this argument. In the opt-in scenario, the VP on each chain is different. It’s not like VP from Cosmos Hub somehow translates to VP on other chains. Delegators delegate wherever they want. Some validators are small on Cosmos Hub but top validators on other chains. Many such examples. I don’t see how “race to be in the active set” benefits large validators of Cosmos Hub at all.

There is concentration of VP in the top-n scenario as the big validators get to be in the active set automatically for the consumer chain. But that is by design.

Shouldn’t it cost money to create chain id? I think it should be like the proposal. If one wants to create a chain they need to deposit a certain amount of ATOMs. I would say 100 ATOMs (or about $1000 at present) should be the price for registering a chain slot.

We don’t think we should charge proposals to join the ICS. The rationale and the message sent to potential users is counter productive. It would basically mean, pay first, get served later… eventually.

This is a model that many chains have opted for in the crypto space, this has not proven to be a good option so far. On the contrary, the Hub’s strength is its governance capability, coupled with a 500 ATOMs deposit for the proposal, this should be more than enough to deter wasteful propositions. The argument we shared is that this deposit should be burnt (aka vetoing) if the proposition doesn’t meet some basic criteria which we should define clearly.

Of course we are opened to explore other solutions, we just think this is something that should be debated before we launch PSS. We still have plenty of time to work on this framework, but the TL;DR is that the sooner we get to work the better!

I really want to avoid the spamming that we had in the proposals. You can be sure the chain ids will spammed immediately if they are free. You are operating in an adversarial space and you need to raise the cost of spam attacks.

How to cover the cost of validators?
ICS 2.0 will have inflation?

Genuinely in favor of this, hats off to @jtremback
This seems like a wonderful evolution to replicated security. Omitting validator obligations & removing the friction of governance makes this a much more scalable and attractive product overall.

The next step is BD, recruitment, GTM, and more documentation! Will be happy to contribute and support it however I can.

waqarmmirza: In this case, smaller validators will get to run only loss-making ICS chains, and bigger validators will get bigger because they now have the inherited right to join This is inaccurate, according to the documentation: Note that in a Top N consumer chain, the top `N%` provider validators have to validate the consumer chain. Nevertheless, validators in the bottom `(100 - N)%` can opt in to validate as well. Provider validators that belong or enter the top `N%` validators are automatically opted in to validate a Top N consumer chain. Source: Partial Set Security | Interchain Security This system works as follows: the only restriction is for TopN validators which can’t opt-out of the PSS chain if it passed the governance vote to be on-boarded. All other validators can opt-in and out of the validator set at any time. This is another quote from the documentation: In PSS, we allow validators to opt in and out of validating any given consumer chain. This has one exception: we introduce a parameter `N` for each consumer chain and require that the validators in top `N%` of the provider’s voting power have to secure the consumer chain. Validators outside…

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

Indeed, @Govmos’ analysis regarding the Partial Set Security (PSS) update is astute and cogent.

The amalgamates top-n and opt-in features balance between the concentration and distribution of power within consumer chains.

Furthermore, @jtremback raises a salient point concerning the potential disinclination of validators to participate in the opt-in feature. Implementing incentives or rewards for validators who operate consumer chains, such as a 15% commission rate (vs. the standard 10% on the Cosmos Hub) or a share of transaction fees.

This could make running consumer chains more attractive to validators without causing an excessive burden on the consumers.

Providing further specificity and concreteness in the explanation is undoubtedly a prudent course of action.

Top-n validators, such as specific thresholds for stake, track record, or reputation, will add an explanation.

A balanced granularity and reduced complexity would enable a more comprehensive understanding of the proposed hybrid model and its potential benefits.

According to the specifications from the CHIPs discussion phase, there were mentions to a particular (optional) vote power cap for consumer chains within the PSS system. Validator power cap Each consumer chain can also set a cap on the power that any individual validator can have on their chain […] We’ll release some analysis on different top-n and cap scenarios soon. Source: CHIPs discussion phase: Partial Set Security (updated) Since this post didn’t mention this feature, we were wondering if it’s still part of the design and if you still plan to release some analysis of different scenarios. We emphasize this because in our own projections of PSS economics, we saw this as an absolute necessity to balance the natural centralizing forces that could emerge in the validator set. We were hoping to use your analysis model to potentially advocate for a minimum cap built into the topN system. Consumers would be able to adjust it freely, of course, but not beyond this threshold. Something like a 5% maximum VP set by default would ensure that even in the tightest conditions of the 50% topN with no other validator joining outside the top would ensure that consumers have a…

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

Hi @jtremback
Can ICS 2.0 bring actual benefits to ATOM validators and stakers?
As I known, Elys will have its own stake method. They call Governors. Users will stake ELYS to governors. The governors will earn ELYS staking commission. But the governors is not ATOM validators. The governors doesn’t need to run nodes. This is similar to Stride.
In this way, ATOM validators are still running the consumer chain nodes at a loss, and ATOM stakers have negligible income.
So what does ICS2.0 bring to ATOM

Elys will send rewards back to the Hub to pay for the validator set. Validators can opt in and out as they want. No validator will choose to run Elys at a loss, so it is not something I am worried about.

Yeah, I know Elys will send rewards to validators and ATOM stakers.
However, just like Neutron and Stride now, although there are also distributed rewards to Hub, it is very small for stakers. The same is true for validators. validators are completely losing money and cannot cover hardware costs.

Are the opt-in nodes only those in the active set (180) or also the others?
I mean think of validators towards the end of the active list, dropping out. Would they then also need to stop validating the ICS2.0 chains?

And how would an opt-in chain ensure to continuously keep running with sufficient security?
I guess for most consumers stop and go frequently would be a desaster.

And finally: when going for TopN how would this be approached?
Is it possible to have a x+ decission? Lets say a consumer tries to go for 95% and would fail, however 85% of validators would accept, while down to 80% would be acceptable. Could a voting be held for 80% + to get as much as possible but not below 80%?

As part of a team operating one of the Hub’s validators ( PRO Delegators ), let us address some of the points you’ve raised. alexp: And how would an opt-in chain ensure to continuously keep running with sufficient security? I guess for most consumers stop and go frequently would be a desaster. Firstly, it’s important to clarify that the following answer reflects our own perspective on the matter and may not necessarily be shared by all other validators. Let’s begin by explaining the rationale behind our expected validator’s decision to opt into a chain or not. The initial step involves conducting a professional-grade due diligence process. This includes reviewing the project’s vision, the chain’s code, the team’s history and legitimacy, the competitive landscape, the value proposition, and a detailed roadmap, among other factors. If the project passes this review process successfully, the next step is to assess the proposition itself from an economic standpoint. The project must present coherent revenue expectations and a realistic forecast (inflated numbers here would raise a red flag for us). Examining the revenue share mechanism is the next crucial part of…

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

Ok, thank you for your explanation.

Thanks for the questions @alexp

We eventually want to extend it to the full set, not just the active set, but that won’t be in the first version.

An Opt-In chain does need to provide enough rewards to get validators. It’s a little tricky to figure out what this is at first, but after a few chains launch it will be obvious. If a chain can’t issue enough rewards to attract validators, this is an issue with or without ICS. I think that if a chain has less than 4 or 5 validators it starts to look sketchy.

Since we only allow validators that are in the active set right now, it does put a floor on the level of security that will be obtainable by a consumer chain. Validators at the very bottom of the active set tend to have 100k or below atoms. So a chain must be issuing enough rewards to fund about 500k atoms staked, or around $6m worth of security. As a comparison, only the very smallest standalone chains have this low of a level of security so I think that consumer chains with even the smallest amount of momentum and size will be fine.

Once we let validators outside of the active set opt in, it will lower that floor, but I think it is pretty low already.

jtremback:

Once we let validators outside of the active set opt in, it will lower that floor, but I think it is pretty low already.

We must say that we haven’t thought about this before but we definitely like that idea. A net benefit for everyone and some interesting economics can can be created beyond the active set. We could easily imagine people running inactive nodes with smaller ATOM balances but still being profitable by providing “venture” security to very small chains. This situation would be a win-win for everyone, the hub would have more validators (most people tend to forget that inactive validators are important as well), whilst the consumers would benefit from using the CosmosHub’s consensus and execution to secure the PSS agreement.