Merge branch 'main' into shawn/throttle-with-retries-consumer-changes

.github/dependabot.yml

@@ -37,3 +37,13 @@ updates:
     open-pull-requests-limit: 0
     labels:
       - dependencies
+
+  - package-ecosystem: gomod
+    directory: "/"
+    schedule:
+      interval: daily
+    target-branch: "release/v3.1.x"
+    # Only allow automated security-related dependency updates on release branches.
+    open-pull-requests-limit: 0
+    labels:
+      - dependencies

.github/workflows/deploy-docs.yml

@@ -40,7 +40,7 @@ jobs:
           make build-docs
 
       - name: Deploy 🚀
-        uses: JamesIves/[email protected].2
+        uses: JamesIves/[email protected].3
         with:
           branch: gh-pages
           folder: ~/output

.github/workflows/proto-registry.yml

@@ -13,7 +13,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
-      - uses: bufbuild/buf-setup-action@v1.23.1
+      - uses: bufbuild/buf-setup-action@v1.24.0
       - uses: bufbuild/buf-push-action@v1
         with:
           input: "proto"

.github/workflows/proto.yml

@@ -14,7 +14,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
-      - uses: bufbuild/buf-setup-action@v1.23.1
+      - uses: bufbuild/buf-setup-action@v1.24.0
       - uses: bufbuild/buf-breaking-action@v1
         with:
           input: "proto"

.mergify.yml

@@ -26,3 +26,11 @@ pull_request_rules:
       backport:
         branches:
           - release/v3.0.x
+  - name: Backport patches to the release/v3.1.x branch
+    conditions:
+      - base=main
+      - label=A:backport/v3.1.x
+    actions:
+      backport:
+        branches:
+          - release/v3.1.x

CHANGELOG.md

@@ -4,6 +4,7 @@
 
 Add an entry to the unreleased section whenever merging a PR to main that is not targeted at a specific release. These entries will eventually be included in a release.
 
+* (fix!) revert consumer packet data changes from #1037 [#1150](https://github.com/cosmos/interchain-security/pull/1150)
 * (fix!) proper deletion of pending packets [#1146](https://github.com/cosmos/interchain-security/pull/1146)
 * (feat!) optimize pending packets storage on consumer, with migration! [#1037](https://github.com/cosmos/interchain-security/pull/1037)
 

docs/docs/adrs/adr-010-standalone-changeover.md

@@ -0,0 +1,55 @@
+---
+sidebar_position: 11
+title: Standalone to Consumer Changeover
+---
+## ADR 010: Standalone to Consumer Changeover
+
+## Changelog
+
+* 6/30/23: Feature completed, first draft of ADR.
+
+## Status
+
+Implemented
+
+## Context
+
+[Stride](https://github.com/Stride-Labs/stride) will be the first consumer to "changeover" from a standalone cosmos blockchain, to a consumer chain secured by the Cosmos Hub. This document will outline the changes made to the replicated security protocol to support this changeover process.
+
+## Decision
+
+### Process
+
+Prior to the changeover, the consumer chain will have an existing staking keeper and validator set, these may be referred to as the "standalone staking keeper" and "standalone validator set" respectively.  
+
+The first step in the changeover process is to submit a ConsumerAdditionProposal. If the proposal passes, the provider will create a new IBC client for the consumer at spawn time, with the provider's validator set. A consumer genesis will also be constructed by the provider for validators to query. Within this consumer genesis contains the initial validator set for the consumer to apply after the changeover.
+
+Next, the standalone consumer chain runs an upgrade which adds the CCV module, and is properly setup to execute changeover logic.
+
+The consumer upgrade height must be reached after the provider has created the new IBC client. Any replicated security validators who will run the consumer, but are not a part of the sovereign validator set, must sync up a full node before the consumer upgrade height is reached. The disc state of said full node will be used to run the consumer chain after the changeover has completed.
+
+The meat of the changeover logic is that the consumer chain validator set is updated to that which was specified by the provider via the queried consumer genesis. Validators which were a part of the old set, but not the new set, are given zero voting power. Once these validator updates are given to Comet, the set is committed, and in effect 2 blocks later (see [FirstConsumerHeight](https://github.com/cosmos/interchain-security/blob/f10e780df182158d95a30f7cf94588b2d0479309/x/ccv/consumer/keeper/changeover.go#L19)).
+
+A relayer then establishes the new IBC connection between the provider and consumer. The CCV channel handshake is started on top of this connection. Once the CCV channel is established and VSC packets are being relayed, the consumer chain is secured by the provider.
+
+### Changes to CCV Protocol
+
+* Consumer Genesis state is updated to include a `PreCCV` boolean. When this boolean is set true in the  consumer genesis JSON, [special logic](https://github.com/cosmos/interchain-security/blob/f10e780df182158d95a30f7cf94588b2d0479309/x/ccv/consumer/keeper/changeover.go) is executed on InitGenesis to trigger the changeover process on the consumer's first endblocker after the upgrade which adds the CCV module. Note that InitGenesis is not automatically called during chain upgrades, so the consumer must manually call the consumer's InitGenesis method in an upgrade handler.
+* The `ConsumerAdditionProposal` type is updated to include a `DistributionTransmissionChannel` field. This field allows the consumer to use an existing IBC transfer channel to send rewards as a part of the CCV protocol. Consumers that're not changing over from a standalone chain will leave this field blank, indicating that a new transfer channel should be created on top of the same connection as the CCV channel.
+* The CCV consumer keeper is updated to contain an optional reference to the standalone staking keeper. The standalone staking keeper is used to slash for infractions that happened before the changeover was completed. Ie. any infraction from a block height before the changeover, that is submitted after the changeover, will call the standalone staking keeper's slash method. Note that a changeover consumer's  standalone staking keeper becomes a democracy module keeper, so it is possible for a governance token to be slashed.
+
+## Consequences
+
+### Positive
+
+* Existing cosmos chains are now able to onboard over to a consumer chain secured by a provider.
+* The previous staking keepers for such chains can be transitioned to democracy staking module keepers.
+
+### Negative
+
+* The delineation between different types of consumers in this repo becomes less clear. Ie. there is code in the [democracy consumer's app.go](https://github.com/cosmos/interchain-security/blob/f10e780df182158d95a30f7cf94588b2d0479309/app/consumer-democracy/app.go) that only applies to a previously standalone chain, but that file also serves as the base for a normal democracy consumer launched with RS from genesis.
+
+## References
+
+* EPIC: Standalone to Consumer Changeover [#756](https://github.com/cosmos/interchain-security/issues/756)
+* [Changeover diagram from Stride](https://app.excalidraw.com/l/9UFOCMAZLAI/5EVLj0WJcwt)

docs/docs/adrs/adr-template.md

@@ -36,6 +36,6 @@ If the proposed change will be large, please also indicate a way to do the chang
 
 ## References
 
-> Are there any relevant PR comments, issues that led up to this, or articles referrenced for why we made the given design choice? If so link them here!
+> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here!
 
 * {reference link}

docs/docs/consumer-development/consumer-chain-governance.md

@@ -16,7 +16,7 @@ For an example, see the [Democracy Consumer](https://github.com/cosmos/interchai
 
 ## CosmWasm
 
-There several great DAO and governance frameworks written as CosmWasm contracts. These can be used as the main governance system for a consumer chain. Actions triggered by the CosmWasm governance contracts are able to affect parameters and trigger actions on the consumer chain.
+There are several great DAO and governance frameworks written as CosmWasm contracts. These can be used as the main governance system for a consumer chain. Actions triggered by the CosmWasm governance contracts are able to affect parameters and trigger actions on the consumer chain.
 
 For an example, see [Neutron](https://github.com/neutron-org/neutron/).
 

docs/docs/consumer-development/onboarding.md

@@ -20,7 +20,7 @@ To help validators and other node runners onboard onto your chain, please prepar
 
 This should include (at minimum):
 
-- [ ] genesis.json witout CCV data (before the propsal passes)
+- [ ] genesis.json without CCV data (before the proposal passes)
 - [ ] genesis.json with CCV data (after spawn time passes)
 - [ ] information about relevant seed/peer nodes you are running
 - [ ] relayer information (compatible versions)
@@ -73,7 +73,7 @@ Example of a consumer chain addition proposal.
     // will be responsible for starting their consumer chain validator node.
     "spawn_time": "2023-02-28T20:40:00.000000Z",
     // Unbonding period for the consumer chain.
-    // It should should be smaller than that of the provider.
+    // It should be smaller than that of the provider.
     "unbonding_period": 86400000000000,
     // Timeout period for CCV related IBC packets.
     // Packets are considered timed-out after this interval elapses.
@@ -96,7 +96,7 @@ Example of a consumer chain addition proposal.
 	// 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 maintan the existing ibc transfer channel
+    // in order to maintain the existing ibc transfer channel
     "distribution_transmission_channel": "channel-123"
 }
 ```

docs/docs/features/key-assignment.md

@@ -49,7 +49,7 @@ gaiad tx provider assign-consensus-key <consumer-chain-id> '<pubkey>' --from <tx
 - `consumer-chain-id` is the string identifier of the consumer chain, as assigned on the provider chain
 - `consumer-pub-key` has the following format `{"@type":"/cosmos.crypto.ed25519.PubKey","key":"<key>"}`
 
-Check that the key was assigned correcly by querying the provider:
+Check that the key was assigned correctly by querying the provider:
 
 ```bash
 gaiad query provider validator-consumer-key <consumer-chain-id> cosmosvalcons1e....3xsj3ayzf4uv6

docs/docs/features/proposals.md

@@ -32,7 +32,7 @@ Minimal example:
         "revision_number": 1,
     },
     // Unbonding period for the consumer chain.
-    // It should should be smaller than that of the provider.
+    // It should be smaller than that of the provider.
     "unbonding_period": 86400000000000,
     // Timeout period for CCV related IBC packets.
     // Packets are considered timed-out after this interval elapses.
@@ -44,7 +44,7 @@ Minimal example:
     "genesis_hash": "d86d756e10118e66e6805e9cc476949da2e750098fcc7634fd0cc77f57a0b2b0",
     "binary_hash": "376cdbd3a222a3d5c730c9637454cd4dd925e2f9e2e0d0f3702fc922928583f1"
     // relevant for chains performing a sovereign to consumer changeover
-    // in order to maintan the existing ibc transfer channel
+    // in order to maintain the existing ibc transfer channel
     "distribution_transmission_channel": "channel-123"
 }
 ```

docs/docs/features/slashing.md

@@ -3,7 +3,7 @@ sidebar_position: 4
 ---
 
 # Consumer Initiated Slashing
-A consumer chain is essentially a regular Cosmos-SDK based chain that uses the interchain security module to achieve economic security by stake deposited on the provider chain, instead of it's own chain.
+A consumer chain is essentially a regular Cosmos-SDK based chain that uses the interchain security module to achieve economic security by stake deposited on the provider chain, instead of its own chain.
 In essence, provider chain and consumer chains are different networks (different infrastructures) that are bound together by the provider's validator set. By being bound to the provider's validator set, a consumer chain inherits the economic security guarantees of the provider chain (in terms of total stake).
 
 To maintain the proof of stake model, the consumer chain is able to send evidence of infractions (double signing and downtime) to the provider chain so the offending validators can be penalized.
@@ -17,7 +17,7 @@ reported by consumer chains are acted upon on the provider as soon as the provid
 Instead of slashing, the provider will only jail offending validator for the duration of time established in the chain parameters.
 
 :::info
-Slash throttling (sometimes called jail throttling) mechanism insures that only a fraction of the validator set can be jailed at any one time to prevent malicious consumer chains from harming the provider.
+Slash throttling (sometimes called jail throttling) mechanism ensures that only a fraction of the validator set can be jailed at any one time to prevent malicious consumer chains from harming the provider.
 :::
 
 ## Double-signing (equivocation)

docs/docs/introduction/terminology.md

@@ -8,7 +8,7 @@ You may have heard of one or multiple buzzwords thrown around in the cosmos and
 
 ## Shared Security
 
-Shared security is a family of technologies that include optimistic rollups, zk-rollups, sharding and Interchain Security. Ie. any protocol or technology that can allow one blockchain to lend/share it's proof-of-stake security with another blockchain or off-chain process.
+Shared security is a family of technologies that include optimistic rollups, zk-rollups, sharding and Interchain Security. Ie. any protocol or technology that can allow one blockchain to lend/share its proof-of-stake security with another blockchain or off-chain process.
 
 ## Interchain Security
 

go.mod

@@ -3,7 +3,7 @@ module github.com/cosmos/interchain-security/v3
 go 1.20
 
 require (
-	cosmossdk.io/errors v1.0.0-beta.7
+	cosmossdk.io/errors v1.0.0
 	cosmossdk.io/math v1.0.1
 	github.com/cometbft/cometbft v0.37.2
 	github.com/cometbft/cometbft-db v0.8.0
@@ -22,10 +22,10 @@ require (
 	github.com/spf13/cobra v1.6.1
 	github.com/stretchr/testify v1.8.4
 	github.com/tidwall/gjson v1.14.4
-	golang.org/x/crypto v0.8.0 // indirect
+	golang.org/x/crypto v0.11.0 // indirect
 	golang.org/x/exp v0.0.0-20230515195305-f3d0a9c9a5cc
-	golang.org/x/net v0.9.0 // indirect
-	golang.org/x/sys v0.7.0 // indirect
+	golang.org/x/net v0.12.0 // indirect
+	golang.org/x/sys v0.10.0 // indirect
 	google.golang.org/genproto v0.0.0-20230410155749-daa745c078e1
 	google.golang.org/grpc v1.56.2
 	google.golang.org/protobuf v1.31.0
@@ -153,8 +153,8 @@ require (
 	go.etcd.io/bbolt v1.3.7 // indirect
 	go.opencensus.io v0.24.0 // indirect
 	golang.org/x/oauth2 v0.7.0 // indirect
-	golang.org/x/term v0.7.0 // indirect
-	golang.org/x/text v0.9.0 // indirect
+	golang.org/x/term v0.10.0 // indirect
+	golang.org/x/text v0.11.0 // indirect
 	golang.org/x/xerrors v0.0.0-20220907171357-04be3eba64a2 // indirect
 	google.golang.org/api v0.114.0 // indirect
 	google.golang.org/appengine v1.6.7 // indirect