Sealevel MultisigIsm - implement it #2216
Assignees
Labels
Comments
Merged
tkporter
added a commit
that referenced
this issue
May 17, 2023
### Description * Implements the message ID specific version of the multsig ISM (i.e. no fraud proofs) * Works by having a single "access control" PDA account (set in the Initialize fn), which stores the owner * Setting the set & threshold happens in a single instruction - i.e. no "add to set" or "remove from set" or "change only threshold", etc * Tests are split into unit tests & functional tests. Function tests are for things that involve account creation / CPIs that can't be unit tested well * Note that because instructions are usually just borsh serialized enums, this introduces the expectation that the first instruction of an ISM program is verify, and the second is the ISM type ### Drive-by changes * Some small quality of life changes ### Related issues - Fixes #2216 ### Backward compatibility _Are these changes backward compatible?_ Yes _Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling?_ None ### Testing _What kind of testing have these changes undergone?_ Unit Tests & functional tests
|
On-chain component done. Agent component blocked by #2173 |
|
gonna consider this done with #2251 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the only ISM implemented is a "rubber stamp" ISM that doesn't perform any kind of security verification.
We want to implement the multisig ISM as a Sealevel program. The Solidity version of this can be found here https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/solidity/contracts/isms/multisig/AbstractMultisigIsm.sol.
A MultisigIsm is a program that will allow the owner to configure the validator set and threshold for a remote domain. This is then used to verify messages from that remote domain to the local domain. The metadata bytes passed into the verify function must adhere to a specific format, and must include ECDSA signatures from at least
thresholdof the validators in the validator set that attest to the message. The signatures / the data that's been signed must follow the exact format that the existing solidity version expects. This is because the validator signatures are not destination-domain specific.As of #2173, the Multisig ISM will be split into two distinct ISMs: one ISM that takes in signatures over a merkle root where a merkle proof is provided that proves the message is included in that merkle root, and one ISM where validators signatures are over a specific message id. To work within the small transaction sizes on Solana, we've decided for now to only build out the latter version, where validator signatures are over the message ID. This way we don't need to provide the 32 * 32 bytes = 1024 bytes of the merkle proof in the transactions. Look at the PR for details of what this looks like
Implementation-wise, I think the validator sets & thresholds should be stored in a PDA account whose seed is based off the origin domain ID
So concretely:
thresholdvalidators in the set are provided that attest to the provided message ID. Its metadata format should match the metadata found in Make merkle proofs optional on multisig ISM #2173The text was updated successfully, but these errors were encountered: