feat: first iteration on Permissionless ICS

Makefile

@@ -33,8 +33,8 @@ install: go.sum
 		go install -ldflags "$(democracyFlags)" ./cmd/interchain-security-cdd
 		go install -ldflags "$(standaloneFlags)" ./cmd/interchain-security-sd
 
-# run all tests: unit, integration, diff, and E2E
-test: test-unit test-integration test-mbt test-e2e
+# run all tests: unit, integration, and E2E
+test: test-unit test-integration test-e2e
 
 # shortcut for local development
 test-dev: test-unit test-integration test-mbt
@@ -271,4 +271,4 @@ build-docs-local:
 ###############################################################################
 
 e2e-traces:
-	cd tests/e2e; go test -timeout 30s -run ^TestWriteExamples -v
+	cd tests/e2e; go test -timeout 30s -run ^TestWriteExamples -v

docs/docs/adrs/adr-019-permissionless-ics.md

@@ -95,8 +95,7 @@ consumer chains with the exact same `chainId`, and it is the responsibility of t
 to interact with by providing the right `consumerId`.
 
 Note that with Permissionless ICS, all interactions on a consumer chain have to use the `consumerId` instead of the `chainId`.
-For example, if a validator opts in on a chain using `MsgOptIn`, the validator has to provide the `consumerId`. To also
-provide the `consumerId` for Top N consumers chains, we store a mapping between `proposalID` to `consumerId`. This storing
+For example, if a validator opts in on a chain using `MsgOptIn`, the validator has to provide the `consumerId`. To also provide the `consumerId` for Top N consumers chains, we store a mapping between `proposalID` to `consumerId`. This storing
 takes place in the [`AfterProposalSubmission`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.8/x/gov/types/hooks.go#L19) hook.
 Specifically, for the equivocation evidence, we update the `MsgSubmitConsumerMisbehaviour` and `MsgSubmitConsumerDoubleVoting` messages to include the `consumerId`,
 and change [Hermes](https://github.com/informalsystems/hermes) to include `consumerId` in those constructed messages as well.
@@ -161,9 +160,9 @@ where `ConsumerRegistrationRecord` contains information about the to-be-launched
 
 ```protobuf
 message ConsumerRegistrationRecord {
-  // the title of the chain to-be-launched 
+  // the title of the chain to-be-registered 
   string title;
-  // the description of the chain to-be-launched
+  // the description of the chain to-be-registered
   string description;
   // the chain id of the new consumer chain
   string chain_id;
@@ -183,7 +182,7 @@ To move an Opt In consumer chain to its initialized phase, we issue a `MsgInitia
 
 ```protobuf
 message MsgInitializeConsumer {
-  // consumer id of the to-be-updated consumer chain
+  // consumer id of the to-be-initialized consumer chain
   string consumer_id;
   // the initialization record that contains initialization parameters for the upcoming chain
   ConsumerInitializationRecord initialization_record;
@@ -332,6 +331,9 @@ Because we only have two consumer chains at the moment, this is not going to be
 consumer chains that are being voted upon. Similarly, all the messages, queries, etc. would need to be changed to operate on a `consumerId`
 instead of a `chainId`.
 
+To prevent a validator from accidentally opting in to a wrong chain, we disallow a validator from opting in to two or more
+different chains (different `consumerId`) with the same `chainId`.
+
 It is **important** to migrate any ongoing `ConsumerAdditionProposal`s when we upgrade before we actually deprecate `ConsumerAdditionProposal`s.
 
 ## Consequences

proto/interchain_security/ccv/provider/v1/provider.proto

@@ -21,6 +21,7 @@ import "amino/amino.proto";
 // These schemas can change with proper consideration of compatibility or migration. 
 // 
 
+// WARNING: This message is deprecated in favor of `MsgCreateConsumer`.
 // ConsumerAdditionProposal is a governance proposal on the provider chain to
 // spawn a new consumer chain. If it passes, then all validators on the provider
 // chain are expected to validate the consumer chain at spawn time or get
@@ -112,6 +113,7 @@ message ConsumerAdditionProposal {
   bool allow_inactive_vals = 21;
 }
 
+// WARNING: This message is deprecated in favor of `MsgRemoveConsumer`.
 // ConsumerRemovalProposal is a governance proposal on the provider chain to
 // remove (and stop) a consumer chain. If it passes, all the consumer chain's
 // state is removed from the provider chain. The outstanding unbonding operation
@@ -132,6 +134,7 @@ message ConsumerRemovalProposal {
       [ (gogoproto.stdtime) = true, (gogoproto.nullable) = false ];
 }
 
+// WARNING: This message is deprecated in favor of `MsgUpdateConsumer`.
 // ConsumerModificationProposal is a governance proposal on the provider chain to modify parameters of a running
 // consumer chain. If it passes, the consumer chain's state is updated to take into account the newest params.
 message ConsumerModificationProposal {
@@ -285,6 +288,7 @@ message ConsumerRemovalProposals {
 // AddressList contains a list of consensus addresses
 message AddressList { repeated bytes addresses = 1; }
 
+// WARNING: This message is deprecated and is not used.
 // ChannelToChain is used to map a CCV channel ID to the consumer chainID
 message ChannelToChain {
   string channel_id = 1;
@@ -362,3 +366,101 @@ message ConsumerRewardsAllocation {
     (gogoproto.castrepeated) = "github.com/cosmos/cosmos-sdk/types.DecCoins"
   ];
 }
+
+// ConsumerMetadata contains general information about the registered chain
+message ConsumerMetadata {
+  // the name of the chain
+  string name = 1;
+  // the description of the chain
+  string description = 2;
+  // the metadata (e.g., GitHub repository URL) of the chain
+  string metadata = 3;
+}
+
+// ConsumerInitializationParameters are the parameters needed to launch a chain
+message ConsumerInitializationParameters {
+  // ---------- ---------- ----------
+  // Following fields are used when the consumer chain launches and are not needed by the provider afterwards.
+  // ---------- ---------- ----------
+
+  // the proposed initial height of new consumer chain.
+  // For a completely new chain, this will be {0,1}. However, it may be
+  // different if this is a chain that is converting to a consumer chain.
+  ibc.core.client.v1.Height initial_height = 1 [ (gogoproto.nullable) = false ];
+  // The hash of the consumer chain genesis state without the consumer CCV
+  // module genesis params. It is used for off-chain confirmation of
+  // genesis.json validity by validators and other parties.
+  bytes genesis_hash = 2;
+  // The hash of the consumer chain binary that should be run by validators on
+  // chain initialization. It is used for off-chain confirmation of binary
+  // validity by validators and other parties.
+  bytes binary_hash = 3;
+  // spawn time is the time on the provider chain at which the consumer chain
+  // genesis is finalized and all validators will be responsible for starting
+  // their consumer chain validator node.
+  google.protobuf.Timestamp spawn_time = 4 [ (gogoproto.nullable) = false, (gogoproto.stdtime) = true ];
+  // Unbonding period for the consumer,
+  // which should be smaller than that of the provider in general.
+  google.protobuf.Duration unbonding_period = 5  [ (gogoproto.nullable) = false, (gogoproto.stdduration) = true ];
+
+
+  // ---------- ---------- ----------
+  // Following fields are used to construct the consumer genesis of the to-be-launched consumer chain
+  // and are set up as params on the consumer chain. Those params can then be directly modified by the consumer chain.
+  // ---------- ---------- ----------
+
+  // Sent CCV related IBC packets will timeout after this duration
+  google.protobuf.Duration ccv_timeout_period = 6  [ (gogoproto.nullable) = false, (gogoproto.stdduration) = true ];
+  // Sent transfer related IBC packets will timeout after this duration
+  google.protobuf.Duration transfer_timeout_period = 7 [ (gogoproto.nullable) = false, (gogoproto.stdduration) = true ];
+  // The fraction of tokens allocated to the consumer redistribution address
+  // during distribution events. The fraction is a string representing a
+  // decimal number. For example "0.75" would represent 75%.
+  string consumer_redistribution_fraction = 8;
+  // BlocksPerDistributionTransmission is the number of blocks between
+  // ibc-token-transfers from the consumer chain to the provider chain. On
+  // sending transmission event, `consumer_redistribution_fraction` of the
+  // accumulated tokens are sent to the consumer redistribution address.
+  int64 blocks_per_distribution_transmission = 9;
+  // The number of historical info entries to persist in store.
+  // This param is a part of the cosmos sdk staking module. In the case of
+  // a ccv enabled consumer chain, the ccv module acts as the staking module.
+  int64 historical_entries = 10;
+  // The ID of a token transfer channel used for the Reward Distribution
+  // sub-protocol. If DistributionTransmissionChannel == "", a new transfer
+  // channel is created on top of the same connection as the CCV channel.
+  // Note that transfer_channel_id is the ID of the channel end on the consumer
+  // chain. it is most relevant for chains performing a sovereign to consumer
+  // changeover in order to maintain the existing ibc transfer channel
+  string distribution_transmission_channel = 11;
+}
+
+// PowerShapingParameters contains parameters that shape the validator set that we send to the consumer chain
+message PowerShapingParameters {
+  // Corresponds to the percentage of validators that have to validate the chain under the Top N case.
+  // For example, 53 corresponds to a Top 53% chain, meaning that the top 53% provider validators by voting power
+  // have to validate the proposed consumer chain. top_N can either be 0 or any value in [50, 100].
+  // A chain can join with top_N == 0 as an Opt In chain, or with top_N ∈ [50, 100] as a Top N chain.
+  uint32 top_N = 1;
+  // Corresponds to the maximum power (percentage-wise) a validator can have on the consumer chain. For instance, if
+  // `validators_power_cap` is set to 32, it means that no validator can have more than 32% of the voting power on the
+  // consumer chain. Note that this might not be feasible. For example, think of a consumer chain with only
+  // 5 validators and with `validators_power_cap` set to 10%. In such a scenario, at least one validator would need
+  // to have more than 20% of the total voting power. Therefore, `validators_power_cap` operates on a best-effort basis.
+  uint32 validators_power_cap = 2;
+  // Corresponds to the maximum number of validators that can validate a consumer chain.
+  // Only applicable to Opt In chains. Setting `validator_set_cap` on a Top N chain is a no-op.
+  uint32 validator_set_cap = 3;
+  // corresponds to a list of provider consensus addresses of validators that are the ONLY ones that can validate the consumer chain
+  repeated string allowlist = 4;
+  // corresponds to a list of provider consensus addresses of validators that CANNOT validate the consumer chain
+  repeated string denylist = 5;
+  // Corresponds to the minimal amount of (provider chain) stake required to validate on the consumer chain.
+  uint64 min_stake = 6;
+  // Corresponds to whether inactive validators are allowed to validate the consumer chain.
+  bool allow_inactive_vals = 7;
+}
+
+// ConsumerIds contains consumer ids of chains
+// Used so we can easily (de)serialize slices of strings
+message ConsumerIds { repeated string ids = 1; }