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.
Inclusive top-n
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.
Exclusive top-n
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?
Inclusive top-n plus custom active set
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.