docs: 10180 Fix SDK (#10237)

* docs: Fix Cosmos-sdk references in md files * Fix SDK to Cosmos SDK in all found places and adjust grammar in turn * Add changelog entry * Update docs/core/context.md Co-authored-by: Barrie Byron <barrie.byron@tendermint.com> * Update docs/architecture/adr-010-modular-antehandler.md Co-authored-by: Barrie Byron <barrie.byron@tendermint.com> * Update docs/basics/README.md Co-authored-by: Barrie Byron <barrie.byron@tendermint.com> * Update docs/architecture/adr-040-storage-and-smt-state-commitments.md Co-authored-by: Barrie Byron <barrie.byron@tendermint.com> * Update docs/building-modules/intro.md Co-authored-by: Barrie Byron <barrie.byron@tendermint.com> * Update docs/building-modules/intro.md Co-authored-by: Barrie Byron <barrie.byron@tendermint.com> * Update docs/core/baseapp.md Co-authored-by: Barrie Byron <barrie.byron@tendermint.com> * Update docs/building-modules/intro.md Co-authored-by: Barrie Byron <barrie.byron@tendermint.com> * Update docs/basics/accounts.md Co-authored-by: Barrie Byron <barrie.byron@tendermint.com> * docs 10180 fix 'an Cosmos SDK' where used Co-authored-by: Barrie Byron <barrie.byron@tendermint.com> Co-authored-by: Amaury <1293565+amaurym@users.noreply.github.com> Co-authored-by: Robert Zaremba <robert@zaremba.ch>
2021-09-28 19:33:58 +02:00
parent f757c90f61
commit a47bd592e9
75 changed files with 264 additions and 264 deletions
@@ -12,7 +12,7 @@ send fungible token transfers to other chains.

 ## Integrating the IBC module

-Integrating the IBC module to your SDK-based application is straighforward. The general changes can be summarized in the following steps:
+Integrating the IBC module to your Cosmos SDK-based application is straighforward. The general changes can be summarized in the following steps:

 - Add required modules to the `module.BasicManager`
 - Define additional `Keeper` fields for the new modules on the `App` type
@@ -244,7 +244,7 @@ func NewApp(...args) *App {
 :::

 That's it! You have now wired up the IBC module and are now able to send fungible tokens across
-different chains. If you want to have a broader view of the changes take a look into the SDK's
+different chains. If you want to have a broader view of the changes take a look into the Cosmos SDK's
 [`SimApp`](https://github.com/cosmos/ibc-go/blob/main/testing/simapp/app.go).

 ## Next {hide}
@@ -16,7 +16,7 @@ of some logic clients may want to be aware of. This is extremely useful when rel
 Any message that uses IBC will emit events for the corresponding TAO logic executed as defined in
 the [IBC events spec](https://github.com/cosmos/ibc-go/blob/main/modules/core/spec/06_events.md).

-In the SDK, it can be assumed that for every message there is an event emitted with the type `message`,
+In the Cosmos SDK, it can be assumed that for every message there is an event emitted with the type `message`,
 attribute key `action`, and an attribute value representing the type of message sent
 (`channel_open_init` would be the attribute value for `MsgChannelOpenInit`). If a relayer queries
 for transaction events, it can split message events using this event Type/Attribute Key pair.
@@ -10,5 +10,5 @@ This directory contains information on how to upgrade an IBC chain without break

 IBC-connnected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform a IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client.

-1. The [quick-guide](./quick-guide.md) describes how IBC-connected chains can perform client-breaking upgrades and how relayers can securely upgrade counterparty clients using the SDK.
+1. The [quick-guide](./quick-guide.md) describes how IBC-connected chains can perform client-breaking upgrades and how relayers can securely upgrade counterparty clients using the Cosmos SDK.
 2. The [developer-guide](./developer-guide.md) is a guide for developers intending to develop IBC client implementations with upgrade functionality.
@@ -6,7 +6,7 @@ order: 1

 Learn how to upgrade your chain and counterparty clients. {synopsis}

-The information in this doc for upgrading chains is relevant to SDK chains. However, the guide for counterparty clients is relevant to any Tendermint client that enables upgrades.
+The information in this doc for upgrading chains is relevant to Cosmos SDK chains. However, the guide for counterparty clients is relevant to any Tendermint client that enables upgrades.

 ### IBC Client Breaking Upgrades

@@ -26,7 +26,7 @@ Note: Since upgrades are only implemented for Tendermint clients, this doc only
 8. Upgrading to a non-backwards compatible version of IBC: **Unsupported**, as IBC version is negotiated on connection handshake.
 9. Changing the Tendermint LightClient algorithm: **Partially Supported**. Changes to the light client algorithm that do not change the ClientState or ConsensusState struct may be supported, provided that the counterparty is also upgraded to support the new light client algorithm. Changes that require updating the ClientState and ConsensusState structs themselves are theoretically possible by providing a path to translate an older ClientState struct into the new ClientState struct; however this is not currently implemented.

-### Step-by-Step Upgrade Process for SDK chains
+### Step-by-Step Upgrade Process for Cosmos 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 list above and then execute the upgrade process described below in order to prevent counterparty clients from breaking.