Remove references to max rank

.changelog/unreleased/features/provider/2035-min-stake-max-rank.md

@@ -1,2 +1,2 @@
-- Add minimum stake and maximum validator rank requirements to let consumer chains
+- Add minimum stake requirement to let consumer chains
   determine requirements for validators that validate their chain. ([\#2035](https://github.com/cosmos/interchain-security/pull/2035))

.changelog/unreleased/state-breaking/provider/2035-min-stake-max-rank.md

@@ -1,2 +1,2 @@
-- Add minimum stake and maximum validator rank requirements to let consumer chains
+- Add minimum stake requirement to let consumer chains
   determine requirements for validators that validate their chain. ([\#2035](https://github.com/cosmos/interchain-security/pull/2035))

docs/docs/adrs/adr-017-allowing-inactive-validators.md

@@ -70,11 +70,6 @@ set of consumer chains.
 
 To mitigate risks from validators with little stake, we introduce a minimum stake requirement for validators to be able to validate on consumer chains, which can be set by each consumer chain independently, with a default value set by the provider chain.
 
-Additionally, we independently allow individual consumer chains to set a maximum rank for validators.
-This means that validators above a certain position in the validator set cannot validate on the consumer chain.
-Setting this to be equal to `MaxProviderConsensusValidators` effectively disables inactive validators from validating on the consumer chain and thus
-disables the main feature described in this ADR.
-
 Additional risk mitigations are to increase the active set size slowly, and to monitor the effects on the network closely. For the first iteration, we propose to increase the active set size to 200 validators (while keeping the consensus validators to 180), thus letting the 20 validators with the most stake outside of the active set validate on consumer chains.
 
 ## Testing Scenarios
@@ -156,7 +151,7 @@ Checked as part of the e2e tests `inactive-vals-mint` (scenario with 1 active va
 
 ### Scenarios 8: Inactive validators can validate on consumer chains
 
-An inactive validator can opt in and validate on consumer chains (if min stake and max rank allow it)
+An inactive validator can opt in and validate on consumer chains (if min stake allows it)
 
 Checked as part of the e2e test `inactive-provider-validators-on-consumer`.
 

docs/docs/features/power-shaping.md

@@ -36,11 +36,9 @@ power. For example, consider that the top validator `V` on the provider chain ha
 then if `V` is denylisted, the consumer chain would only be secured by at least 40% of the provider's power.
 :::
 
-4) **Maximum validator rank**: The consumer chain can specify a maximum position in the validator set that a validator can have on the provider chain to be able to validate the consumer chain. This can be used to ensure that only validators with relatively large amounts of stake can validate the consumer chain. For example, setting this to 20 would mean only the 20 validators with the most voting stake on the provider chain can validate the consumer chain.
+4) **Minimum validator stake**: The consumer chain can specify a minimum amount of stake that a validator must have on the provider chain to be able to validate the consumer chain. This can be used to ensure that only validators with a certain amount of stake can validate the consumer chain. For example, setting this to 1000 would mean only validators with at least 1000 tokens staked on the provider chain can validate the consumer chain.
 
-5) **Minimum validator stake**: The consumer chain can specify a minimum amount of stake that a validator must have on the provider chain to be able to validate the consumer chain. This can be used to ensure that only validators with a certain amount of stake can validate the consumer chain. For example, setting this to 1000 would mean only validators with at least 1000 tokens staked on the provider chain can validate the consumer chain.
-
-6) **Allow inactive validators**: The consumer chain can specify whether provider validators that are *not* active in consensus may validate on the consumer chain or not. If this is set to `false`, only active validators on the provider chain can validate the consumer chain. If this is set to `true`, inactive validators can also validate the consumer chain. This can be useful for chains that want to have a larger validator set than the active validators on the provider chain, or for chains that want to have a more decentralized validator set. Consumer chains that enable this feature should strongly consider setting a maximum validator rank and/or a minimum validator stake to ensure that only validators with some reputation/stake can validate the chain. This parameter is set to `false` by default.
+5) **Allow inactive validators**: The consumer chain can specify whether provider validators that are *not* active in consensus may validate on the consumer chain or not. If this is set to `false`, only active validators on the provider chain can validate the consumer chain. If this is set to `true`, inactive validators can also validate the consumer chain. This can be useful for chains that want to have a larger validator set than the active validators on the provider chain, or for chains that want to have a more decentralized validator set. Consumer chains that enable this feature should strongly consider setting a minimum validator stake to ensure that only validators with some reputation/stake can validate the chain. This parameter is set to `false` by default.
 
 All these mechanisms are set by the consumer chain in the `ConsumerAdditionProposal`. They operate *solely on the provider chain*, meaning the consumer chain simply receives the validator set after these rules have been applied and does not have any knowledge about whether they are applied.
 

tests/e2e/main.go

@@ -337,7 +337,7 @@ func getTestCases(selectedPredefinedTests, selectedTestFiles TestSet, providerVe
 			"partial-set-security-modification-proposal",
 			"active-set-changes", "inactive-vals-topN",
 			"inactive-provider-validators-on-consumer", "inactive-provider-validators-governance",
-			"max-rank", "min-stake", "inactive-vals-mint",
+			"min-stake", "inactive-vals-mint",
 		}
 		if includeMultiConsumer != nil && *includeMultiConsumer {
 			selectedPredefinedTests = append(selectedPredefinedTests, "multiconsumer")

tests/e2e/steps_inactive_vals.go

@@ -733,7 +733,7 @@ func stepsMinStake() []Step {
 				},
 			},
 			{
-				// we start all the validators, but due to max rank of 1, only carol can validate
+				// we start all the validators, but due to the min stake, only carol can validate
 				Action: StartConsumerChainAction{
 					ConsumerChain: ChainID("consu"),
 					ProviderChain: ChainID("provi"),

tests/integration/partial_set_security_test.go

@@ -19,12 +19,12 @@ import (
 // won't correspond to at least one voting power
 const stake_multiplier = 1000000
 
-// TestMinStakeMaxRank tests the min stake and max rank parameters.
+// TestMinStake tests the min stake parameter.
 // It starts a provider and single consumer chain,
 // sets the initial powers according to the input, and then
-// sets the min stake and max rank parameters according to the test case.
+// sets the min stake parameter according to the test case.
 // Finally, it checks that the validator set on the consumer chain is as expected
-// according to the min stake and max rank parameters.
+// according to the min stake parameter.
 func TestMinStake(t *testing.T) {
 	testCases := []struct {
 		name                string
@@ -138,7 +138,7 @@ func TestMinStake(t *testing.T) {
 
 			// adjust parameters
 
-			// set the maxRank and minStake according to the test case
+			// set the minStake according to the test case
 			providerKeeper.SetMinStake(s.providerChain.GetContext(), s.consumerChain.ChainID, tc.minStake)
 
 			// undelegate and delegate to trigger a vscupdate