GITBOOK-242: Fix URLs

hyperlane-xyz · Jul 20, 2023 · 972d1f3 · 972d1f3
1 parent b1d531b
commit 972d1f3
Show file tree

Hide file tree

Showing 9 changed files with 106 additions and 119 deletions.
diff --git a/SUMMARY.md b/SUMMARY.md
@@ -72,8 +72,8 @@
 * [Interchain security modules](protocol/sovereign-consensus/README.md)
   * [Interface](protocol/sovereign-consensus/interchain-security-modules.md)
   * [Multisig ISM](protocol/sovereign-consensus/multisig-ism.md)
-  * [Routing ISM](protocol/sovereign-consensus/aggregation-ism.md)
-  * [Aggregation ISM](protocol/sovereign-consensus/aggregation-ism-1.md)
+  * [Routing ISM](protocol/sovereign-consensus/routing-ism.md)
+  * [Aggregation ISM](protocol/sovereign-consensus/aggregation-ism.md)
   * [Optimistic ISM](protocol/sovereign-consensus/optimistic-ism.md)
   * [Wormhole ISM](protocol/sovereign-consensus/wormhole-ism.md)
   * [Hook ISM](protocol/sovereign-consensus/hook-ism.md)

diff --git a/apis-and-sdks/hooks/README.md b/apis-and-sdks/hooks/README.md
@@ -8,7 +8,7 @@ description: Use native or third-party bridges as "hooks" for your dispatch call
 
 Developers can use the Hooks API to secure their messages either through native bridges like for Optimism or use other third-party bridge vendors.
 
-There are cases where you may feel the MultisigISM or your own configured ISM security isn't sufficient for your application and instead you want the security of a native bridge like Optimism or a third-party vendor like Wormhole. You can opt-in to such do so with hooks without leaving the purview of the Mailbox interface and needing a bridge-specific implementation. Hooks can also be used as routes specified for the [aggregation-ism-1.md](../../protocol/sovereign-consensus/aggregation-ism-1.md "mention").
+There are cases where you may feel the MultisigISM or your own configured ISM security isn't sufficient for your application and instead you want the security of a native bridge like Optimism or a third-party vendor like Wormhole. You can opt-in to such do so with hooks without leaving the purview of the Mailbox interface and needing a bridge-specific implementation. Hooks can also be used as routes specified for the [aggregation-ism.md](../../protocol/sovereign-consensus/aggregation-ism.md "mention").
 
 Hooks come in a pair of contracts, the `IMessageHook` on the source chain and `HookISM` on the destination chain. `IMessageHook` provides you the `postDispatch` method which you can call after `IMailbox.dispatch` providing the destination domain and the messageId. You pass on the `messageId` as payload to configured external provider (defined by the hook) which interacts with the corresponding `HookISM` contract on the destination chain. If the ISM can verify the validity of the messageId, the message can be delivered successfully by the relayer.
 
@@ -161,7 +161,7 @@ All ERC-5164 compatible bridge vendors have to implement contracts `IMessageDisp
 
 The `ERC-5164` hook calls the dispatchMessage function on the `IMessageDispatcher` which send messages to IMessageExecutor at the specified toChainId. The executor contract has the special access to write to the `ERC5164ISM` contract, setting the messageId in the `verifiedMessageId`'s mapping to the original source chain sender (ie. the user).  The relayer carries just the message with no metadata, waiting for the  bridge provider to prove the validity and transport the message to the destination chain and the message delivery is then verified.&#x20;
 
-This open interface allows any third party bridge provider like Wormhole or Telepathy to implement the interface and be supported by the ERC5164Hook out-of-the-box. This is especially useful if you want the reliability and security of a diverse set of bridge vendors by using the [aggregation-ism-1.md](../../protocol/sovereign-consensus/aggregation-ism-1.md "mention").
+This open interface allows any third party bridge provider like Wormhole or Telepathy to implement the interface and be supported by the ERC5164Hook out-of-the-box. This is especially useful if you want the reliability and security of a diverse set of bridge vendors by using the [aggregation-ism.md](../../protocol/sovereign-consensus/aggregation-ism.md "mention").
 
 ```mermaid
 %%{ init: {

diff --git a/protocol/sovereign-consensus/README.md b/protocol/sovereign-consensus/README.md
@@ -18,7 +18,7 @@ For example, application developers that want increased sovereignty over interch
 
 ISMs act as "security [legos](https://en.wikipedia.org/wiki/Lego)". Developers can mix and match different ISMs together to encode a security model that best fits their needs.
 
-For example, application developers that want additional security could deploy an [aggregation-ism-1.md](aggregation-ism-1.md "mention") that requires verification by both a [multisig-ism.md](multisig-ism.md "mention") configured with validators from the Hyperlane community, **and** a [wormhole-ism.md](wormhole-ism.md "mention") that verifies that a quorum of the [Wormhole](https://wormhole.com/) validator set verified the message.
+For example, application developers that want additional security could deploy an [aggregation-ism.md](aggregation-ism.md "mention") that requires verification by both a [multisig-ism.md](multisig-ism.md "mention") configured with validators from the Hyperlane community, **and** a [wormhole-ism.md](wormhole-ism.md "mention") that verifies that a quorum of the [Wormhole](https://wormhole.com/) validator set verified the message.
 
 ### Customize
 

diff --git a/protocol/sovereign-consensus/aggregation-ism-1.md b/protocol/sovereign-consensus/aggregation-ism-1.md
diff --git a/protocol/sovereign-consensus/aggregation-ism.md b/protocol/sovereign-consensus/aggregation-ism.md
@@ -1,46 +1,54 @@
 ---
-description: Smarter interchain security models
+description: Aggregate security from multiple ISMs
 ---
 
-# Routing ISM
+# Aggregation ISM
 
-Developers can use a `RoutingISM` to delegate message verification to a different ISM. This allows developers to change security models based on message content or application context.&#x20;
+Developers can use an `AggregationISM` to combine security from multiple ISMs. Simply put, an `AggregationISM` requires that `m` of `n` ISMs verify a particular interchain message.
 
 ## Interface
 
-`RoutingISMs` must implement the `IRoutingIsm` interface.
+`AggregationISMs` must implement the `IAggregationIsm` interface.
 
 ```solidity
-interface IRoutingIsm is IInterchainSecurityModule {
+// SPDX-License-Identifier: MIT OR Apache-2.0
+pragma solidity >=0.6.11;
+
+import {IInterchainSecurityModule} from "../IInterchainSecurityModule.sol";
+
+interface IAggregationIsm is IInterchainSecurityModule {
     /**
-     * @notice Returns the ISM responsible for verifying _message
+     * @notice Returns the set of modules responsible for verifying _message
+     * and the number of modules that must verify
      * @dev Can change based on the content of _message
-     * @param _message Formatted Hyperlane message (see Message.sol).
-     * @return module The ISM to use to verify _message
+     * @param _message Hyperlane formatted interchain message
+     * @return modules The array of ISM addresses
+     * @return threshold The number of modules needed to verify
      */
-    function route(bytes calldata _message)
+    function modulesAndThreshold(bytes calldata _message)
         external
         view
-        returns (IInterchainSecurityModule);
+        returns (address[] memory modules, uint8 threshold);
 }
+
 ```
 
 ## Configure
 
-The hyperlane-monorepo contains a `RoutingISM` implementation, `DomainRoutingIsm`, that application developers can deploy off-the-shelf, specifying their desired configuration.
+The hyperlane-monorepo contains an `AggregationISM` implementation that application developers can deploy off-the-shelf, specifying their desired configuration.
 
-This ISM simply switches security models depending on the origin chain of the message. A simple use case for this is to use different [multisig-ism.md](multisig-ism.md "mention") validator sets for each chain.
+Developers can configure, for each origin chain, a set of `n` ISMs, and the number of ISMs needed to verify a message.
 
-Eventually, you could imagine a `DomainRoutingIsm` routing to different light-client-based ISMs, depending on the type of consensus protocol used on the origin chain.
+`AggregationISMs` can aggregate the security of any ISMs. For example, users can deploy a [multisig-ism.md](multisig-ism.md "mention") with their own validator set, and deploy an `AggregationISM` that aggregates that ISM with the Hyperlane default ISM.
 
-The [hyperlane-deploy repo](https://github.com/hyperlane-xyz/hyperlane-deploy) contains the tooling and instructions needed to deploy and configure a `DomainRoutingIsm`.
+The [hyperlane-deploy repo](https://github.com/hyperlane-xyz/hyperlane-deploy) contains the tooling and instructions needed to deploy and configure an `AggregationISM`.
 
 ## Customize
 
-The hyperlane-monorepo contains an abstract `RoutingISM` implementation that application developers can fork.
+The hyperlane-monorepo contains an abstract `AggregationISM` implementation that application developers can fork.
 
-Developers simply need to implement the `route()` function.
+Developers simply need to implement the `modulesAndThreshold()` function.
 
-By creating a custom implementation, application developers can tailor the security provided by a `RoutingISM` to the needs of their application.
+By creating a custom implementation, application developers can tailor the security provided by a `AggregationISM` to the needs of their application.
 
-For example, a custom implementation could change security models based on the contents of the message or the state of the application receiving the message.
+For example, a custom implementation could require that low value messages be verified by a [multisig-ism.md](multisig-ism.md "mention"), and require that high value messages _also_ be verified by a [wormhole-ism.md](wormhole-ism.md "mention").
diff --git a/protocol/sovereign-consensus/routing-ism.md b/protocol/sovereign-consensus/routing-ism.md
@@ -0,0 +1,46 @@
+---
+description: Smarter interchain security models
+---
+
+# Routing ISM
+
+Developers can use a `RoutingISM` to delegate message verification to a different ISM. This allows developers to change security models based on message content or application context.&#x20;
+
+## Interface
+
+`RoutingISMs` must implement the `IRoutingIsm` interface.
+
+```solidity
+interface IRoutingIsm is IInterchainSecurityModule {
+    /**
+     * @notice Returns the ISM responsible for verifying _message
+     * @dev Can change based on the content of _message
+     * @param _message Formatted Hyperlane message (see Message.sol).
+     * @return module The ISM to use to verify _message
+     */
+    function route(bytes calldata _message)
+        external
+        view
+        returns (IInterchainSecurityModule);
+}
+```
+
+## Configure
+
+The hyperlane-monorepo contains a `RoutingISM` implementation, `DomainRoutingIsm`, that application developers can deploy off-the-shelf, specifying their desired configuration.
+
+This ISM simply switches security models depending on the origin chain of the message. A simple use case for this is to use different [multisig-ism.md](multisig-ism.md "mention") validator sets for each chain.
+
+Eventually, you could imagine a `DomainRoutingIsm` routing to different light-client-based ISMs, depending on the type of consensus protocol used on the origin chain.
+
+The [hyperlane-deploy repo](https://github.com/hyperlane-xyz/hyperlane-deploy) contains the tooling and instructions needed to deploy and configure a `DomainRoutingIsm`.
+
+## Customize
+
+The hyperlane-monorepo contains an abstract `RoutingISM` implementation that application developers can fork.
+
+Developers simply need to implement the `route()` function.
+
+By creating a custom implementation, application developers can tailor the security provided by a `RoutingISM` to the needs of their application.
+
+For example, a custom implementation could change security models based on the contents of the message or the state of the application receiving the message.
diff --git a/protocol/sovereign-consensus/wormhole-ism.md b/protocol/sovereign-consensus/wormhole-ism.md
@@ -14,4 +14,4 @@ This ISM requires that 13 of the 19 [Wormhole guardians](https://wormhole.com/ne
 
 ## Compose
 
-Developers can compose a Wormhole ISM with a [multisig-ism.md](multisig-ism.md "mention")using an [aggregation-ism-1.md](aggregation-ism-1.md "mention") to require that m of n Hyperlane validators **and** 13-of-19 Wormhole guardians verify a message.
+Developers can compose a Wormhole ISM with a [multisig-ism.md](multisig-ism.md "mention")using an [aggregation-ism.md](aggregation-ism.md "mention") to require that m of n Hyperlane validators **and** 13-of-19 Wormhole guardians verify a message.