Skip to content
This repository has been archived by the owner on Dec 7, 2023. It is now read-only.

🚀 Pulling upstream into main #23

Open
wants to merge 194 commits into
base: main
Choose a base branch
from
Open

🚀 Pulling upstream into main #23

wants to merge 194 commits into from

Conversation

HariSeldon23
Copy link

An automated PR to sync with upstream

Co-authored-by: josedev-union josedev-union@users.noreply.github.com

tkporter and others added 30 commits August 23, 2023 17:12
…perlane-xyz#2646)

### Description

just opening for image for now

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

<!--
What kind of testing have these changes undergone?

None/Manual/Unit Tests
-->

---------

Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com>
…z#2543)

### Description

This PR sets chain signer keys in the external secret.
related to
hyperlane-xyz#2458

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

<!--
What kind of testing have these changes undergone?

None/Manual/Unit Tests
-->

Co-authored-by: josedev-union <josedev-union@users.noreply.github.com>
Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
### Description

Adds addresses of the rc validator keys for solana, nautilus and their
testnet counterparts

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

<!--
What kind of testing have these changes undergone?

None/Manual/Unit Tests
-->
…yperlane-xyz#2647)

### Description

This change adds the possibility to configure a subfolder inside an S3
bucket, to avoid having to spin up an entire bucket for hyperlane.

### Drive-by changes

Nothing

### Related issues

None, chatted about it on Slack with @nambrot 

### Backward compatibility

Yes

I made the field optional in the `RawCheckpointSyncerConf` so that
current config are still valid and will continue to read/write at the
root of the bucket. That being said, I'm new to this code so I hope I
got it right

### Testing

None

---------

Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
### Description

Process user used in Dockerfile can now read and write to any volume
mounted under the `/data/` directory.

### Drive-by changes

N/A

### Related issues

Fixes: 2691

### Backward compatibility

Yes

### Testing

Manual

I've built the image locally and tested that we can mount any kind of
docker volume under the `/data/` directory
### Description

This does two things:
1) It parses the agent-specific configs for the relayer, validator, and
scraper.
2) It removes the rigid structures that had been in place for parsing
that were called out earlier and instead parses the serde json values
directly.

This PR does not cut over to the new versions just yet. That can happen
once we start integrating it into the testing and deployment pipelines.

### Drive-by changes

- Derive more was added and used where it made sense
- The old config macro was removed

### Related issues

- Progress on hyperlane-xyz#2215 

### Backward compatibility

Yes

### Testing

None
### Description
 
Depends on hyperlane-xyz#2583

Indexes IGP payments related to the relayer's data pda address. Unless
this address is specified in the config (`sealevel.relayer_account `),
no filtering is applied and all IGP payments are stored in the local
database.

<!--
What's included in this PR?
-->

### Drive-by changes

- Sets `HYP_BASE_GASPAYMENTENFORCEMENT` in `run-locally` for the
relayer, to test that it correctly indexes the IGP payment before
submitting the message
- A new config section (`sealevel`) is added to the relayer
- The `MessageIndexer` trait is replaced with
`SequenceIndexer<HyperlaneMessage>`, renaming `fetch_count_at_tip` to
`sequence_at_tip`. `SequenceIndexer` is now common to both the message
and igp indexers.
- The `parse_addr` macro is modified so it can be reused when parsing
the sealevel relayer address config too
- `rust/utils/sealevel-test.bash` is included because I was using it to
test locally, but I can remove it if the sealevel e2e test already does
all the steps there @mattiecnvr
- Performs a `try_into` conversion that can be removed once
hyperlane-xyz#2610 is done

### Related issues

- Fixes hyperlane-xyz#2501


### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

<!--
What kind of testing have these changes undergone?
-->
e2e tests but the pipeline is failing, likely fixed by
hyperlane-xyz#2602

---------

Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
…p transfers in tooling (hyperlane-xyz#2700)

### Description

Sadly, there's no programmatic way to submit transactions to Squads via
an API or anything. As a workaround, if `-k` is passed a Pubkey and not
a path to a Keypair as the payer, transactions will instead be logged in
a base58 serialized format that can then be copied into Squads.
Instructions for exactly how to do this are found in our Notion

So this includes:
* Allow for the payer to just be a Pubkey without a Keypair
* Some commands & functions to allow for ownership transfer

### Drive-by changes

* There was a whole directory
`rust/chains/hyperlane-sealevel/src/solana` that somehow got into main,
I deleted this
* Cleaned up some logs to be formatted more nicely

### Related issues

part of hyperlane-xyz/issues#545

### Backward compatibility

backward compatible

### Testing

Transferred ownership of devnet

---------

Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com>
### Description

- Add support for multi-protocol to the HelloWorld app and Kathy service
- Create a new MultiProtocolCore

### Related issues

hyperlane-xyz#2503

### Backward compatibility

Yes

### Testing

- Tested new Kathy abstraction on existing EVM while we wait for
Sealevel Kathy to be unblocked
- Tested using local config stubs for both EVM and Sealevel
### Description

- Migrating `SealevelTokenAdapter` to monorepo for providing a common abstraction
- Common serialization code under `sdk/sealevel`

### Related issues

- hyperlane-xyz#2652 

### Backward compatibility

Yes

### Testing

Manual

---------

Co-authored-by: J M Rossy <jm.rossy@gmail.com>
### Description

- Script to monitor token balances for Nautilus-Zebec-Solana warp route
(hardcoded)
- Helm command to deploy warp route monitoring script to Kubernetes

### Drive-by changes

- Updated default version to testnet3 for kathy and liquidity-layer

### Related issues

- issue hyperlane-xyz/issues#549

### Backward compatibility

Yes

### Testing

Manual
### Description

- Currently if you do keyboard interrupt while running the deploy
script, none of the already deployed addresses get written to the
artifacts.
- Register a SIGINT handler in the `deployWithArtifacts` script

### Drive-by changes

None

### Related issues

None

### Backward compatibility

Yes

### Testing

Manual
### Description
Tooling to get / set gas oracle data for sealevel, part of
hyperlane-xyz/issues#568

The PR adds two IGP oracle commands. If the values to be set are
specified, then the command performs a write using the key configured.
Otherwise, it performs a read. Unsure whether this is the best UX, happy
to change it.

Usage example:
```bash
# Get gas values
cargo run --bin hyperlane-sealevel-client igp destination-gas-overhead --environments-dir ./sealevel/environments --environment testnet3 --chain-name solanadevnet --remote-domain 88002

# Set gas values. Note the added `--gas-overhead 159736` flag
cargo run --bin hyperlane-sealevel-client igp destination-gas-overhead --environments-dir ./sealevel/environments --environment testnet3 --chain-name solanadevnet --remote-domain 88002 --gas-overhead 159736
```

There's also a small warp route util added to read the destination gas:
```bash
 cargo run --bin hyperlane-sealevel-client warp-route destination-gas --program-id 84DAG9VX5CvefQrBUGh9Gp66kmkat2voaM4MB2YwpGW1 --destination-domain 88002
 ```

<!--
What's included in this PR?
-->

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling?

Yes/No
-->

### Testing
Manual
<!--
What kind of testing have these changes undergone?

None/Manual/Unit Tests
-->
### Description
Fixes a current deployment issue due to some changes in the infra
deployment.

Also caught an error in the schema for the matching list type and
updated it.
)

Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
Removes some unnecessary logs from the sealevel igp indexing fn. Also
instruments the eta calculator in response to
hyperlane-xyz#2723

### Description

<!--
What's included in this PR?
-->

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

<!--
What kind of testing have these changes undergone?

None/Manual/Unit Tests
-->
### Description

<!--
What's included in this PR?
-->

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

<!--
What kind of testing have these changes undergone?

None/Manual/Unit Tests
-->
### Description

- Build on hyperlane-xyz#2684, migrates the EvmAdapter and missing utils from the warp UI
- Remove the token App as it's unused and redundant with adapters
- Add IGP serialization code for hyperlane-xyz#2546 
- Simplify multi-protocol adapters in SDK
- Make token adapters extend base adapters
- Move token serialization code to token package

### Drive-by changes

- Update Sepolia RPC which was causing errors

### Related issues

hyperlane-xyz#2652 

### Backward compatibility

Yes

### Testing

Tested these in warp UI

---------

Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>
Simplify mailbox and make interfaces payable

Update version constant

Keep message ID events
Use mailbox callback to authenticate messages in hooks where necessary (hyperlane-xyz#2609)

Co-authored-by: Kunal Arora <55632507+aroralanuk@users.noreply.github.com>
- IGP as a standalone hook, implementing postDispatch to call payForGas
directly
- Setting a DEFAULT_GAS_USAGE if metadata not specified and
message.senderAddress() as refund address if not specified.

- None

Fixes hyperlane-xyz/issues#511

Yes, same interface as the previous IGP but for Mailbox V3

Unit Tests

---------

Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>
…-xyz#2632)

- Updated the OP Stack tests for the Mailbox V3 transient storage
version
- Allowing OPStackHook to send msg.value at the time of message delivery
(uses bit masking)
- Added LibBit library, will be useful for all the auth hooks which can
send `msg.value`

- None

- Fixes breaking OP Stack tests for
hyperlane-xyz/issues#513
- Also fixes
hyperlane-xyz#2410

No

Unit tests

---------

Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>

Remove e2e and add yarn build to CI

Adding protocol fees (hyperlane-xyz#2640)

- Adding protocol fee as a hook

- None

V3

Yes

Fuzz tests

---------

Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>
- fixes GasRouter expectRevert message
- added TestMerkleRootHook for proof() and fixes MerkleRootMultisig test
- fixes ERC5164 tests post v3 changes

- added contract name to mailbox and abstractHook error messages
- removed unnecessary tests for "message too large"
- downgrade slither in actions to 0.3.0 because of their recent "missing
inheritance" bug on main

- V3

Yes

Unit tests
- `quoteDispatch` added to `IPostDispatchHook` interface and the
relevant hooks:
     - StaticProtocolFee
     - OPStackHook
     - InterchainGasPaymaster
     - MerkleTreeHook
     - PausableHook (no tests)
     - DomainRoutingHook (no tests)
     - ConfigFallbackDomainRoutingHook
     - ConfigurableDomainRoutingHook (no tests)

- `expectEmit` -> `expectCall`

- Quote in V3

Yes

Uint tests
### Description

- AggregationHook for v3

### Drive-by changes

None

### Related issues

v3

hyperlane-xyz/issues#514

### Backward compatibility

Yes

### Testing

Always be fuzzing
nambrot and others added 30 commits November 28, 2023 23:08
### Description

This PR adds a slightly better error message if there is no `./configs`
folder for the CLI invocation
### Description

deploys agents with new release

### Drive-by changes

n/a

### Related issues

n/a
### Backward compatibility

ye

### Testing

deployed
### Description

Update to latest ethers-rs (forked) version with
hyperlane-xyz/ethers-rs#9

### Drive-by changes

n/a

### Related issues

n/a

### Backward compatibility

n/a

### Testing

Planning to deploy with it, but the ethers-rs version is well tested
### Description

Deploys w/ hyperlane-xyz#2998

### Drive-by changes

- Had to remove mantapacific from the list of scraper chains because
it's not present in the DB domain table atm

### Related issues

n/a

### Backward compatibility

n/a

### Testing

Deployed
### Description

Updates the values given the current market conditions

### Drive-by changes

Add a sleep for avoid getting rate limited
### Description

Uses a version of our ethers fork with
hyperlane-xyz/ethers-rs#10, which adds back a
change that I had reverted from
hyperlane-xyz/ethers-rs#8

This is required to fix bsc / bsctestnet txs, where the base fee is 0
and we want to estimate the priority fee

### Drive-by changes

n/a

### Related issues

n/a

### Backward compatibility

ye

### Testing
deployed and saw successful bsc / bsctestnet msgs
### Description

- fix to filter out igp in merging the given and SDK artifacts

### Drive-by changes

- None

### Related issues

- None

### Backward compatibility

Yes

### Testing

Manual

---------

Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>
…fact (hyperlane-xyz#2993)

### Description

- changing `multisigIsm` to`interchainSecurityModule` for core
deployments artifact

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

<!--
What kind of testing have these changes undergone?

None/Manual/Unit Tests
-->
### Description

Add artifact selection step to warp deploy
Improve chain selection for kurtosis agent deploy

### Drive-by changes

Add chain metadata consts validation unit test

### Related issues

Fixes hyperlane-xyz/issues#774

### Backward compatibility

Small break in kurtosis deploy args, likely won't be noticed.

### Testing

Manual
hyperlane-xyz#3005)

### Description

- CLI was using a static start block numbers for core chains or getting
the latest block number from a PI chain for agent config which is
redundant and dangerous. Instead, I updated to using the
`mailbox.deployedBlock()` which should precede all other indexable
contract deployment and is hence safer.

### Drive-by changes

- filtering the agent configs in CLI is redundant since the
`HyperlaneDeploymentArtifactsSchema` requires all the specified entries
and if `writeAgentConfig` gets an artifacts which doesn't contain these,
we should throw an error and not filter them.

### Related issues

- related to hyperlane-xyz/issues#736

### Backward compatibility

Yes

### Testing

Manual b/w anvil1 and anvil2
### Description

Deploying with new release

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

<!--
What kind of testing have these changes undergone?

None/Manual/Unit Tests
-->
…hains to match addresses in MultiProtocolApp (hyperlane-xyz#3001)

### Description

Fixes 2 issues:
1. Estimates gas in Kathy by explicitly specifying the `from` address
due to this bug with PolygonZkEvm when using a non-zero value
0xPolygonHermez/zkevm-node#2869
2. Now that we've added neutron & mantapacific as mainnet chains but we
don't have helloworld deployments on these chains, Kathy was trying to
send to & from these chains. To fix, I changed the constructor of
`MultiProtocolApp` to intersect the multiProvider to only work with the
chains specified in `addresses`

### Drive-by changes

n/a

### Related issues

n/a

### Backward compatibility

ye

### Testing

Ran kathy locally successfully & sent from polygonzkevm
### Description

Deploy Kathy with hyperlane-xyz#3001 

### Drive-by changes

Small fix to deploy kathy successfully - because the relayer chains
doesn't include neutron and kathy will try to create a multiprovider for
all chains the env, we need to use the environment chain names as the
helm `hyperlane.chains` value

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

<!--
What kind of testing have these changes undergone?

None/Manual/Unit Tests
-->
)

### Description

Turns out bridging from L1 to Base has been broken the whole time :(
it's because the version of @eth-optimism/sdk we were using was 1.8.0
(according to yarn.lock) which was released in late 2022
https://github.com/ethereum-optimism/optimism/releases/tag/%40eth-optimism%2Fsdk%401.8.0,
far before Base was launched. So we'd always get this error in key
funder because we rely on the optimism SDK knowing about Base's chain
ID:
```
{"chain":"base","error":"Error: cannot get contract AddressManager for unknown L2 chain ID 8453, you must provide an address\n    at getOEContract (/hyperlane-monorepo/node_modules/@eth-optimism/sdk/src/utils/contracts.ts:58:11)\n    at getAllOEContracts (/hyperlane-monorepo/node_modules/@eth-optimism/sdk/src/utils/contracts.ts:121:46)\n    at new CrossChainMessenger (/hyperlane-monorepo/node_modules/@eth-optimism/sdk/src/cross-chain-messenger.ts:170:39)\n    at ContextFunder.bridgeToOptimism (/hyperlane-monorepo/typescript/infra/scripts/funding/fund-keys-from-deployer.ts:652:33)\n    at ContextFunder.bridgeToL2 (/hyperlane-monorepo/typescript/infra/scripts/funding/fund-keys-from-deployer.ts:637:23)\n    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n    at async ContextFunder.bridgeIfL2 (/hyperlane-monorepo/typescript/infra/scripts/funding/fund-keys-from-deployer.ts:492:9)\n    at async gracefullyHandleError (/hyperlane-monorepo/typescript/infra/scripts/funding/fund-keys-from-deployer.ts:774:5)\n    at async /hyperlane-monorepo/typescript/infra/scripts/funding/fund-keys-from-deployer.ts:394:29\n    at async Promise.all (index 9)","level":"error","message":"Error bridging to L2"}
```

The fix was just to upgrade to a newer optimism SDK version

A mystery to me is that we'd get that log ^ but sometimes the key funder
pod would show as having ran successfully. My best guess here is there
was a race condition in `fund` when we had a variable local to the
function called `failureOccurred` that many promises which were
`Promise.all`'d would read and write to it via `failureOccurred ||=
await someFallibleFn()`. I changed the logic here to not have multiple
concurrent promises contend for the variable

Also made a small change to not include mantapacific in the list of
relayer keys for the Hyperlane context. It's not ever used, and had a
downstream effect of us trying to fund the Kathy key on mantapacific,
which we don't want to actually do

### Drive-by changes

n/a

### Related issues

n/a

### Backward compatibility

ye

### Testing

ran locally
### Description

- enable configuring hooks in the CLI (merkle, igp, protocolFee,
aggregation, routing)
- use preset by default without prompting

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

<!--
What kind of testing have these changes undergone?

None/Manual/Unit Tests
-->
### Description

https://eslint.org/docs/latest/rules/guard-for-in

### Drive-by changes

Fix lint error in SDK Sealevel adapter

### Backward compatibility

Yes
…xyz#3016)

### Description

- CI fails otherwise

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

Manual
### Description

- Improve shared context utility with conditional typing and core artifact handling
- Improve UX of send and status commands with prompts
- Prompt for key if required and not provided

### Drive-by Changes

Update the token readme for hyperlane-xyz/issues#715

### Backward compatibility

Yes

### Testing

Manual
…-xyz#3021)

### Description

- don't restrict user to having two chains for ism config
- if the user accidentally picks two chains, we prompt them again to
confirm if they don't want to use the hyperlane validators for their
multisigconfig

### Drive-by changes

None

### Related issues

- fixes hyperlane-xyz/issues#811

### Backward compatibility

Yes

### Testing

Manual between arbitrumgoerli and anvil1
Done:
- scaffolding for fetching custom agent metrics
- abstractions for building a metrics fetcher for a given VM
- querying cosmos balances; e2e tested.
- querying evm balances; e2e tested.
- **Note that as a result, evm addresses are now no longer zero-padded
when printed in the logs. This may break existing log queries**
- fixed a nasty bug on ubuntu where wasmd (osmosisd dependency, part of
the grpc query flow) would panic when a block is specified via
`x-cosmos-block-height`. The fix was to bump the version of osmosisd
from `19.0.0` to `20.5.0`. **Note that when running e2e on Mac OS, the
osmosis version in use is still 19.0.0**. That's because we need a fork
that publishes a darwin target binary (currently pointing
[here](https://github.com/hashableric/osmosis/releases/download/v19.0.0-mnts/osmosisd-19.0.0-mnts-darwin-arm64.tar.gz))

For follow up PR:
- sealevel balance querying

I'm open to all renaming suggestions, I just tried to speed through and
didn't ponder names too much

Relates to hyperlane-xyz/issues#701
Closes hyperlane-xyz/issues#702 (because the
balance becomes available in the metrics endpoint for polling)
Publishes sealevel balance as a relayer metric

**Drive-by Changes**
- Creates `HyperlaneSealevelError`, a `hyperlane-sealevel` specific type
to avoid including sealevel errors in `hyperlane-core`'s
`ChainCommunicationError`. It's pretty empty now, but we have a starting
point now. This follows the approach used in `hyperlane-cosmos` too.
- Includes an rpc provider instance in `SealevelProvider`, and uses it
to add `get_balance` on `SealevelProvider`.

**Testing**
None, as sealevel e2e is currently disabled
There are way too many `No message found in DB for leaf index` logs to
have them at debug level. Also the wording makes it seem like an error
when it's not.
# Releases
## @hyperlane-xyz/cli@3.3.0

### Minor Changes

-   7e620c9: Allow CLI to accept hook as a config

### Patch Changes

-   f44589e: Improve warp and kurtosis deploy command UX

-   2da6cce: Allow users to only configure validators for their chain

    -   Don't restrict user to having two chains for ism config
- If the user accidentally picks two chains, we prompt them again to
confirm if they don't want to use the hyperlane validators for their
multisigConfig

- 9f2c7ce: Removing agentStartBlocks and using mailbox.deployedBlock()
instead

-   9705079: Improve UX of the send and status commands

-   c606b6a: Add figlet to CLI

-   Updated dependencies [7e620c9]

-   Updated dependencies [3501755]

-   Updated dependencies [9f2c7ce]
    -   @hyperlane-xyz/sdk@3.3.0
    -   @hyperlane-xyz/utils@3.3.0

## @hyperlane-xyz/core@3.3.0

### Patch Changes

-   3501755: Rename StaticProtocolFee hook to ProtocolFee for clarity
    -   @hyperlane-xyz/utils@3.3.0

## @hyperlane-xyz/helloworld@3.3.0

### Patch Changes

-   Updated dependencies [7e620c9]
-   Updated dependencies [3501755]
-   Updated dependencies [9f2c7ce]
    -   @hyperlane-xyz/sdk@3.3.0
    -   @hyperlane-xyz/core@3.3.0

## @hyperlane-xyz/sdk@3.3.0

### Patch Changes

-   7e620c9: Allow CLI to accept hook as a config
-   3501755: Rename StaticProtocolFee hook to ProtocolFee for clarity
- 9f2c7ce: Removing agentStartBlocks and using mailbox.deployedBlock()
instead
-   Updated dependencies [3501755]
    -   @hyperlane-xyz/core@3.3.0
    -   @hyperlane-xyz/utils@3.3.0

## @hyperlane-xyz/utils@3.3.0

## @hyperlane-xyz/infra@3.3.0

### Patch Changes

-   7e620c9: Allow CLI to accept hook as a config
- 9f2c7ce: Removing agentStartBlocks and using mailbox.deployedBlock()
instead
-   Updated dependencies [7e620c9]
-   Updated dependencies [3501755]
-   Updated dependencies [9f2c7ce]
    -   @hyperlane-xyz/sdk@3.3.0
    -   @hyperlane-xyz/helloworld@3.3.0
    -   @hyperlane-xyz/utils@3.3.0

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
…hyperlane-xyz#3009)

### Description

- `DefaultFallbackRoutingIsm` needs the mailbox address which meant
`DefaultFallbackRoutingIsmFactory` needed the mailbox address which is
not ideal. So, I switched to non-factory deployments for this specific
ISM type.
- CLI does the ISM deployment inside core deployment instead of ISM
first and core then.
- Using the coreDeployer's `cachedAddresses` to store the latest ie
toplevel ISM.

### Drive-by changes

- fixed bug in `ismFactory.fromAddressMap` to not use the multiprovider
filtered by contract map. This is undesirable as CLI user can provide
chain selection and artifacts which doesn't include all the chains in
the configs (and when we call `multiprovider.getDomainId` for the origin
which may now be missing from the filtered MP, we get an error).

### Related issues

- fixes hyperlane-xyz#2895

### Backward compatibility

Yes

### Testing

Manual through CLI
### Description

* Remove the `bank` role, which we haven't used since the inception of
abacus / hyperlane
* Big changes to `key-utils.ts` so that there's a single source of truth
on what kind of keys are used depending on the role & chain. Before this
was sprinkled in a few different places
* You can now get an object of `{ [chain]: { [role]: keys[] } }`, so
it's super clear what kind of key relates to which chain. For example,
before we would use the AWS-based relayer key for EVM chains, and then a
GCP-based relayer key for non-EVM chains. But this wasn't really honored
by key funder - it had no way of knowing to only fund the AWS relayer on
EVM chains, and only fund the GCP relayer on non-EVM chains. Same
situation for Kathy, where we want to use AWS keys for EVM chains but
the GCP key for non-EVM chains
* On v2 and prior to that we were using the AWS-based key for Kathy.
Originally, we also launched v3 this way. However it was changed on v3
to use the GCP key for Kathy, causing us to fund both types of addresses
on v3. This makes it more clear that we should be using the AWS-based
key for Kathy on EVM chains

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

<!--
- Fixes #[issue number here]
-->

### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

<!--
What kind of testing have these changes undergone?

None/Manual/Unit Tests
-->
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet