feat: add validator announce, multisig ISM deployment, and local-doma…

[blasrodri]

…in parameter

This commit combines two feature additions to the Hyperlane CLI tool:

1. Validator Announce and Multisig ISM Deployment:

   • Added deployment command for MerkleRootMultisigIsm with validator addresses and threshold
   • Added validator announcement command for signature storage location
   • Added helper functions for parsing ISM IDs and validators from events

2. Local Domain Parameter:

   • Added local-domain as a configurable parameter for deployment commands
   • Updated SetupWithIsm to accept dynamic local-domain instead of hardcoded value
   • Applied to deploy-zkism, deploy-noopism, and deploy-multisigism commands

Overview

[blasrodri]

@damiannolan I'm merging Walid changes from XO here.

[jonas089]

@damiannolan This PR is conflicting with our Rust fix for the ISM deployment #259.

The Hyp client didn't correctly set the trusted height and root for EVM, Celestia so we instead added the ISM deploy and update functionality to ev-prover's CLI.

[blasrodri]

@damiannolan This PR is conflicting with our Rust fix for the ISM deployment #259.

The Hyp client didn't correctly set the trusted height and root for EVM, Celestia so we instead added the ISM deploy and update functionality to ev-prover's CLI.

understood

will port this logic to this then

[damiannolan]

Maybe it would be good to add here that the validators list should be eth-style 20 byte 0x hex addresses.

[damiannolan]

@blasrodri did you say there's more to be pushed to this PR before its ready?

Lemme know when I should review :)

[blasrodri]

@blasrodri did you say there's more to be pushed to this PR before its ready?

Lemme know when I should review :)

Yes. Everything will be implemented in rust.

I'll ping you when it's ready

[damiannolan]

In rust? You mean Go, right?

[blasrodri]

In rust? You mean Go, right?

No. @jonas089 referred to the integration of some of these commands onto the ev-prover

[damiannolan]

Yes, there was a nuanced issue with instantiating the zk ism from the hyp golang client. And due to a bit of a mess with the overall celestia dependency tree between app and node it was easiest for us to include a command in the ev-prover binary to deploy the ism. Specifically we need to know the last evm state root within a blob posted to a celestia block. It would be possible to do it in hyp using Go but it would require rebasing the feat branch with main of celestia-app again and making sure its compatible with the celestia-node dependency there.

IMO I think the its good ux to be able to instantiate the zk ism from the ev-prover binary and also use it to set the zk ism identifier on a token. I don't think we should use the ev-prover binary for create hyperlane infra like, mailboxes, hooks, validator announce etc, I think its kind of outside of its scope.

[blasrodri]

Close in favor of #285