Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aggregation ISM #7

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions HIP-5.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
| hip | title | status | author | created |
| --- | --------- | ------ | ------ | ---------- |
| 5 | Combo ISM | Draft | asaj | 2022-12-21 |

### **Brief Summary / Abstract**

Defines the specification for an interchain security module (ISM) that combines other ISMs.

### **Motivation**

The goal of this HIP is to standardize the `ComboIsm` interface, so that users can compose multiple ISMs.
asaj marked this conversation as resolved.
Show resolved Hide resolved

For example, some users have expressed the desire to have a security model where n-of-m validators need to sign from some large, semi trusted set, but also one more more signatures from some smaller, more trusted set, are needed. This model can be expressed as the combination of two `MultisigIsms`.

### **Tech Spec**

A `ComboIsm` must return `2` in `type()`.

A `ComboIsm` must implement the following interface. Relayers should use the `combination()` view function to understand what metadata the `ISM` needs in order to verify a message.

```
interface IComboIsm is IInterchainSecurityModule {
/**
* @notice Returns the set of ISMs needed to verify _message
* @dev Can change based on the content of _message
* @param _message Hyperlane formatted interchain message
* @return The set of ISMs needed to verify _message
*/
function combination(
bytes calldata _message
) external view returns (address[] memory interchainSecurityModules);
}
```

A `ComboIsm` must expect the metadata passed to `verify()` to be formatted in the following way:

```
/**
* [ 0: 1] Expected ISM count
* [ 1:????] Lengths, as uint32s, of each ISM's metadata
* [????:????] Tightly packed metadata for each ISM
*/
```

Relayers must order the lengths and metadata in order to match the order returned by `combination(_message)`.

`ComboIsms` should avoid conditioning on frequently-changing state, as this may result in a relayer formatting metadata incorrectly.

### **Rationale**
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume section to be filled out?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tbh I'm not really sure what to put. Again, the design decisions seem very straightforward.


### **Backwards Compatibility**

### **Security Considerations**