diff --git a/docs/architecture/README.md b/docs/architecture/README.md index cae7778356f..6f433052c79 100644 --- a/docs/architecture/README.md +++ b/docs/architecture/README.md @@ -44,5 +44,5 @@ To suggest an ADR, please make use of the [ADR template](@site/architecture/adr. | [011](./adr-011-transfer-total-escrow-state-entry.md) | ICS20 state entry for total amount of tokens in escrow | Accepted | | [015](./adr-015-ibc-packet-receiver.md) | IBC Packet Routing | Accepted | | [025](./adr-025-ibc-passive-channels.md) | IBC passive channels | Deprecated | -| [026](./adr-026-ibc-client-recovery-mechanisms.md) | IBC client recovery mechansisms | Accepted | +| [026](./adr-026-ibc-client-recovery-mechanisms.md) | IBC client recovery mechanisms | Accepted | | [027](./adr-027-ibc-wasm.md) | Wasm based light clients | Accepted | diff --git a/docs/architecture/adr-001-coin-source-tracing.md b/docs/architecture/adr-001-coin-source-tracing.md index a2e295e2c50..17b905adca7 100644 --- a/docs/architecture/adr-001-coin-source-tracing.md +++ b/docs/architecture/adr-001-coin-source-tracing.md @@ -14,7 +14,7 @@ Accepted, Implemented The specification for IBC cross-chain fungible token transfers ([ICS20](https://github.com/cosmos/ibc/tree/master/spec/app/ics-020-fungible-token-transfer)), needs to be aware of the origin of any token denomination in order to relay a `Packet` which contains the sender -and recipient addressed in the +and recipient addresses in the [`FungibleTokenPacketData`](https://github.com/cosmos/ibc/tree/master/spec/app/ics-020-fungible-token-transfer#data-structures). The Packet relay sending works based in 2 cases (per diff --git a/docs/architecture/adr-002-go-module-versioning.md b/docs/architecture/adr-002-go-module-versioning.md index c33bc8d5a5c..20959896bb7 100644 --- a/docs/architecture/adr-002-go-module-versioning.md +++ b/docs/architecture/adr-002-go-module-versioning.md @@ -10,7 +10,7 @@ Accepted ## Context -The IBC module was originally developed in the Cosmos SDK and released during with the Stargate release series (v0.42). +The IBC module was originally developed in the Cosmos SDK and released during the Stargate release series (v0.42). It was subsequently migrated to its own repository, ibc-go. The first official release on ibc-go was v1.0.0. v1.0.0 was decided to be used instead of v0.1.0 primarily for the following reasons: @@ -74,7 +74,7 @@ This prevents the Go module version from being incremented with breaking changes It also requires all extended functions to live in the same Go module, disrupting the existing code structure. The version that implements this change will still be incompatible with previous versions, but future versions could be imported together without namespace collisions. -For example, lets say this solution is implemented in v3. Then +For example, let's say this solution is implemented in v3. Then `github.com/cosmos/ibc-go/v2` cannot be imported with any other ibc-go version diff --git a/docs/architecture/adr-025-ibc-passive-channels.md b/docs/architecture/adr-025-ibc-passive-channels.md index ce3f1e96db8..33cac135928 100644 --- a/docs/architecture/adr-025-ibc-passive-channels.md +++ b/docs/architecture/adr-025-ibc-passive-channels.md @@ -45,7 +45,7 @@ ctx.EventManager().EmitEvents(sdk.Events{ sdk.NewAttribute(types.AttributeKeyHops, strings.Join(connectionHops, ",")), sdk.NewAttribute(types.AttributeKeyOrder, order.String()), sdk.NewAttribute(types.AttributeKeySrcPort, portID), - sdk.NewAttribute(types.AttributeKeySrcChannel, chanenlID), + sdk.NewAttribute(types.AttributeKeySrcChannel, channelID), sdk.NewAttribute(types.AttributeKeySrcVersion, version), sdk.NewAttribute(types.AttributeKeyDstPort, counterparty.GetPortID()), sdk.NewAttribute(types.AttributeKeyDstChannel, counterparty.GetChannelID()), diff --git a/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md b/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md index a77fc97f8ae..a1152b4e1cb 100644 --- a/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md +++ b/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md @@ -48,7 +48,7 @@ We elect not to deal with chains which have actually halted, which is necessaril 1. Add a new governance proposal with `MsgRecoverClient`. 1. Create a new Msg with two client identifiers (`string`) and a signer. 1. The first client identifier is the proposed client to be updated. This client must be either frozen or expired. - 1. The second client is a substitute client. It carries all the state for the client which may be updated. It must have identitical client and chain parameters to the client which may be updated (except for latest height, frozen height, and chain-id). It should be continually updated during the voting period. + 1. The second client is a substitute client. It carries all the state for the client which may be updated. It must have identical client and chain parameters to the client which may be updated (except for latest height, frozen height, and chain-id). It should be continually updated during the voting period. 1. If this governance proposal passes, the client on trial will be updated to the latest state of the substitute. 1. The signer must be the authority set for the ibc module. diff --git a/docs/architecture/adr-027-ibc-wasm.md b/docs/architecture/adr-027-ibc-wasm.md index 26ba89a1d77..2abe7d6d82d 100644 --- a/docs/architecture/adr-027-ibc-wasm.md +++ b/docs/architecture/adr-027-ibc-wasm.md @@ -11,7 +11,7 @@ ## Abstract -In the Cosmos SDK light clients are current hardcoded in Go. This makes upgrading existing IBC light clients or +In the Cosmos SDK light clients are currently hardcoded in Go. This makes upgrading existing IBC light clients or adding support for new light client a multi step process involving on-chain governance which is time-consuming. To remedy this, we are proposing a Wasm VM to host light client bytecode, which allows easier upgrading of diff --git a/docs/dev/project-structure.md b/docs/dev/project-structure.md index da6410634de..0f04dd2ebd9 100644 --- a/docs/dev/project-structure.md +++ b/docs/dev/project-structure.md @@ -25,8 +25,8 @@ This folder contains implementations for the IBC TAO (`core`), IBC applications ### `light-clients` -- `06-solomachine`: This package implement the types for the Solo Machine light client specified in [ICS 06](https://github.com/cosmos/ibc/tree/main/spec/client/ics-006-solo-machine-client). -- `07-tendermint`: This package implement the types for the Tendermint consensus light client as specified in [ICS 07](https://github.com/cosmos/ibc/tree/main/spec/client/ics-007-tendermint-client). +- `06-solomachine`: This package implements the types for the Solo Machine light client specified in [ICS 06](https://github.com/cosmos/ibc/tree/main/spec/client/ics-006-solo-machine-client). +- `07-tendermint`: This package implements the types for the Tendermint consensus light client as specified in [ICS 07](https://github.com/cosmos/ibc/tree/main/spec/client/ics-007-tendermint-client). ## `proto` diff --git a/docs/dev/release-management.md b/docs/dev/release-management.md index fb188df867e..3b3ebc36953 100644 --- a/docs/dev/release-management.md +++ b/docs/dev/release-management.md @@ -31,7 +31,7 @@ In order to alleviate the burden for a single person to have to cherry-pick and Current release is `v1.0.2`. We then maintain a (living) branch `release/v1.0.x`, given `x` as the next patch release number (currently `v1.0.3`) for the `v1.0` release series. As bugs are fixed and PRs are merged into `main`, if a contributor wishes the PR to be released into the `v1.0.x` point release, the contributor must: -1. Add the `backport-to-v1.0x` label to the PR. +1. Add the `backport-to-v1.0.x` label to the PR. 2. Once the PR is merged, the Mergify GitHub application will automatically copy the changes into another branch and open a new PR against the desired `release/v1.0.x` branch. 3. If the following has not been discussed in the original PR, then update the backport PR's description and ensure it contains the following information: diff --git a/docs/requirements/channel-upgradability-requirements.md b/docs/requirements/channel-upgradability-requirements.md index e56d02e351b..78cf9e6bdb3 100644 --- a/docs/requirements/channel-upgradability-requirements.md +++ b/docs/requirements/channel-upgradability-requirements.md @@ -70,7 +70,7 @@ A normal flow for upgrades: 1. Governance proposal with `MsgChannelUpgradeInit` proposing to upgrade channel version to `{"fee_version":"ics29-1","app_version":"ics20-1"}` is submitted on chain A. 2. Governance proposal passes and `MsgChannelUpgradeInit` executes successfully on chain A. -3. Governance of chain B updates the list of allowed connections for channel upgrades, so that `channel-0` is allowed to be upgraded permissionlesly. +3. Governance of chain B updates the list of allowed connections for channel upgrades, so that `channel-0` is allowed to be upgraded permissionlessly. 4. Relayer submits `MsgChannelUpgradeTry` on chain B proposing to upgrade channel version to `{"fee_version":"ics29-1","app_version":"ics20-1"}`. 5. Execution of `MsgChannelUpgradeTry` succeeds on chain B. Chain B specifies a timeout for chain A before which all packets on its side should be flushed. 6. Relayer starts flushing in-flight packets from chain B to chain A. @@ -113,7 +113,7 @@ The crossing hello flow for upgrades happens when a governance proposal on both Sample exception flows: -- If two different relayers detect execution of `MsgChannelUpgradeInit` on both chain A and chain B and they submit `MsgChannelUpgradeTry` on the counterparty, then the handshake will finish `MsgChannelUpgradeOpen` after both chains execute `MsgChannelUpgradeAck` and all in-flight packets has been flushed (i.e. it is not needed to execute `MsgChannelUpgradeConfirm`). +- If two different relayers detect execution of `MsgChannelUpgradeInit` on both chain A and chain B and they submit `MsgChannelUpgradeTry` on the counterparty, then the handshake will finish `MsgChannelUpgradeOpen` after both chains execute `MsgChannelUpgradeAck` and all in-flight packets have been flushed (i.e. it is not needed to execute `MsgChannelUpgradeConfirm`). # Functional requirements diff --git a/e2e/README.md b/e2e/README.md index b39f4728309..a0a7f3451a9 100644 --- a/e2e/README.md +++ b/e2e/README.md @@ -51,8 +51,8 @@ options specified in your config file. | Environment Variable | Description | Default Value | |----------------------|-------------------------------------------|---------------| | CHAIN_IMAGE | The image that will be used for the chain | ibc-go-simd | -| CHAIN_A_TAG | The tag used for chain B | latest | -| CHAIN_B_TAG | The tag used for chain A | latest | +| CHAIN_A_TAG | The tag used for chain A | latest | +| CHAIN_B_TAG | The tag used for chain B | latest | | CHAIN_BINARY | The binary used in the container | simd | | RELAYER_TAG | The tag used for the relayer | main | | RELAYER_ID | The type of relayer to use (rly/hermes) | hermes |