From 30550c2b4366c0511bce4d35e04816d1f7166fb1 Mon Sep 17 00:00:00 2001 From: Christina <156356273+cratiu222@users.noreply.github.com> Date: Wed, 3 Jul 2024 11:23:46 +0300 Subject: [PATCH] Docs improvements (#6746) * fix adr-009-v6-ics27-msgserver.md * fix adr-015-ibc-packet-receiver.md * fix adr-026-ibc-client-recovery-mechanisms.md * fix adr-027-ibc-wasm.md * fix adr.template.md --- docs/architecture/adr-009-v6-ics27-msgserver.md | 4 ++-- docs/architecture/adr-015-ibc-packet-receiver.md | 2 +- docs/architecture/adr-026-ibc-client-recovery-mechanisms.md | 2 +- docs/architecture/adr-027-ibc-wasm.md | 2 +- docs/architecture/adr.template.md | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/architecture/adr-009-v6-ics27-msgserver.md b/docs/architecture/adr-009-v6-ics27-msgserver.md index 08d7cb53036..61d229e5d78 100644 --- a/docs/architecture/adr-009-v6-ics27-msgserver.md +++ b/docs/architecture/adr-009-v6-ics27-msgserver.md @@ -12,13 +12,13 @@ Accepted, implemented in v6 of ibc-go ICS 27 (Interchain Accounts) brought a cross-chain account management protocol built upon IBC. 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. +The initial release of ICS 27 focused on enabling authentication schemes that 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: - a default authentication module would enable more usage of ICS 27 - generic authentication modules should be capable of authenticating an interchain account registration -- application logic which wraps ICS 27 packet sends do not need to be associated with the authentication logic +- application logic which wraps ICS 27 packet sends does not need to be associated with the authentication logic ## Decision diff --git a/docs/architecture/adr-015-ibc-packet-receiver.md b/docs/architecture/adr-015-ibc-packet-receiver.md index ad220f35d4d..591694ba3b8 100644 --- a/docs/architecture/adr-015-ibc-packet-receiver.md +++ b/docs/architecture/adr-015-ibc-packet-receiver.md @@ -10,7 +10,7 @@ In ICS 26, the routing module is defined as a layer above each application module which verifies and routes messages to the destination modules. It is possible to -implement it as a separate module, however, we already have functionality to route +implement it as a separate module, however, we already have the functionality to route messages upon the destination identifiers in the baseapp. This ADR suggests to utilize existing `baseapp.router` to route packets to application modules. diff --git a/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md b/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md index a1152b4e1cb..2c295ad9ae7 100644 --- a/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md +++ b/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md @@ -18,7 +18,7 @@ ### Summary -At launch, IBC will be a novel protocol, without an experienced user-base. At the protocol layer, it is not possible to distinguish between client expiry or misbehaviour due to genuine faults (Byzantine behavior) and client expiry or misbehaviour due to user mistakes (failing to update a client, or accidentally double-signing). In the base IBC protocol and ICS 20 fungible token transfer implementation, if a client can no longer be updated, funds in that channel will be permanently locked and can no longer be transferred. To the degree that it is safe to do so, it would be preferable to provide users with a recovery mechanism which can be utilised in these exceptional cases. +At launch, IBC will be a novel protocol, without an experienced user-base. At the protocol layer, it is not possible to distinguish between client expiry or misbehaviour due to genuine faults (Byzantine behaviour) and client expiry or misbehaviour due to user mistakes (failing to update a client, or accidentally double-signing). In the base IBC protocol and ICS 20 fungible token transfer implementation, if a client can no longer be updated, funds in that channel will be permanently locked and can no longer be transferred. To the degree that it is safe to do so, it would be preferable to provide users with a recovery mechanism which can be utilised in these exceptional cases. ### Exceptional cases diff --git a/docs/architecture/adr-027-ibc-wasm.md b/docs/architecture/adr-027-ibc-wasm.md index 1a2a1e8a8a9..c8fa15fdd32 100644 --- a/docs/architecture/adr-027-ibc-wasm.md +++ b/docs/architecture/adr-027-ibc-wasm.md @@ -29,7 +29,7 @@ client is part of its codebase), re-build chains' binaries, pass a governance pr Another problem stemming from the above process is that if a chain wants to upgrade its own consensus, it will need to convince every chain or hub connected to it to upgrade its light client in order to stay connected. Due -to the time consuming process required to upgrade a light client, a chain with lots of connections needs to be +to the time-consuming process required to upgrade a light client, a chain with lots of connections needs to be disconnected for quite some time after upgrading its consensus, which can be very expensive in terms of time and effort. We are proposing simplifying this workflow by integrating a Wasm light client module that makes adding support for diff --git a/docs/architecture/adr.template.md b/docs/architecture/adr.template.md index cd11ecd1b82..d5ec7fc125e 100644 --- a/docs/architecture/adr.template.md +++ b/docs/architecture/adr.template.md @@ -12,7 +12,7 @@ ## Context -> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. +> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high-level idea behind the solution. ## Decision