backport rc1 changes (#251)

* fix link (#250)

* Update outdated documentation (#252)

* fix #85

* fix #77

* add genesis restart docs (#247)

* add genesis restart docs

* add small note

* bump SDK dep to v0.43.0-rc1 (#254)

* update changelog dates

CHANGELOG.md

@@ -34,7 +34,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
 
 # Changelog
 
-## [v1.0.0-rc0](https://github.com/cosmos/ibc-go/releases/tag/v1.0.0-rc0) - 2021-07-07
+## [v1.0.0-rc1](https://github.com/cosmos/ibc-go/releases/tag/v1.0.0-rc1) - 2021-07-15
 
 ### Bug Fixes
 

docs/ibc/integration.md

@@ -17,15 +17,15 @@ Integrating the IBC module to your SDK-based application is straighforward. The
 - Add required modules to the `module.BasicManager`
 - Define additional `Keeper` fields for the new modules on the `App` type
 - Add the module's `StoreKeys` and initialize their `Keepers`
-- Set up corresponding routers and routes for the `ibc` and `evidence` modules
+- Set up corresponding routers and routes for the `ibc` module
 - Add the modules to the module `Manager`
 - Add modules to `Begin/EndBlockers` and `InitGenesis`
 - Update the module `SimulationManager` to enable simulations
 
 ### Module `BasicManager` and `ModuleAccount` permissions
 
-The first step is to add the following modules to the `BasicManager`: `x/capability`, `x/ibc`,
-`x/evidence` and `x/ibc-transfer`. After that, we need to grant `Minter` and `Burner` permissions to
+The first step is to add the following modules to the `BasicManager`: `x/capability`, `x/ibc`, 
+and `x/ibc-transfer`. After that, we need to grant `Minter` and `Burner` permissions to
 the `ibc-transfer` `ModuleAccount` to mint and burn relayed tokens.
 
 ```go
@@ -36,7 +36,6 @@ var (
     // ...
     capability.AppModuleBasic{},
     ibc.AppModuleBasic{},
-    evidence.AppModuleBasic{},
     transfer.AppModuleBasic{}, // i.e ibc-transfer module
   )
 
@@ -60,7 +59,6 @@ type App struct {
   // other keepers
   // ...
   IBCKeeper        *ibckeeper.Keeper // IBC Keeper must be a pointer in the app, so we can SetRouter on it correctly
-  EvidenceKeeper   evidencekeeper.Keeper // required to set up the client misbehaviour route
   TransferKeeper   ibctransferkeeper.Keeper // for cross-chain fungible token transfers
 
   // make scoped keepers public for test purposes
@@ -105,11 +103,6 @@ func NewApp(...args) *App {
   )
   transferModule := transfer.NewAppModule(app.TransferKeeper)
 
-  // Create evidence Keeper for to register the IBC light client misbehaviour evidence route
-  evidenceKeeper := evidencekeeper.NewKeeper(
-    appCodec, keys[evidencetypes.StoreKey], &app.StakingKeeper, app.SlashingKeeper,
-  )
-
   // .. continues
 }
 ```
@@ -126,12 +119,6 @@ IBC module.
 Adding the module routes allows the IBC handler to call the appropriate callback when processing a
 channel handshake or a packet.
 
-The second `Router` that is required is the evidence module router. This router handles genenal
-evidence submission and routes the business logic to each registered evidence handler. In the case
-of IBC, it is required to submit evidence for [light client
-misbehaviour](https://github.com/cosmos/ics/tree/master/spec/ics-002-client-semantics#misbehaviour)
-in order to freeze a client and prevent further data packets from being sent/received.
-
 Currently, a `Router` is static so it must be initialized and set correctly on app initialization.
 Once the `Router` has been set, no new routes can be added.
 
@@ -147,19 +134,6 @@ func NewApp(...args) *App {
   // No more routes can be added
   app.IBCKeeper.SetRouter(ibcRouter)
 
-  // create static Evidence routers
-
-  evidenceRouter := evidencetypes.NewRouter().
-    // add IBC ClientMisbehaviour evidence handler
-    AddRoute(ibcclient.RouterKey, ibcclient.HandlerClientMisbehaviour(app.IBCKeeper.ClientKeeper))
-
-  // Setting Router will finalize all routes by sealing router
-  // No more routes can be added
-  evidenceKeeper.SetRouter(evidenceRouter)
-
-  // set the evidence keeper from the section above
-  app.EvidenceKeeper = *evidenceKeeper
-
   // .. continues
 ```
 
@@ -176,7 +150,6 @@ func NewApp(...args) *App {
     // other modules
     // ...
     capability.NewAppModule(appCodec, *app.CapabilityKeeper),
-    evidence.NewAppModule(app.EvidenceKeeper),
     ibc.NewAppModule(app.IBCKeeper),
     transferModule,
   )
@@ -187,7 +160,6 @@ func NewApp(...args) *App {
     // other modules
     // ...
     capability.NewAppModule(appCodec, *app.CapabilityKeeper),
-    evidence.NewAppModule(app.EvidenceKeeper),
     ibc.NewAppModule(app.IBCKeeper),
     transferModule,
   )
@@ -219,10 +191,10 @@ localhost (_aka_ loopback) client.
 func NewApp(...args) *App {
   // .. continuation from above
 
-  // add evidence, staking and ibc modules to BeginBlockers
+  // add staking and ibc modules to BeginBlockers
   app.mm.SetOrderBeginBlockers(
     // other modules ...
-    evidencetypes.ModuleName, stakingtypes.ModuleName, ibchost.ModuleName,
+    stakingtypes.ModuleName, ibchost.ModuleName,
   )
 
   // ...
@@ -233,7 +205,7 @@ func NewApp(...args) *App {
   app.mm.SetOrderInitGenesis(
     capabilitytypes.ModuleName,
     // other modules ...
-    ibchost.ModuleName, evidencetypes.ModuleName, ibctransfertypes.ModuleName,
+    ibchost.ModuleName, ibctransfertypes.ModuleName,
   )
 
   // .. continues

docs/ibc/upgrades/genesis-restart.md

@@ -0,0 +1,49 @@
+<!--
+order: 3
+-->
+
+# Genesis Restart Upgrades
+
+Learn how to upgrade your chain and counterparty clients using genesis restarts. {synopsis}
+
+**NOTE**: Regular genesis restarts are currently unsupported by relayers!
+
+### IBC Client Breaking Upgrades
+
+IBC client breaking upgrades are possible using genesis restarts. 
+It is highly recommended to use the in-place migrations instead of a genesis restart.
+Genesis restarts should be used sparingly and as backup plans. 
+
+Genesis restarts still require the usage of an IBC upgrade proposal in order to correctly upgrade counterparty clients.
+
+#### Step-by-Step Upgrade Process for SDK Chains
+
+If the IBC-connected chain is conducting an upgrade that will break counterparty clients, it must ensure that the upgrade is first supported by IBC using the [IBC Client Breaking Upgrade List](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/upgrades/quick-guide.md#ibc-client-breaking-upgrades) and then execute the upgrade process described below in order to prevent counterparty clients from breaking.
+
+1. Create a 02-client [`UpgradeProposal`](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/proto-docs.md#upgradeproposal) with an `UpgradePlan` and a new IBC ClientState in the `UpgradedClientState` field. Note that the `UpgradePlan` must specify an upgrade height **only** (no upgrade time), and the `ClientState` should only include the fields common to all valid clients and zero out any client-customizable fields (such as TrustingPeriod).
+2. Vote on and pass the `UpgradeProposal`
+3. Halt the node after successful upgrade. 
+4. Export the genesis file.
+5. Swap to the new binary.
+6. Run migrations on the genesis file.
+7. Remove the `UpgradeProposal` plan from the genesis file. This may be done by migrations.
+8. Change desired chain-specific fields (chain id, unbonding period, etc). This may be done by migrations.
+8. Reset the node's data.
+9. Start the chain.
+
+Upon the `UpgradeProposal` passing, the upgrade module will commit the UpgradedClient under the key: `upgrade/UpgradedIBCState/{upgradeHeight}/upgradedClient`. On the block right before the upgrade height, the upgrade module will also commit an initial consensus state for the next chain under the key: `upgrade/UpgradedIBCState/{upgradeHeight}/upgradedConsState`.
+
+Once the chain reaches the upgrade height and halts, a relayer can upgrade the counterparty clients to the last block of the old chain. They can then submit the proofs of the `UpgradedClient` and `UpgradedConsensusState` against this last block and upgrade the counterparty client.
+
+#### Step-by-Step Upgrade Process for Relayers Upgrading Counterparty Clients
+
+These steps are identical to the regular [IBC client breaking upgrade process](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/upgrades/quick-guide.md#step-by-step-upgrade-process-for-relayers-upgrading-counterparty-clients).
+
+### Non-IBC Client Breaking Upgrades
+
+While ibc-go supports genesis restarts which do not break IBC clients, relayers do not support this upgrade path. 
+Here is a tracking issue on [Hermes](https://github.com/informalsystems/ibc-rs/issues/1152).
+Please do not attempt a regular genesis restarts unless you have a tool to update counterparty clients correctly.
+
+
+

docs/ibc/upgrades/quick-guide.md

@@ -30,10 +30,10 @@ Note: Since upgrades are only implemented for Tendermint clients, this doc only
 
 If the IBC-connected chain is conducting an upgrade that will break counterparty clients, it must ensure that the upgrade is first supported by IBC using the list above and then execute the upgrade process described below in order to prevent counterparty clients from breaking.
 
-1. Create a `SoftwareUpgradeProposal` with an `UpgradePlan` that includes the new IBC ClientState in the `UpgradedClientState`. Note that the `UpgradePlan` must specify an upgrade height **only** (no upgrade time), and the `ClientState` should only include the fields common to all valid clients and zero out any client-customizable fields (such as TrustingPeriod).
-2. Vote on and pass the `SoftwareUpgradeProposal`
+1. Create a 02-client [`UpgradeProposal`](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/proto-docs.md#upgradeproposal) with an `UpgradePlan` and a new IBC ClientState in the `UpgradedClientState` field. Note that the `UpgradePlan` must specify an upgrade height **only** (no upgrade time), and the `ClientState` should only include the fields common to all valid clients and zero out any client-customizable fields (such as TrustingPeriod).
+2. Vote on and pass the `UpgradeProposal`
 
-Upon the `SoftwareUpgradeProposal` passing, the upgrade module will commit the UpgradedClient under the key: `upgrade/UpgradedIBCState/{upgradeHeight}/upgradedClient`. On the block right before the upgrade height, the upgrade module will also commit an initial consensus state for the next chain under the key: `upgrade/UpgradedIBCState/{upgradeHeight}/upgradedConsState`.
+Upon the `UpgradeProposal` passing, the upgrade module will commit the UpgradedClient under the key: `upgrade/UpgradedIBCState/{upgradeHeight}/upgradedClient`. On the block right before the upgrade height, the upgrade module will also commit an initial consensus state for the next chain under the key: `upgrade/UpgradedIBCState/{upgradeHeight}/upgradedConsState`.
 
 Once the chain reaches the upgrade height and halts, a relayer can upgrade the counterparty clients to the last block of the old chain. They can then submit the proofs of the `UpgradedClient` and `UpgradedConsensusState` against this last block and upgrade the counterparty client.
 
@@ -51,4 +51,4 @@ Thus, the upgrade process for relayers trying to upgrade the counterparty client
 
 The Tendermint client on the counterparty chain will verify that the upgrading chain did indeed commit to the upgraded client and upgraded consensus state at the upgrade height (since the upgrade height is included in the key). If the proofs are verified against the upgrade height, then the client will upgrade to the new client while retaining all of its client-customized fields. Thus, it will retain its old TrustingPeriod, TrustLevel, MaxClockDrift, etc; while adopting the new chain-specified fields such as UnbondingPeriod, ChainId, UpgradePath, etc. Note, this can lead to an invalid client since the old client-chosen fields may no longer be valid given the new chain-chosen fields. Upgrading chains should try to avoid these situations by not altering parameters that can break old clients. For an example, see the UnbondingPeriod example in the supported upgrades section.
 
-The upgraded consensus state will serve purely as a basis of trust for future `UpdateClientMsgs` and will not contain a consensus root to perform proof verification against. Thus, relayers must submit an `UpdateClientMsg` with a header from the new chain so that the connection can be used for proof verification again.
+The upgraded consensus state will serve purely as a basis of trust for future `UpdateClientMsgs` and will not contain a consensus root to perform proof verification against. Thus, relayers must submit an `UpdateClientMsg` with a header from the new chain so that the connection can be used for proof verification again.

docs/migrations/ibc-migration-043.md

@@ -164,7 +164,7 @@ The solo machine has replaced the FrozenSequence uint64 field with a IsFrozen bo
 
 Application developers need to update their `OnRecvPacket` callback logic. 
 
-The `OnRecvPacket` callback has been modified to only return the acknowledgement. The acknowledgement returned must implement the `Acknowledgement` interface. The acknowledgement should indicate if it represents a successful processing of a packet by returning true on `Success()` and false in all other cases. A return value of false on `Success()` will result in all state changes which occurred in the callback being discarded. More information can be found in the [documentation](https://github.com/cosmos/ibc-go/blob/main/docs/custom.md#receiving-packets).
+The `OnRecvPacket` callback has been modified to only return the acknowledgement. The acknowledgement returned must implement the `Acknowledgement` interface. The acknowledgement should indicate if it represents a successful processing of a packet by returning true on `Success()` and false in all other cases. A return value of false on `Success()` will result in all state changes which occurred in the callback being discarded. More information can be found in the [documentation](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/apps.md#receiving-packets).
 
 The `OnRecvPacket`, `OnAcknowledgementPacket`, and `OnTimeoutPacket` callbacks are now passed the `sdk.AccAddress` of the relayer who relayed the IBC packet. Applications may use or ignore this information. 
 

go.mod

@@ -7,7 +7,7 @@ replace github.com/gogo/protobuf => github.com/regen-network/protobuf v1.3.3-alp
 require (
 	github.com/armon/go-metrics v0.3.9
 	github.com/confio/ics23/go v0.6.6
-	github.com/cosmos/cosmos-sdk v0.43.0-rc0
+	github.com/cosmos/cosmos-sdk v0.43.0-rc1
 	github.com/gogo/protobuf v1.3.3
 	github.com/golang/protobuf v1.5.2
 	github.com/gorilla/mux v1.8.0

go.sum

@@ -164,8 +164,8 @@ github.com/coreos/go-systemd v0.0.0-20190321100706-95778dfbb74e/go.mod h1:F5haX7
 github.com/coreos/go-systemd/v22 v22.3.2/go.mod h1:Y58oyj3AT4RCenI/lSvhwexgC+NSVTIJ3seZv2GcEnc=
 github.com/coreos/pkg v0.0.0-20160727233714-3ac0863d7acf/go.mod h1:E3G3o1h8I7cfcXa63jLwjI0eiQQMgzzUDFVpN/nH/eA=
 github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f/go.mod h1:E3G3o1h8I7cfcXa63jLwjI0eiQQMgzzUDFVpN/nH/eA=
-github.com/cosmos/cosmos-sdk v0.43.0-rc0 h1:+WGHEo1N/2zRSpWpKmuquTjDskL4j9K6zTc7CfDpfOM=
-github.com/cosmos/cosmos-sdk v0.43.0-rc0/go.mod h1:ctcrTEAhei9s8O3KSNvL0dxe+fVQGp07QyRb/7H9JYE=
+github.com/cosmos/cosmos-sdk v0.43.0-rc1 h1:3QGgMqwLmzW+015P4ZEIQ+wRj7TrVU063D2QpHc2Syw=
+github.com/cosmos/cosmos-sdk v0.43.0-rc1/go.mod h1:ctcrTEAhei9s8O3KSNvL0dxe+fVQGp07QyRb/7H9JYE=
 github.com/cosmos/go-bip39 v0.0.0-20180819234021-555e2067c45d/go.mod h1:tSxLoYXyBmiFeKpvmq4dzayMdCjCnu8uqmCysIGBT2Y=
 github.com/cosmos/go-bip39 v1.0.0 h1:pcomnQdrdH22njcAatO0yWojsUnCO3y2tNoV1cb6hHY=
 github.com/cosmos/go-bip39 v1.0.0/go.mod h1:RNJv0H/pOIVgxw6KS7QeX2a0Uo0aKUlfhZ4xuwvCdJw=

modules/apps/transfer/spec/01_concepts.md

@@ -31,7 +31,7 @@ acting as the "source zone". When the token is sent back to the chain it previou
 prefix is removed. This is a backwards movement in the token's timeline and the sender chain is
 acting as the "sink zone".
 
-It is strongly recommended to read the full details of [ADR 001: Coin Source Tracing](./../../../../../docs/architecture/adr-001-coin-source-tracing.md) to understand the implications and context of the IBC token representations.
+It is strongly recommended to read the full details of [ADR 001: Coin Source Tracing](https://github.com/cosmos/ibc-go/blob/main/docs/architecture/adr-001-coin-source-tracing.md) to understand the implications and context of the IBC token representations.
 
 ### UX suggestions for clients
 
@@ -96,7 +96,7 @@ The only viable alternative for clients (at the time of writing) to tokens with
 
 ## Locked Funds
 
-In some [exceptional cases](./../../../../../docs/architecture/adr-026-ibc-client-recovery-mechanisms.md#exceptional-cases), a client state associated with a given channel cannot be updated. This causes that funds from fungible tokens in that channel will be permanently locked and thus can no longer be transferred.
+In some [exceptional cases](https://github.com/cosmos/ibc-go/blob/main/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md#exceptional-cases), a client state associated with a given channel cannot be updated. This causes that funds from fungible tokens in that channel will be permanently locked and thus can no longer be transferred.
 
 To mitigate this, a client update governance proposal can be submitted to update the frozen client
 with a new valid header. Once the proposal passes the client state will be unfrozen and the funds