PSS: Permissionless vs premissioned-lite opt-in consumer chains

Hub Proposals CHIPs
1

With the pure opt-in side of PSS, it is theoretically possible to launch consumer chains in a completely permissionless manner. However, it may still be beneficial to piggyback on the Cosmos Hub’s governance practices and UX. Let’s look at two alternatives to see why:

Transaction-based (fully permissionless)

Let’s look at how a fully permissionless consumer chain could launch:

  • Consumer chain developers post a transaction to the Hub, claiming a chain ID and launching their chain
  • Validators post transactions opting into the chain
  • As validators opt in, the chain’s security increases

This is very simple; in theory, there is no barrier to launching a consumer chain. But this ignores the realities of UX. Consumer chains must reach validators to get them to opt in. Either this will need to be done through back channels and social platforms, or we need to build an interface to list all active consumer chains and help validators opt in.

Building such a platform would be a lot of work and even once it is built, validators would need to be notified about consumer chain launches and driven to engage with the platform. One of the key value adds of ICS is eliminating some of the validator set creation overhead, and needing to drive validators to a new platform may negate this advantage.

Proposal opt-in (permissioned-lite)

We could also piggyback on the existing governance proposal system.

  • Consumer chain developers post a governance prop to the Hub launching their consumer chain.
  • Validators vote
    • YES if they want to validate on the consumer chain
    • NO if the do not want it to launch at all
    • ABSTAIN if they do not personally want to validate, but don’t mind the chain launching
  • When the vote concludes successfully, the YES voters are automatically opted in
  • The criteria for a proposal to pass is
    • It passes quorum
    • There are more YES than NO votes
  • So for most opt-in consumer chain proposals, it should be pretty easy for them to pass as long as they can get to quorum, since people are unlikely to vote NO, even if they don’t want to validate themselves.

In theory, this has a higher technical bar than the fully permissionless approach. The proposal must pass the quorum threshold to even launch. But this is the main hurdle. After quorum is met, as long as there are more YES than NO votes, the chain launches. It seems unlikely that people will vote NO in any numbers, since it doesn’t really affect them.

So technically, it is a little harder to get a consumer chain launched this way, although it is possible to modify quorum requirements on specific proposal types, making the difficulty of reaching quorum negligeable.

But the UX might be way better. Instead of someone needing to push validators to use a new platform, and get into the habit of checking for new consumer chains etc., they use a platform they are well accustomed to. Consumer chain launches can follow the same processes as any governance proposal. The power of utilizing an existing platform shouldn’t be underestimated.

One potential downside is that voters might not know the difference between an opt-in proposal and a top-n proposal. On an opt-in proposal, they won’t have to run the consumer chain if they don’t want to, while on a top-n proposal, the top validators will have to run it if it passes. This confusion could result in voters voting NO on a chain, even if they would have no problem with it if they realized that it was opt-in. This can be solved by clearly marking the proposals to avoid confusion.

8 Likes
2

I don’t think this is a problem since we have the Cosmos Hub forum which is a great place to get awareness if you’re launching a consumer chain. If a concern is that not all validators check the Cosmos Hub forum, then perhaps that chain is better off not onboarding them in the first place.

2 Likes
3

Proposal opt-in is interesting. The main pro I see is quality control - since a NO vote would only happen if a chain was damaging to the Cosmos Hub. While this might be technically easier to implement, I think it’s more complex of a concept and will thus be harder for people to understand how it works and why it exists. Since I find the permissionless version more elegant and easier to explain to people, I’d lean towards focusing on that.

4

Agree with Elijah here.

I see benefits of a semi-Permissioned model, but for the Hub to reach its full potential we need fully permissionless consumer chain onboarding.

I’m confident between the forums and other social media channels, it won’t be hard for validators to identify consumer chains they want to secure.

Eventually a better interface can be built for potential consumer chain discoverability, but I don’t think that needs to be priority right now. That’s something that can be built once the market shows permissionless opt-in has PMF.

6 Likes
5

Noob question. With regards to emissions and incentives in a permissionless implementation for a consumer chain, suppose that you’re delegating to a validator who opts out of validating a consumer. Would your validator and thus you not receive any of these block rewards?

I mostly ask, because if that’s the case, wouldn’t that cause more validator centralization, since you would naturally want to delegate to the validators who are running all of them?

4 Likes
6

I assume this idea is derived from the structure proposed by eigenlayer. Some shared security marketplace to match supply and demand between providers and consumers.

Even though we think the idea seems appealing on paper our long-term vision lies on a different forecast. We think the Cosmos market for security should be multi-layered between full set ICSv1, partial set opt-in V2 and eventually imagine subset security V3 with less validators involved to match lower costs execution demands. The hub’s position in this world is heavily reliant in validators to be proactive instead of passive. This is something we have described in greater extent here: Cosmos Ecosystem : A permissionless B2B2C network - #8 by Govmos.

In conclusion, we tend to support the thesis for governance approved onboarding for V1 and V2 requests. Where V3 type requests are expected to be more discretionary business served by validator subsets. This is where we would imagine a market fit for permissionless deployment.

1 Like
7

I like permissioned lite. 40% quorum is high though (72 validators). I’d say quorum for this proposal should be 10% or about 18 validators min should sign up.

1 Like
8

@tknox35 Maybe in theory, but IMO not so much in practice. Some of the largest validators seem to have the most trouble running consumer chains, and some small validators run nodes with no problem on the Hub, the consumer chains, and every other Cosmos chain.

I think in the short term, you will see the validator set get a little more movement as people try to redelegate to those validators who can ensure that they don’t miss out. Some of those smaller but high performing validators may get bigger.

1 Like
10

I think this is a viable step forward, glad to hear from you Jehan. As for me, I think this make ICS compete with solutions like Eigenlayer/Ethos or Mesh. Glad the BD at informal has been cooking, looking forward to this going on chain.

2 Likes
11

@Elijah and @effortcapital - I definitely get what you’re saying. A few other complications with launching consumer chains with transactions though:

  • Chain-id reservation: The ability to permissionlessly claim chain-ids involves some complexity. You could have someone claim a bunch of them and squat on them. To avoid this type of issue you basically need to build something a lot like a nameservice which is pretty complex. You could also just make it so that opt-in consumer chains get a random string as a chain-id which we could look into more. It is used in some places on block explorers, but it might not be a big deal. However, this would make it impossible for an existing chain to transition to being a consumer chain (like Stride did). Launching with a proposal avoids this because obvious squatting will be voted down as spam.
  • Starting validator set: You need a validator set to start a chain, at least to perform the IBC handshake. For this reason, we’ll have to build in a “sign up period” even with transaction-launched consumer chains.
  • Development velocity: It’s honestly just going to be a lot quicker to build proposal-launched opt-in consumer chains. So even if going fully transaction-launched is on the roadmap, I feel like it might be best to start with proposal launches.
2 Likes
12

Should the name service be something that AADAO puts out for an RFP if it’s a potential critical feature?

Maybe a dumb question, but if a consumer chain never launches because it doesn’t get validators to opt in, won’t it not be able to squat/spam chain-ids?

Sign up period makes sense even for permissionless deployment. That doesn’t feel like a concern.

Whats the timeline for both types? Quicker deployment the better, but I’m strongly in favor to remove Hub governance from ICS whenever possible.

13

True. So long as a proposal can make it through the general hub governance approval then validators who don’t see the market fit can simply opt-out. We think this is the key difference the hub can offer. Consumer chains filtering through two levels: first you test governance then you test “basic economics” with each independent validator opting in or out. We can hardly stress how important icsv2 is for the hub.

1 Like
14

This brings up a few questions for me:

  1. Are we focusing on the amount of consensus power, or the number of validators that will opt-in to secure the Consumer Chain?

  2. Will this have the same voting mechanism just with different parameters? A validator could vote yes or abstain themselves but the majority of their stake vote no, should that be taken into consideration at all?

  3. Will all Consumer Chains be able to access the Atomic IBC whether having top-n, PSS, or through a fully permissionless mechanism?

  4. If larger validators don’t want a chain to be secured even by PSS, they could block any chain from being secured even by a large number of validators who just don’t have as much consensus power. If Binance, Coinbase and a few others participate and vote no instead of on these proposals, they could essentially deny partial set security. By staking ATOM, stakeholders are implicitly agreeing to contribute to the security of Consumer Chains, considering this is currently the Hub’s primary function. This is a crucial stepping stone towards the implementation of a fully permissionless model. A permissionless marketplace should ultimately decide security provision.

We’ve seen that this is the case in terms of Consumer Chain upgrades for sure, but I think it will take some time for the average delegator to understand whats going on and adjust accordingly. It will be hard to do this especially with the varying ways validators can participate with their consensus power for rewards. Either way, I agree this is an opportunity for delegators to see who can run the various nodes effectively.

Really excited about the upcoming changes to ICS and appreciate all the work you and the team are doing @jtremback

15

I am not sure delegators voting on this makes any sense. This should be a special proposal type in which only validators can vote. And then each validator vote has weight of 1. Delegated stake doesn’t matter.

2 Likes
16

To address @Tricky 's questions 1-2, and @vixcontango 's question, I’ll just do another overview of how this would work.

First of all the Cosmos SDK governance works like this:

  1. Validators can choose a vote, which will take effect for any of their delegators who haven’t voted. Delegator voting rates are really low so it’s mostly validators voting.
  2. If a proposal does not have at least x% of power voting for any option it does not “meet quorum”, and so does not pass. Quorum can be met by YES, NO, or ABSTAIN votes.
  3. Once a proposal meets quorum, it must have more YES votes than NO votes to pass.

This means that if the required quorum for this proposal type is 5% and a opt-in consumer chain proposal receives:

  • 0.6% YES
  • 4% ABSTAIN
  • 0.5% NO

The proposal will pass, and the validators representing the 0.6% of power that voted yes will be the starting validator set. So, depending on quorum, there is a bar, but it is not high.

Edge cases

What happens if delegators vote differently than their validators? What happens if a validator uses a split vote?

I think that the best solution is that if a validator votes NO at all, even if their delegators vote YES, or they have some proportion of YES in their split vote, it is not opted in.

2 Likes
17

@effortcapital I hear you on the long term inevitability of a completely permissionless system, but I am increasingly leaning towards this permissioned-lite option in the short term to speed deployment of the first version of partial set security. I’ll go a bit more into the challenges of the full permissionless system here and how permissioned-lite sidesteps them:

Chain id squatting

Chain ID squatting is when someone “starts” a bunch of consumer chains just to reserve the chain IDs. This is partially mitigated by the fact that consumer chains are automatically removed after a few weeks of inactivity. However, it would only require one validator to keep the IBC channel of a consumer chain open and to keep it from getting cleaned up. Especially once validators outside of the Hub’s active set can participate (also not in the first version for boring technical reasons), then this cleanup process is no longer an impediment to squatting, since someone could run a validator with 0.000001 ATOM staked, opt into all their squatted chain IDs, and keep the channels open to prevent cleanup.

So there are two options to solve this:

  1. Random chain IDs plus governance reservations: If we give every new consumer chain a chain ID that is a random string of characters, then there can be no squatting. I’m not sure how important it is that chain IDs be human readable but we’d have to look into this. This would cause a problem for chains migrating from being a sovereign chain to a consumer chain, since you cannot switch chain IDs. For these chains, they would need to get a governance proposal passed that would reserve their current chain ID for a smooth transition.
  2. Full nameservice (possibly with governance override): The other option is to go with a full nameservice. Nameservices have code around registering names, transferring them, renewing them, etc. This is obviously well-tread ground, but it all has to be built. This would also need some way for governance to take a name away from someone, again for the case that an existing chain wants to migrate to a consumer chain.

I prefer option 1 because it seems much simpler. There are also probably some complexities around “custody” of a chain ID if it is being reserved for an existing chain, and who controls the chain ID before the chain starts.

Permissionless consumer chain creation and sign up etc interface

We’ll probably want to replicate the 2 week governance period in the permissionless version as a validator signup period, because a chain cannot be created without a validator set. This is of course not hard to do, but it needs to fit into a system that handles the lifecycle, we’ll have to make some prodcut choices around that, and probably it needs an interface. Then we’ll need to get people to use it, educate consumer chain devs and validators on it, etc.

Permissioned lite

The permissioned-lite system I propose here would sidestep all of these questions and use the existing governance path that people are used to, as well as reusing a bunch of code that already exists for creating consumer chains. To me it seems very prudent to go with this first.

2 Likes
18

I totally get how voting works, just trying to establish if the token holders role is for these onboarding proposals vs traditional proposals was any different.

Essentially, overall consensus decides on whether or not the chain gets onboarded no matter the amount of validators that would support the CC, and then the individual validator vote decides if they opt in or not if the CC is accepted. In this case, it’s really just a regular prop so would the decrease to 10% quorum be needed considering validators won’t want to look like they aren’t participating in governance and will most likely vote?

It seems there’s still more permission involved than is ideal in this implementation, but sounds like it would be the simplest route to an early version of PSS. Any version that can be deployed in the short term is a win.

19

I am against permissionless chains entirely.

Outside of the issue of chain id spam, this is also an issue whether validators should be forced to support chains they don’t want. As such validator approval is needed for a chain to launch. If validator approval is needed, they you need some of permissioned launch.

Even more relevant is what type of a chain needs Cosmos Hub security. I don’t think a guy tinkering in a garage needs Cosmos Hub security. He can bootstrap a chain with 5 of his friends and go tinker. When you come to Cosmos Hub, this needs to be something more substantial. I think the threshold here is $100,000. Basically an angel investment. I view each permission-lite chain as an angel investment. A chain is coming an asking the Cosmos Hub community to make an angel investment in it. A permissioned-lite chain with 10 validators is roughly $100,000 of annual costs. I think that should be the minimum requirement to be a consumer chain of the Hub

1 Like