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

Hub Proposals
1

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 consumer chains, such as:

  • Whitelists and blacklists: Consumer chains can choose to exclude certain validators, or only include others (if they opt in).
  • Power cap: Consumer chains can choose to cap the amount of power a large validator can bring to their chain. For example, they could configure it so that no validator could have more than 25% of the power on their chain, even if one of the validators was much larger than the others.
  • Active set: A consumer chain can choose to have an active set smaller than the Hub’s active set, for better performance.

Top-n consumer chains

Some consumer chains need to guarantee a high level of security, and are valuable or strategic enough to warrant it. This is the category of chains that have used Replicated Security to date. To continue to support this use case, we are introducing the “top-n” feature. On a top-n consumer chain, the top “n” percent of Hub validators are automatically opted in.

A top-n setting of 95% percent is functionally equivalent to Replicated Security, and this is what current Replicated Security consumer chains will be migrated to. Other settings are also available. For instance, 66% top-n has comparable security to 100%, yet only requires around the top 25 Hub validators to run the consumer chains (others can still opt in if they want).

However, we expect that the majority of new chains will launch as opt-in chains. Neutron and Stride will be migrated to 95% top-n chain, which is exactly equivalent to their current security with Replicated Security.

Permissionless launch

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.

However, for the first version, consumer chains will need to be “cleared for launch” by governance. This is purely to avoid frivolous or spam consumer chains being created. In an update after launch, we will be refactor the database code to allow for fully permissionless consumer chains.

Details

Here is an ADR describing the main points of PSS: Partial Set Security | Interchain Security

Progress is tracked here: EPIC: Partial Set Security · Issue #853 · cosmos/interchain-security · GitHub

Code is in progress here: GitHub - cosmos/interchain-security at feat/partial-set-security

19 Likes
2

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.

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.

Overall, we just want to take this opportunity to express our strong support for this upcoming feature. At this point, we wish we could fast-forward to the day of the effective release! Kudos to the Informal team for their valuable contributions to make this happen.

On behalf of the entire PRO Delegators’ team, thank you.
pro-delegators-sign

9 Likes
3

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.

3 Likes
4

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

1 Like
5

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

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.

6

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 ones will take quite some time & efforts to research. Defining such minimal framework for the permissionless version is absolutely necessary to us.

Of course, this is our stance on the matter, and we definitely look forward to a community debate on a general governance framework for the chain. We will initiate that debate in the coming month if no one else does it before!

2 Likes
7

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?

8

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?

9

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.

10

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.

11

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!

3 Likes
12

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.

1 Like
13

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

14

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.

15

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 of the top N% can dynamically opt in if they want to validate on the consumer chain.

Direct Link to the full documentation is provided here.

We hope this will help eliviate this legitimate fear you presented.
Govmos.
pro-delegators-sign

5 Likes
16

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.

2 Likes
17

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 bare minimum of 10 validators running this chain. In the current Hub’s VP distribution, this would only impact the rewards of the first two validators.

Moreover, inviting every topN consumer to use an even lower cap than the base 5% may be a good way to combine efforts with the forthcoming VotePower Tax proposed by @effortcapital. More information regarding this proposition can be found here: Cosmos Hub Tokenomics - Fiscal and Governance Policy (Blockworks Research).

To summarize, we would like to ask @jtremback if this cap is still part of the final design, and if so, we would like to propose the introduction of a base VP cap to the topN design. The appropriate level of this parameter should be debated by the community, of course, based on a model to showcase the underlying effects this parameter has. If needed, we can help produce this model.

Thanks for reading!
Govmos

7 Likes
18

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

19

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.

20

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.