Rename ICS 26 (closes cosmos#274)

README.md

@@ -58,7 +58,7 @@ All standards at or past the "Draft" stage are listed here in order of their ICS
 | [23](spec/ics-023-vector-commitments)          | Vector Commitments         | Draft |
 | [24](spec/ics-024-host-requirements)           | Host Requirements          | Draft |
 | [25](spec/ics-025-handler-interface)           | Handler Interface          | Draft |
-| [26](spec/ics-026-relayer-module)              | Relayer Module             | Draft |
+| [26](spec/ics-026-routing-module)              | Routing Module             | Draft |
 
 ### IBC/APP
 

ibc/1_IBC_TERMINOLOGY.md

@@ -54,13 +54,13 @@ A *commitment proof* is the proof structure which proves whether a particular ke
 
 The IBC *handler module* is the module within the state machine which implements [ICS 25](../spec/ics-025-handler-module), managing clients, connections, & channels, verifying proofs, and storing appropriate commitments for packets.
 
-### Relayer Module
+### Routing Module
 
-The IBC *relayer module* is the module within the state machine which implements [ICS 26](../spec/ics-026-relayer-module), routing packets between the handler module and other modules on the host state machine which utilise the relayer module's external interface.
+The IBC *routing module* is the module within the state machine which implements [ICS 26](../spec/ics-026-routing-module), routing packets between the handler module and other modules on the host state machine which utilise the routing module's external interface.
 
 ### Datagram
 
-A *datagram* is an opaque bytestring transmitted over some physical network, and handled by the IBC relayer module implemented in the ledger's state machine. In some implementations, the datagram may be a field in a ledger-specific transaction or message data structure which also contains other information (e.g. a fee for spam prevention, nonce for replay prevention, type identifier to route to the IBC handler, etc.). All IBC sub-protocols (such as opening a connection, creating a channel, sending a packet) are defined in terms of sets of datagrams and protocols for handling them through the relayer module.
+A *datagram* is an opaque bytestring transmitted over some physical network, and handled by the IBC routing module implemented in the ledger's state machine. In some implementations, the datagram may be a field in a ledger-specific transaction or message data structure which also contains other information (e.g. a fee for spam prevention, nonce for replay prevention, type identifier to route to the IBC handler, etc.). All IBC sub-protocols (such as opening a connection, creating a channel, sending a packet) are defined in terms of sets of datagrams and protocols for handling them through the routing module.
 
 ### Connection
 

ibc/5_IBC_DESIGN_PATTERNS.md

@@ -61,18 +61,18 @@ It also has one notable disadvantage:
   relayer processes will need to track the state of multiple modules to determine when packets
   can be submitted.
 
-For this reason, there is an additional IBC "relayer module" which exposes a call dispatch interface.
+For this reason, there is an additional IBC "routing module" which exposes a call dispatch interface.
 
 ## Call dispatch
 
-For common relay patterns, an "IBC relayer module" can be implemented which maintains a module dispatch table and simplifies the job of relayers.
+For common relay patterns, an "IBC routing module" can be implemented which maintains a module dispatch table and simplifies the job of relayers.
 
 In the call dispatch pattern, datagrams (contained within transaction types defined by the host state machine) are relayed directly
-to the relayer module, which then looks up the appropriate module (owning the channel & port to which the datagram was addressed)
-and calls an appropriate function (which must have been previously registered with the relayer module). This allows modules to 
+to the routing module, which then looks up the appropriate module (owning the channel & port to which the datagram was addressed)
+and calls an appropriate function (which must have been previously registered with the routing module). This allows modules to 
 avoid handling datagrams directly, and makes it harder to accidentally screw-up the atomic state transition execution which must
 happen in conjunction with sending or receiving a packet (since the module never handles packets directly, but rather exposes
-functions which are called by the relayer module upon receipt of a valid packet).
+functions which are called by the routing module upon receipt of a valid packet).
 
-Additionally, the relayer module can implement default logic for handshake datagram handling (accepting incoming handshakes
+Additionally, the routing module can implement default logic for handshake datagram handling (accepting incoming handshakes
 on behalf of modules), which is convenient for modules which do not need to implement their own custom logic.

misc/aspell_dict

@@ -127,7 +127,6 @@ runtime
 connOpenConfirm
 mempools
 whitelist
-relayerModule
 Ojha
 updateConsensusState
 consensusStateKey
@@ -258,6 +257,7 @@ Sig
 portKey
 computable
 TCP
+routingModule
 counterpartyVersion
 portPath
 createClient

spec.pdc

@@ -85,9 +85,9 @@ header-includes:
 
 !include spec/ics-025-handler-interface/README.md.xfm
 
-# ICS 026 - Relayer Module
+# ICS 026 - Routing Module
 
-!include spec/ics-026-relayer-module/README.md.xfm
+!include spec/ics-026-routing-module/README.md.xfm
 
 # ICS 018 - Relayer Algorithms
 

spec/ics-004-channel-and-packet-semantics/README.md

@@ -451,7 +451,7 @@ function chanCloseConfirm(
 
 The following sequence of steps must occur for a packet to be sent from module *1* on machine *A* to module *2* on machine *B*, starting from scratch.
 
-The module can interface with the IBC handler through [ICS 25](../ics-025-handler-interface) or [ICS 26](../ics-026-relayer-module).
+The module can interface with the IBC handler through [ICS 25](../ics-025-handler-interface) or [ICS 26](../ics-026-routing-module).
 
 1. Initial client & port setup, in any order
     1. Client created on *A* for *B* (see [ICS 2](../ics-002-client-semantics))

spec/ics-005-port-allocation/README.md

@@ -31,7 +31,7 @@ port simultaneously. Channels are end-to-end between two ports, each of which mu
 Optionally, the host state machine can elect to expose port binding only to a specially-permissioned module manager,
 by generating a capability key specifically for the ability to bind ports. The module manager
 can then control which ports modules can bind to with a custom rule-set, and transfer ports to modules only when it
-has validated the port name & module. This role can be played by the relayer module (see [ICS 26](../ics-026-relayer-module)).
+has validated the port name & module. This role can be played by the routing module (see [ICS 26](../ics-026-routing-module)).
 
 ### Definitions
 
@@ -96,7 +96,7 @@ function callingModuleIdentifier(): SourceIdentifier {
 
 `generate` and `authenticate` functions are then defined as follows.
 
-In the former case, `generate` returns a new object-capability key, which must be returned by the outer-layer function, and `authenticate` requires that the outer-layer function take an extra argument `capability`, which is an object-capability key with uniqueness enforced by the host state machine. Outer-layer functions are any functions exposed by the IBC handler ([ICS 25](../ics-025-handler-interface)) or relayer module ([ICS 26](../ics-026-relayer-module)) to modules.
+In the former case, `generate` returns a new object-capability key, which must be returned by the outer-layer function, and `authenticate` requires that the outer-layer function take an extra argument `capability`, which is an object-capability key with uniqueness enforced by the host state machine. Outer-layer functions are any functions exposed by the IBC handler ([ICS 25](../ics-025-handler-interface)) or routing module ([ICS 26](../ics-026-routing-module)) to modules.
 
 ```
 function generate(): CapabilityKey {

spec/ics-020-fungible-token-transfer/README.md

@@ -11,15 +11,15 @@ modified: 2019-08-25
 
 ## Synopsis
 
-This standard document specifies packet data structure, state machine handling logic, and encoding details for the transfer of fungible tokens over an IBC channel between two modules on separate chains. The state machine logic presented allows for safe multi-chain denomination handling with permissionless channel opening. This logic constitutes a "fungible token transfer bridge module", interfacing between the IBC relayer module and an existing asset tracking module on the host state machine.
+This standard document specifies packet data structure, state machine handling logic, and encoding details for the transfer of fungible tokens over an IBC channel between two modules on separate chains. The state machine logic presented allows for safe multi-chain denomination handling with permissionless channel opening. This logic constitutes a "fungible token transfer bridge module", interfacing between the IBC routing module and an existing asset tracking module on the host state machine.
 
 ### Motivation
 
 Users of a set of chains connected over the IBC protocol might wish to utilise an asset issued on one chain on another chain, perhaps to make use of additional features such as exchange or privacy protection, while retaining fungibility with the original asset on the issuing chain. This application-layer standard describes a protocol for transferring fungible tokens between chains connected with IBC which preserves asset fungibility, preserves asset ownership, limits the impact of Byzantine faults, and requires no additional permissioning.
 
 ### Definitions
 
-The IBC handler interface & IBC relayer module interface are as defined in [ICS 25](../ics-025-handler-interface) and [ICS 26](../ics-026-relayer-module), respectively.
+The IBC handler interface & IBC routing module interface are as defined in [ICS 25](../ics-025-handler-interface) and [ICS 26](../ics-026-routing-module), respectively.
 
 ### Desired Properties
 
@@ -55,15 +55,15 @@ interface ModuleState {
 
 ### Sub-protocols
 
-The sub-protocols described herein should be implemented in a "fungible token transfer bridge" module with access to a bank module and to the IBC relayer module.
+The sub-protocols described herein should be implemented in a "fungible token transfer bridge" module with access to a bank module and to the IBC routing module.
 
 #### Port & channel setup
 
 The `setup` function must be called exactly once when the module is created (perhaps when the blockchain itself is initialised) to bind to the appropriate port and create an escrow address (owned by the module).
 
 ```typescript
 function setup() {
-  relayerModule.bindPort("bank", ModuleCallbacks{
+  routingModule.bindPort("bank", ModuleCallbacks{
     onChanOpenInit,
     onChanOpenTry,
     onChanOpenAck,
@@ -78,13 +78,13 @@ function setup() {
 }
 ```
 
-Once the `setup` function has been called, channels can be created through the IBC relayer module between instances of the fungible token transfer module on separate chains.
+Once the `setup` function has been called, channels can be created through the IBC routing module between instances of the fungible token transfer module on separate chains.
 
 An administrator (with the permissions to create connections & channels on the host state machine) is responsible for setting up connections to other state machines & creating channels
 to other instances of this module (or another module supporting this interface) on other chains. This specification defines packet handling semantics only, and defines them in such a fashion
 that the module itself doesn't need to worry about what connections or channels might or might not exist at any point in time.
 
-#### Relayer module callbacks
+#### routing module callbacks
 
 ##### Channel lifecycle management
 
@@ -211,7 +211,7 @@ function createOutgoingPacket(
 }
 ```
 
-`onRecvPacket` is called by the relayer module when a packet addressed to this module has been received.
+`onRecvPacket` is called by the routing module when a packet addressed to this module has been received.
 
 ```typescript
 function onRecvPacket(packet: Packet): bytes {
@@ -237,7 +237,7 @@ function onRecvPacket(packet: Packet): bytes {
 }
 ```
 
-`onAcknowledgePacket` is called by the relayer module when a packet sent by this module has been acknowledged.
+`onAcknowledgePacket` is called by the routing module when a packet sent by this module has been acknowledged.
 
 ```typescript
 function onAcknowledgePacket(
@@ -247,7 +247,7 @@ function onAcknowledgePacket(
 }
 ```
 
-`onTimeoutPacket` is called by the relayer module when a packet sent by this module has timed-out (such that it will not be received on the destination chain).
+`onTimeoutPacket` is called by the routing module when a packet sent by this module has timed-out (such that it will not be received on the destination chain).
 
 ```typescript
 function onTimeoutPacket(packet: Packet) {

spec/ics-024-host-requirements/README.md

@@ -30,7 +30,7 @@ IBC should require as simple an interface from the underlying state machine as p
 
 The host state machine must support a module system, whereby self-contained, potentially mutually distrusted packages of code can safely execute on the same ledger, control how and when they allow other modules to communicate with them, and be identified and manipulated by a "master module" or execution environment.
 
-The IBC/TAO specifications define the implementations of two modules: the core "IBC handler" module and the "IBC relayer" module. IBC/APP specifications further define other modules for particular packet handling application logic. IBC requires that the "master module" or execution environment can be used to grant other modules on the host state machine access to the IBC handler module and/or the IBC relayer module, but otherwise does not impose requirements on the functionality or communication abilities of any other modules which may be co-located on the state machine.
+The IBC/TAO specifications define the implementations of two modules: the core "IBC handler" module and the "IBC relayer" module. IBC/APP specifications further define other modules for particular packet handling application logic. IBC requires that the "master module" or execution environment can be used to grant other modules on the host state machine access to the IBC handler module and/or the IBC routing module, but otherwise does not impose requirements on the functionality or communication abilities of any other modules which may be co-located on the state machine.
 
 ### Paths, identifiers, separators
 
@@ -106,7 +106,7 @@ actually used in the private store implementation.
 | provableStore  | "ports/{identifier}/channels/{identifier}/nextSequenceRecv"              | uint64            | [ICS 4](../ics-004-channel-and-packet-semantics) |
 | provableStore  | "ports/{identifier}/channels/{identifier}/packets/{sequence}"            | bytes             | [ICS 4](../ics-004-channel-and-packet-semantics) |
 | provableStore  | "ports/{identifier}channels/{identifier}/acknowledgements/{sequence}"    | bytes             | [ICS 4](../ics-004-channel-and-packet-semantics) |
-| privateStore   | "callbacks/{identifier}"                                                 | ModuleCallbacks   | [ICS 26](../ics-026-relayer-module) |
+| privateStore   | "callbacks/{identifier}"                                                 | ModuleCallbacks   | [ICS 26](../ics-026-routing-module) |
 
 ### Module layout
 
@@ -118,7 +118,7 @@ Represented spatially, the layout of modules & their included specifications on
 | Host State Machine                                                               |
 |                                                                                  |
 | +-------------------+       +--------------------+      +----------------------+ |
-| | Module Aardvark   | <-->  | IBC Relayer Module |      | IBC Handler Module   | |
+| | Module Aardvark   | <-->  | IBC Routing Module |      | IBC Handler Module   | |
 | +-------------------+       |                    |      |                      | |
 |                             | Implements ICS 26. |      | Implements ICS 2, 3, | |
 |                             |                    |      | 4, 5 internally.     | |
@@ -199,13 +199,13 @@ Modules that wish to make use of particular IBC features MAY implement certain h
 
 ### Datagram submission
 
-Host state machines which implement the relayer module MAY define a `submitDatagram` function to submit [datagrams](../../docs/ibc/2_IBC_TERMINOLOGY.md), which will be included in transactions, directly to the relayer module (defined in [ICS 26](../ics-026-relayer-module):
+Host state machines which implement the routing module MAY define a `submitDatagram` function to submit [datagrams](../../docs/ibc/2_IBC_TERMINOLOGY.md), which will be included in transactions, directly to the routing module (defined in [ICS 26](../ics-026-routing-module):
 
 ```typescript
 type submitDatagram = (datagram: Datagram) => void
 ```
 
-`submitDatagram` allows relayer processes to submit IBC datagrams directly to the relayer module on the host state machine. Host state machines MAY require that the relayer process submitting the datagram has an account to pay transaction fees, signs over the datagram in a larger transaction structure, etc — `submitDatagram` MUST define & construct any such packaging required.
+`submitDatagram` allows relayer processes to submit IBC datagrams directly to the routing module on the host state machine. Host state machines MAY require that the relayer process submitting the datagram has an account to pay transaction fees, signs over the datagram in a larger transaction structure, etc — `submitDatagram` MUST define & construct any such packaging required.
 
 ### Exception system
 

spec/ics-025-handler-interface/README.md

@@ -41,23 +41,23 @@ The handler interface exposes `createClient`, `updateClient`, `queryClientConsen
 
 The handler interface exposes `connOpenInit`, `connOpenTry`, `connOpenAck`, `connOpenConfirm`, and `queryConnection`, as defined in [ICS 3](../ics-003-connection-semantics).
 
-The default IBC relayer module SHALL allow external calls to `connOpenTry`, `connOpenAck`, and `connOpenConfirm`.
+The default IBC routing module SHALL allow external calls to `connOpenTry`, `connOpenAck`, and `connOpenConfirm`.
 
 ### Channel lifecycle management
 
 By default, channels are owned by the creating port, meaning only the module bound to that port is allowed to inspect, close, or send on the channel. A module can create any number of channels utilising the same port.
 
 The handler interface exposes `chanOpenInit`, `chanOpenTry`, `chanOpenAck`, `chanOpenConfirm`, `chanCloseInit`, `chanCloseConfirm`, and `queryChannel`, as defined in [ICS 4](../ics-004-channel-and-packet-semantics).
 
-The default IBC relayer module SHALL allow external calls to `chanOpenTry`, `chanOpenAck`, `chanOpenConfirm`, and `chanCloseConfirm`.
+The default IBC routing module SHALL allow external calls to `chanOpenTry`, `chanOpenAck`, `chanOpenConfirm`, and `chanCloseConfirm`.
 
 ### Packet relay
 
 Packets are permissioned by channel (only a port which owns a channel can send or receive on it).
 
 The handler interface exposes `sendPacket`, `recvPacket`, `acknowledgePacket`, `timeoutPacket`, `timeoutOnClose`, and `cleanupPacket` as defined in [ICS 4](../ics-004-channel-and-packet-semantics).
 
-The default IBC relayer module SHALL allow external calls to `sendPacket`, `recvPacket`, `acknowledgePacket`, `timeoutPacket`, `timeoutOnClose`, and `cleanupPacket`.
+The default IBC routing module SHALL allow external calls to `sendPacket`, `recvPacket`, `acknowledgePacket`, `timeoutPacket`, `timeoutOnClose`, and `cleanupPacket`.
 
 ### Properties & Invariants