In contrast to opt-in consumer chains, where any validator can opt in or out of validation, top-n consumer chains will obligate top validators (the top “n” percent) to validate them. This will be useful for consumer chains that want a guarantee about the level of security they will get, as well as providing a migration path for existing replicated security consumer chains to partial set security.
When consumer chains launch, they can choose to use top-n and what the “n” percent is (top 66% is 24 validators). In contrast to pure opt-in chains, top-n chains will never be able to be launched permissionlessly and will always use a governance proposal.
But there are some choices to be made about who else gets to validate these consumer chains.
In this concept, the top “n” percent of the validator set would be obligated to run a consumer chain, but anybody else who wanted to could opt in as well. The top validators only have downside here- they are forced to run the chain, but anyone else can run it if it is profitable. As a consumer chain’s revenues go up and down, the top validators will have to see it through the tough times, only to see a bunch of smaller validators pop in and soak up the profit when times are good. A lot of people want to see policies disadvantaging top validators, but I’m worried that this goes too far. I’m not worried because I feel bad for top validators, or want to put them at an advantage, but because this will probably make them oppose top-n consumer chains more heavily.
In this concept, the top “n” percent of validators are obligated to run a consumer chain, and smaller validators are not able to run it at all. This gives the top validators a potential upside, unlike inclusive top-n. This will probably make them much more likely to support this type of chain. This concept also has benefits for consumer chains that want a smaller validator set for faster performance. However, it could have centralizing effects on the Hub’s validator set. As a delegator, why would you choose to delegate with a validator that will potentially miss out on rewards?
The third option is the most complicated but also the most flexible. Use an inclusive top-n, but then add another setting to consumer chains: active set size. This setting would work exactly the same as it does on any Cosmos chain: by setting a numerical limit on the number of validators that participate in consensus. This would provide more flexibility, since consumer chains could configure the security guarantees of top-n and the performance aspects of a smaller active set separately. You could also potentially “split the difference” when balancing the concerns of top vs smaller validators against each other. With a top-n of 66% and an active set of 50 (for example), you would have 24 top validators obligated to run the chain, with an additional 26 spots for other validators to opt in.