Permissionless ICS will allow anyone to create an opt-in consumer chain, without a governance proposal. This will allow chains to launch more quickly and with less friction.
With this new system, opt-in consumer chains are first registered with a single transaction, then can be initialized with another transaction. After this, settings can be changed with a third transaction (if needed). Once the spawn time has been reached and at least one validator has opted in, the consumer chain is launched.
This update also brings in the concept of a consumer chain owner. This is an account that is able to modify settings of the consumer chain. This can be a single account, a DAO, or even the consumer chain’s governance over an interchain account. This concept will allow for a lot of flexibility in the administration and launch of consumer chains. Here are some ways this could be used:
The development/community DAO of a pre-launch consumer chain sets the spawn time to start the chain once development is complete and enough validators have opted in.
A consumer chain’s on-chain governance modifies the consumer chain’s DenyList to exclude exchange validators.
A consumer chain’s governance raises the ValidatorNumberCap to let more validators into its active set.
Technical details
The ADR contains a very complete specification of the protocol and required code changes, but we’ve included two diagrams below to illustrate some of the concepts.
I think there needs to be a validator minimum to launch a chain permissionlessly. I think that minimum should be 20 validators. I could consider a minimum of 5 as well but a chain with 5 validators is really a garage chain and I am not sure garage chains need to run on the Hub. To avoid spam, the chain creation process should include the assignment of the initial set of validators. If the chain creator can’t get enough validators, they shouldn’t be able to create the chain.
Hey thanks, I am totally on board with not wanting spam. However, I think that in general spam should be filtered on frontends since they are more flexible and better equipped to do it. I cover this here: CHIPs signaling phase: Forge (ICS launchpad)
I’m proposing that initially a chain should have at least one validator opted in to be visible on the frontend, but this could be raised, or other conditions could be added.
For me, showing 1 validator blockchains is spam. I mean that one validator can do what they want with that blockchain. I think you need at least 2 validators to be calling yourself a “distributed” system of any sort. And to be solving any sort of Byzantine generals problem, you need at least 3 parties, one of which can’t be trusted. lol
I would say 3 validators should be the absolute minimum.
We fully support this proposition and would simply note the relevant remarks brought by @vixcontango
We will even suggest to raise that minimum requirement to 4. This is the threshold required by a BFT consensus to achieve minimal liveness safety (as one defaulting node still allows the system to continue operation). Nevertheless we will welcome this CHIP signaling with a warm yes vote. Once again taking the opportunity to thank all the teams working diligently on these improvement proposals.
