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