From ab8a23d0b6c1be595e4bc7c3889b76f9d9aa4745 Mon Sep 17 00:00:00 2001 From: axie <152680487+azukiboy@users.noreply.github.com> Date: Fri, 8 Dec 2023 18:38:21 +0800 Subject: [PATCH] docs: fix typos (#5344) --- docs/architecture/adr-003-ics27-acknowledgement.md | 12 ++++++------ docs/architecture/adr-009-v6-ics27-msgserver.md | 2 +- docs/dev/development-setup.md | 2 +- .../02-interchain-accounts/09-active-channels.md | 2 +- .../02-interchain-accounts/03-active-channels.md | 2 +- .../02-interchain-accounts/03-active-channels.md | 2 +- .../02-interchain-accounts/08-active-channels.md | 2 +- .../02-interchain-accounts/09-active-channels.md | 2 +- .../02-interchain-accounts/09-active-channels.md | 2 +- modules/core/04-channel/types/acknowledgement.go | 2 +- 10 files changed, 15 insertions(+), 15 deletions(-) diff --git a/docs/architecture/adr-003-ics27-acknowledgement.md b/docs/architecture/adr-003-ics27-acknowledgement.md index 560f3b58116..38da73cac21 100644 --- a/docs/architecture/adr-003-ics27-acknowledgement.md +++ b/docs/architecture/adr-003-ics27-acknowledgement.md @@ -15,7 +15,7 @@ This acknowledgement will be hashed and written into state. Thus any changes to ICS27 executes transactions on behalf of a controller chain. Information such as the message result or message error may be returned from other SDK modules outside the control of the ICS27 module. It might be very valuable to return message execution information inside the ICS27 acknowledgement so that controller chain interchain account auth modules can act upon this information. -Only determinstic information returned from the message execution is allowed to be returned in the packet acknowledgement otherwise the network will halt due to a fork in the expected app hash. +Only deterministic information returned from the message execution is allowed to be returned in the packet acknowledgement otherwise the network will halt due to a fork in the expected app hash. ## Decision @@ -37,7 +37,7 @@ func deterministicResponseDeliverTx(response *abci.ResponseDeliverTx) *abci.Resp ### Successful acknowledgements Successful acknowledgements should return information about the transaction execution. -Given the determinstic fields in the `abci.ResponseDeliverTx`, the transaction `Data` can be used to indicate information about the transaction execution. +Given the deterministic fields in the `abci.ResponseDeliverTx`, the transaction `Data` can be used to indicate information about the transaction execution. The `abci.ResponseDeliverTx.Data` will be set in the ICS27 packet acknowledgement upon successful transaction execution. The format for the `abci.ResponseDeliverTx.Data` is constructed by the SDK. @@ -81,7 +81,7 @@ If the bytes could be unmarshaled, then they could be packed into an `*codectype Intercepting the MsgResponse before it becomes marshaled requires replicating this [code](https://github.com/cosmos/cosmos-sdk/blob/dfd47f5b449f558a855da284a9a7eabbfbad435d/baseapp/msg_service_router.go#L109-#L128). It may not even be possible to replicate the linked code. The method handler would need to be accessed somehow. -For these reasons it is deemed infeasible to attempt a fowards compatible approach. +For these reasons it is deemed infeasible to attempt a forwards compatible approach. ICA auth developers can interpret which format was used when constructing the transaction response by checking if the `sdk.TxMsgData.Data` field is non-empty. If the `sdk.TxMsgData.Data` field is not empty then the format for v0.45 was used, otherwise ICA auth developers can assume the transaction response uses the newer format. @@ -96,10 +96,10 @@ A test has been [written](https://github.com/cosmos/ibc-go/blob/v3.0.0/modules/a ### Error acknowledgements -As indicated above, the `abci.ResponseDeliverTx.Code` is determinstic. +As indicated above, the `abci.ResponseDeliverTx.Code` is deterministic. Upon transaction execution errors, an error acknowledgement should be returned including the abci code. -A test has been [written](https://github.com/cosmos/ibc-go/blob/v3.0.0/modules/apps/27-interchain-accounts/host/types/ack_test.go#L41-#L82) to fail if the ABCI code is no longer determinstic. +A test has been [written](https://github.com/cosmos/ibc-go/blob/v3.0.0/modules/apps/27-interchain-accounts/host/types/ack_test.go#L41-#L82) to fail if the ABCI code is no longer deterministic. ## Consequences @@ -113,7 +113,7 @@ A test has been [written](https://github.com/cosmos/ibc-go/blob/v3.0.0/modules/a ### Negative - the security assumptions of this decision rest on the inclusion of the ABCI error code and the Msg response in the ResponseDeliverTx hash created by Tendermint -- events are non-determinstic and cannot be included in the packet acknowledgement +- events are non-deterministic and cannot be included in the packet acknowledgement ### Neutral diff --git a/docs/architecture/adr-009-v6-ics27-msgserver.md b/docs/architecture/adr-009-v6-ics27-msgserver.md index cfcbfade7d2..08d7cb53036 100644 --- a/docs/architecture/adr-009-v6-ics27-msgserver.md +++ b/docs/architecture/adr-009-v6-ics27-msgserver.md @@ -11,7 +11,7 @@ Accepted, implemented in v6 of ibc-go ## Context ICS 27 (Interchain Accounts) brought a cross-chain account management protocol built upon IBC. -It enabled chains to programatically create accounts on behalf of counterparty chains which may enable a variety of authentication methods for this interchain account. +It enabled chains to programmatically create accounts on behalf of counterparty chains which may enable a variety of authentication methods for this interchain account. The initial release of ICS 27 focused on enabling authentication schemes which may not require signing with a private key, such as via on-chain mechanisms like governance. Following the initial release of ICS 27 it became evident that: diff --git a/docs/dev/development-setup.md b/docs/dev/development-setup.md index eafeb705120..b36ef5e3467 100644 --- a/docs/dev/development-setup.md +++ b/docs/dev/development-setup.md @@ -18,7 +18,7 @@ Other helpful commands: We use [Protocol Buffers](https://developers.google.com/protocol-buffers) along with [buf](https://docs.buf.build/introduction) and [gogoproto](https://github.com/gogo/protobuf) to generate code for use in ibc-go. -For determinstic behavior around protobuf tooling, everything is containerized using Docker. Make sure to have Docker installed on your machine, or head to [Docker's website](https://docs.docker.com/get-docker/) to install it. +For deterministic behavior around protobuf tooling, everything is containerized using Docker. Make sure to have Docker installed on your machine, or head to [Docker's website](https://docs.docker.com/get-docker/) to install it. For formatting code in `.proto` files, you can run the `make proto-format` command. diff --git a/docs/docs/02-apps/02-interchain-accounts/09-active-channels.md b/docs/docs/02-apps/02-interchain-accounts/09-active-channels.md index 2aedeb8a42f..3cb521b4bf3 100644 --- a/docs/docs/02-apps/02-interchain-accounts/09-active-channels.md +++ b/docs/docs/02-apps/02-interchain-accounts/09-active-channels.md @@ -13,7 +13,7 @@ In the case of a channel closing, a controller chain needs to be able to regain When an Interchain Account is registered using `MsgRegisterInterchainAccount`, a new channel is created on a particular port. During the `OnChanOpenAck` and `OnChanOpenConfirm` steps (on controller & host chain respectively) the `Active Channel` for this interchain account is stored in state. -It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programatically by sending a new `MsgChannelOpenInit` message like so: +It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programmatically by sending a new `MsgChannelOpenInit` message like so: ```go msg := channeltypes.NewMsgChannelOpenInit(portID, string(versionBytes), channeltypes.ORDERED, []string{connectionID}, icatypes.HostPortID, authtypes.NewModuleAddress(icatypes.ModuleName).String()) diff --git a/docs/versioned_docs/version-v4.5.x/02-apps/02-interchain-accounts/03-active-channels.md b/docs/versioned_docs/version-v4.5.x/02-apps/02-interchain-accounts/03-active-channels.md index 6727055cb18..449f02b1a40 100644 --- a/docs/versioned_docs/version-v4.5.x/02-apps/02-interchain-accounts/03-active-channels.md +++ b/docs/versioned_docs/version-v4.5.x/02-apps/02-interchain-accounts/03-active-channels.md @@ -16,7 +16,7 @@ channel type that provides ordering of packets without the channel closing on ti When an Interchain Account is registered using the `RegisterInterchainAccount` API, a new channel is created on a particular port. During the `OnChanOpenAck` and `OnChanOpenConfirm` steps (controller & host chain) the `Active Channel` for this interchain account is stored in state. -It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programatically by sending a new `MsgChannelOpenInit` message like so: +It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programmatically by sending a new `MsgChannelOpenInit` message like so: ```go msg := channeltypes.NewMsgChannelOpenInit(portID, string(versionBytes), channeltypes.ORDERED, []string{connectionID}, icatypes.PortID, icatypes.ModuleName) diff --git a/docs/versioned_docs/version-v5.3.x/02-apps/02-interchain-accounts/03-active-channels.md b/docs/versioned_docs/version-v5.3.x/02-apps/02-interchain-accounts/03-active-channels.md index 6727055cb18..449f02b1a40 100644 --- a/docs/versioned_docs/version-v5.3.x/02-apps/02-interchain-accounts/03-active-channels.md +++ b/docs/versioned_docs/version-v5.3.x/02-apps/02-interchain-accounts/03-active-channels.md @@ -16,7 +16,7 @@ channel type that provides ordering of packets without the channel closing on ti When an Interchain Account is registered using the `RegisterInterchainAccount` API, a new channel is created on a particular port. During the `OnChanOpenAck` and `OnChanOpenConfirm` steps (controller & host chain) the `Active Channel` for this interchain account is stored in state. -It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programatically by sending a new `MsgChannelOpenInit` message like so: +It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programmatically by sending a new `MsgChannelOpenInit` message like so: ```go msg := channeltypes.NewMsgChannelOpenInit(portID, string(versionBytes), channeltypes.ORDERED, []string{connectionID}, icatypes.PortID, icatypes.ModuleName) diff --git a/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/08-active-channels.md b/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/08-active-channels.md index c4750792719..5f727c17e36 100644 --- a/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/08-active-channels.md +++ b/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/08-active-channels.md @@ -14,7 +14,7 @@ In the case of a channel closing, a controller chain needs to be able to regain When an Interchain Account is registered using `MsgRegisterInterchainAccount`, a new channel is created on a particular port. During the `OnChanOpenAck` and `OnChanOpenConfirm` steps (on controller & host chain respectively) the `Active Channel` for this interchain account is stored in state. -It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programatically by sending a new `MsgChannelOpenInit` message like so: +It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programmatically by sending a new `MsgChannelOpenInit` message like so: ```go msg := channeltypes.NewMsgChannelOpenInit(portID, string(versionBytes), channeltypes.ORDERED, []string{connectionID}, icatypes.HostPortID, authtypes.NewModuleAddress(icatypes.ModuleName).String()) diff --git a/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/09-active-channels.md b/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/09-active-channels.md index 2aedeb8a42f..3cb521b4bf3 100644 --- a/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/09-active-channels.md +++ b/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/09-active-channels.md @@ -13,7 +13,7 @@ In the case of a channel closing, a controller chain needs to be able to regain When an Interchain Account is registered using `MsgRegisterInterchainAccount`, a new channel is created on a particular port. During the `OnChanOpenAck` and `OnChanOpenConfirm` steps (on controller & host chain respectively) the `Active Channel` for this interchain account is stored in state. -It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programatically by sending a new `MsgChannelOpenInit` message like so: +It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programmatically by sending a new `MsgChannelOpenInit` message like so: ```go msg := channeltypes.NewMsgChannelOpenInit(portID, string(versionBytes), channeltypes.ORDERED, []string{connectionID}, icatypes.HostPortID, authtypes.NewModuleAddress(icatypes.ModuleName).String()) diff --git a/docs/versioned_docs/version-v8.0.x/02-apps/02-interchain-accounts/09-active-channels.md b/docs/versioned_docs/version-v8.0.x/02-apps/02-interchain-accounts/09-active-channels.md index 2aedeb8a42f..3cb521b4bf3 100644 --- a/docs/versioned_docs/version-v8.0.x/02-apps/02-interchain-accounts/09-active-channels.md +++ b/docs/versioned_docs/version-v8.0.x/02-apps/02-interchain-accounts/09-active-channels.md @@ -13,7 +13,7 @@ In the case of a channel closing, a controller chain needs to be able to regain When an Interchain Account is registered using `MsgRegisterInterchainAccount`, a new channel is created on a particular port. During the `OnChanOpenAck` and `OnChanOpenConfirm` steps (on controller & host chain respectively) the `Active Channel` for this interchain account is stored in state. -It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programatically by sending a new `MsgChannelOpenInit` message like so: +It is possible to create a new channel using the same controller chain portID if the previously set `Active Channel` is now in a `CLOSED` state. This channel creation can be initialized programmatically by sending a new `MsgChannelOpenInit` message like so: ```go msg := channeltypes.NewMsgChannelOpenInit(portID, string(versionBytes), channeltypes.ORDERED, []string{connectionID}, icatypes.HostPortID, authtypes.NewModuleAddress(icatypes.ModuleName).String()) diff --git a/modules/core/04-channel/types/acknowledgement.go b/modules/core/04-channel/types/acknowledgement.go index 27617d391f5..9b802d0e2c7 100644 --- a/modules/core/04-channel/types/acknowledgement.go +++ b/modules/core/04-channel/types/acknowledgement.go @@ -33,7 +33,7 @@ func NewResultAcknowledgement(result []byte) Acknowledgement { func NewErrorAcknowledgement(err error) Acknowledgement { // the ABCI code is included in the abcitypes.ResponseDeliverTx hash // constructed in Tendermint and is therefore deterministic - _, code, _ := errorsmod.ABCIInfo(err, false) // discard non-determinstic codespace and log values + _, code, _ := errorsmod.ABCIInfo(err, false) // discard non-deterministic codespace and log values return Acknowledgement{ Response: &Acknowledgement_Error{