From f12b4b9789ce976ce41046bee916475a6e3bc32f Mon Sep 17 00:00:00 2001 From: Maximilian Hubert <64627729+gap-editor@users.noreply.github.com> Date: Thu, 27 Mar 2025 20:11:41 +0100 Subject: [PATCH 1/4] Update README.md --- spec/core/ics-005-port-allocation/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/core/ics-005-port-allocation/README.md b/spec/core/ics-005-port-allocation/README.md index bb940eaa0..a4596a9ac 100644 --- a/spec/core/ics-005-port-allocation/README.md +++ b/spec/core/ics-005-port-allocation/README.md @@ -19,7 +19,7 @@ Ports can then be used to open channels and can be transferred or later released ### Motivation -The interblockchain communication protocol is designed to facilitate module-to-module traffic, where modules are independent, possibly mutually distrusted, self-contained +The inter-blockchain communication protocol is designed to facilitate module-to-module traffic, where modules are independent, possibly mutually distrusted, self-contained elements of code executing on sovereign ledgers. In order to provide the desired end-to-end semantics, the IBC handler must permission channels to particular modules. This specification defines the *port allocation and ownership* system which realises that model. From d9488918072fa712febab63d0bfd93a7653bb8fe Mon Sep 17 00:00:00 2001 From: Maximilian Hubert <64627729+gap-editor@users.noreply.github.com> Date: Thu, 27 Mar 2025 20:12:14 +0100 Subject: [PATCH 2/4] Update README.md --- spec/core/ics-004-channel-and-packet-semantics/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/spec/core/ics-004-channel-and-packet-semantics/README.md b/spec/core/ics-004-channel-and-packet-semantics/README.md index 1590d51c4..a7f585dc8 100644 --- a/spec/core/ics-004-channel-and-packet-semantics/README.md +++ b/spec/core/ics-004-channel-and-packet-semantics/README.md @@ -13,19 +13,19 @@ modified: 2019-08-25 ## Synopsis -The "channel" abstraction provides message delivery semantics to the interblockchain communication protocol, in three categories: ordering, exactly-once delivery, and module permissioning. A channel serves as a conduit for packets passing between a module on one chain and a module on another, ensuring that packets are executed only once, delivered in the order in which they were sent (if necessary), and delivered only to the corresponding module owning the other end of the channel on the destination chain. Each channel is associated with a particular connection, and a connection may have any number of associated channels, allowing the use of common identifiers and amortising the cost of header verification across all the channels utilising a connection & light client. +The "channel" abstraction provides message delivery semantics to the inter-blockchain communication protocol, in three categories: ordering, exactly-once delivery, and module permissioning. A channel serves as a conduit for packets passing between a module on one chain and a module on another, ensuring that packets are executed only once, delivered in the order in which they were sent (if necessary), and delivered only to the corresponding module owning the other end of the channel on the destination chain. Each channel is associated with a particular connection, and a connection may have any number of associated channels, allowing the use of common identifiers and amortising the cost of header verification across all the channels utilising a connection & light client. Channels are payload-agnostic. The modules which send and receive IBC packets decide how to construct packet data and how to act upon the incoming packet data, and must utilise their own application logic to determine which state transactions to apply according to what data the packet contains. ### Motivation -The interblockchain communication protocol uses a cross-chain message passing model. IBC *packets* are relayed from one blockchain to the other by external relayer processes. Chain `A` and chain `B` confirm new blocks independently, and packets from one chain to the other may be delayed, censored, or re-ordered arbitrarily. Packets are visible to relayers and can be read from a blockchain by any relayer process and submitted to any other blockchain. +The inter-blockchain communication protocol uses a cross-chain message passing model. IBC *packets* are relayed from one blockchain to the other by external relayer processes. Chain `A` and chain `B` confirm new blocks independently, and packets from one chain to the other may be delayed, censored, or re-ordered arbitrarily. Packets are visible to relayers and can be read from a blockchain by any relayer process and submitted to any other blockchain. The IBC protocol must provide ordering (for ordered channels) and exactly-once delivery guarantees to allow applications to reason about the combined state of connected modules on two chains. > **Example**: An application may wish to allow a single tokenized asset to be transferred between and held on multiple blockchains while preserving fungibility and conservation of supply. The application can mint asset vouchers on chain `B` when a particular IBC packet is committed to chain `B`, and require outgoing sends of that packet on chain `A` to escrow an equal amount of the asset on chain `A` until the vouchers are later redeemed back to chain `A` with an IBC packet in the reverse direction. This ordering guarantee along with correct application logic can ensure that total supply is preserved across both chains and that any vouchers minted on chain `B` can later be redeemed back to chain `A`. -In order to provide the desired ordering, exactly-once delivery, and module permissioning semantics to the application layer, the interblockchain communication protocol must implement an abstraction to enforce these semantics — channels are this abstraction. +In order to provide the desired ordering, exactly-once delivery, and module permissioning semantics to the application layer, the inter-blockchain communication protocol must implement an abstraction to enforce these semantics — channels are this abstraction. ### Definitions From 7176fcf5f06ba9f2dfc5f6795d546133a577e9d0 Mon Sep 17 00:00:00 2001 From: Maximilian Hubert <64627729+gap-editor@users.noreply.github.com> Date: Thu, 27 Mar 2025 20:12:57 +0100 Subject: [PATCH 3/4] Update README.md --- spec/core/ics-026-routing-module/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/core/ics-026-routing-module/README.md b/spec/core/ics-026-routing-module/README.md index 0c19c54f5..687d3dba1 100644 --- a/spec/core/ics-026-routing-module/README.md +++ b/spec/core/ics-026-routing-module/README.md @@ -12,7 +12,7 @@ modified: 2019-08-25 ## Synopsis -The routing module is a default implementation of a secondary module which will accept external datagrams and call into the interblockchain communication protocol handler to deal with handshakes and packet relay. +The routing module is a default implementation of a secondary module which will accept external datagrams and call into the inter-blockchain communication protocol handler to deal with handshakes and packet relay. The routing module keeps a lookup table of modules, which it can use to look up and call a module when a packet is received, so that external relayers need only ever relay packets to the routing module. ### Motivation From c4f97bf551ce5856215a1019c5311ae2acd544f2 Mon Sep 17 00:00:00 2001 From: Maximilian Hubert <64627729+gap-editor@users.noreply.github.com> Date: Thu, 27 Mar 2025 20:13:14 +0100 Subject: [PATCH 4/4] Update README.md --- spec/core/ics-024-host-requirements/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/core/ics-024-host-requirements/README.md b/spec/core/ics-024-host-requirements/README.md index a5daa2bb8..0e59ecaad 100644 --- a/spec/core/ics-024-host-requirements/README.md +++ b/spec/core/ics-024-host-requirements/README.md @@ -14,7 +14,7 @@ modified: 2022-09-14 ## Synopsis -This specification defines the minimal set of interfaces which must be provided and properties which must be fulfilled by a state machine hosting an implementation of the interblockchain communication protocol. +This specification defines the minimal set of interfaces which must be provided and properties which must be fulfilled by a state machine hosting an implementation of the inter-blockchain communication protocol. ### Motivation