Refactor key management in infra and key funder #3023
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
… trevor/refactor-keys
nambrot
reviewed
Dec 5, 2023
nambrot
approved these changes
Dec 5, 2023
tkporter
added a commit
that referenced
this pull request
Dec 7, 2023
* 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
<!--
Are there any minor or drive-by changes also included?
-->
<!--
- Fixes #[issue number here]
-->
<!--
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
-->
<!--
What kind of testing have these changes undergone?
None/Manual/Unit Tests
-->
This was referenced Dec 7, 2023
tkporter
added a commit
that referenced
this pull request
Dec 7, 2023
### Description - cherry-picks #3023, which is necessary to stop funding the GCP relayer key - makes some additional small changes required to work well with key funder, specifically to filter out non-EVM chains and non-blessed chains (like Nautilus). The latter is because the environment specific multiprovider doesn't include non-blessed chains like Nautilus, and adding it messes up a bunch of our other core tooling - small change to #3023 to read in helloworld contract addresses from the correct environment that i will bring to `main` too ### Drive-by changes - fix deploy chains for key funder ### Related issues Part of #3024 ### Backward compatibility ye ### Testing ran funding script locally --------- Co-authored-by: OttBunn <132830906+ottbunn@users.noreply.github.com>
tkporter
added a commit
that referenced
this pull request
Dec 7, 2023
…3035) ### Description - Noticed an issue with #3023 where mainnet3 helloworld addresses were always used. This uses the correct environment and context - Also noticed errors with key funder infra because the neutron rpc url wasn't present - fixed the previous hack to accommodate this - Filter out non evm or blessed chains from key funder as well ### Drive-by changes n/a ### Related issues related to #3024 ### Backward compatibility yes ### Testing ran locally
daniel-savu
pushed a commit
that referenced
this pull request
Jun 5, 2024
### Description - cherry-picks #3023, which is necessary to stop funding the GCP relayer key - makes some additional small changes required to work well with key funder, specifically to filter out non-EVM chains and non-blessed chains (like Nautilus). The latter is because the environment specific multiprovider doesn't include non-blessed chains like Nautilus, and adding it messes up a bunch of our other core tooling - small change to #3023 to read in helloworld contract addresses from the correct environment that i will bring to `main` too ### Drive-by changes - fix deploy chains for key funder ### Related issues Part of #3024 ### Backward compatibility ye ### Testing ran funding script locally --------- Co-authored-by: OttBunn <132830906+ottbunn@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
bankrole, which we haven't used since the inception of abacus / hyperlanekey-utils.tsso 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{ [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 chainsDrive-by changes
Related issues
Backward compatibility
Testing