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

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…

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

jtremback:

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.

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.

jtremback: 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. 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…

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

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.

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?

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.

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.

@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.

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.

@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…

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

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.

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.

jtremback: 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. This brings up a few questions for me: • Are we focusing on the amount of consensus power, or the number of validators that will opt-in to secure the Consumer Chain? • 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? • Will all…

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

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.

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: • 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. • 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. • 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…

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

@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: • Random chain IDs plus governance reservations: If we…

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

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.

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