The home for Hyperlane core contracts, sdk packages, and other infrastructure
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
hyperlane-monorepo/rust/main/Cargo.toml

328 lines
8.4 KiB

[workspace]
members = [
"agents/relayer",
"agents/scraper",
"agents/validator",
"chains/hyperlane-cosmos",
"chains/hyperlane-ethereum",
"chains/hyperlane-fuel",
"chains/hyperlane-sealevel",
"ethers-prometheus",
"hyperlane-base",
"hyperlane-core",
"hyperlane-test",
"utils/abigen",
"utils/backtrace-oneline",
"utils/hex",
"utils/run-locally",
]
[workspace.package]
documentation = "https://docs.hyperlane.xyz"
edition = "2021"
homepage = "https://hyperlane.xyz"
license-file = "../LICENSE.md"
publish = false
version = "0.1.0"
[workspace.dependencies]
Inflector = "0.11.4"
anyhow = "1.0"
async-trait = "0.1"
Fallback Provider Refactor (#3127) ### Description - Generalizes the fallback provider. Now any provider type can be used in it, as long as it implements `Into<Box<dyn BlockNumberGetter>> + Clone` (aka it can be wrapped into a struct that reads the current block #, and it can be cloned). - moves the fallback provider implementation to hyperlane-core - had serious issues with getting versions to successfully resolve - next time I run into issues, strongly inclined to create a new crate with dependencies for all chains, but which are only depended on by the agents codebase (rather than the contract as well). Chatted with @tkporter about this. - now fallbackprovider needs to be wrapped in a newtype struct for chain-specific trait implementations - If `Deref` is implemented for the newtype struct, all the function calls will still work (although using Deref for newtypes is [debatable](https://users.rust-lang.org/t/understanding-the-perils-of-deref/47958/18)) - the `request` function required by the `JsonRpcClient` still has some reusable logic but I left it there until it's clearer what can be reused by the cosmos fallback provider - the fallback provider unit tests still live in hyperlane-ethereum because of the logic in `require` ### Drive-by changes - needed to use `async-rwlock` instead of `tokio` for the `RwLock` structure used by the fallback provider for interior mutability. This is because the solana program requirements had rust pinned too far into the past for `tokio` to resolve to a version. ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/892 ### Backward compatibility Yes ### Testing Unit tests that were already there for the fallback provider
10 months ago
async-rwlock = "1.3"
auto_impl = "1.0"
axum = "0.6.1"
backtrace = "0.3"
base64 = "0.21.2"
bigdecimal = "0.4.2"
bincode = "1.3"
borsh = "0.9"
bs58 = "0.5.0"
bytes = "1"
clap = "4"
color-eyre = "0.6"
config = "0.13.3"
console-subscriber = "0.2.0"
convert_case = "0.6"
cosmrs = { version = "0.14", default-features = false, features = [
"cosmwasm",
"rpc",
"tokio",
"grpc",
] }
cosmwasm-std = "*"
crunchy = "0.2"
ctrlc = "3.2"
curve25519-dalek = { version = "~3.2", features = ["serde"] }
derive-new = "0.5"
derive_builder = "0.12"
Make merkle proofs optional on multisig ISM (#2173) ### Description Validators currently sign `(root, index)` checkpoints and during verification, a `message` is passed as calldata, an `id()` is derived, and a `proof` of `id()` at `index` in `root` is verified This provides “all or nothing” censorship resistance guarantees because a validator can only sign roots to allow any contained messages to be processed. We have considered alternatives where validators sign `message` directly and we lose censorship resistance in exchange for eliminating merkle proof verification gas costs. However, if validators sign `(root, index, message)` tuples, we can skip merkle proof verification on the destination chain while still maintaining censorship resistance by providing two valid metadata formats: 1. existing validator signatures and merkle proof verification of inclusion 2. including merkle proof verification for pathway where validators are censoring `message` It’s worth noting the validator is required to index event data to produce this new signature format. However, this does not require historical indexing and new validators being spun up can simply begin indexing from tip. See https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2187 for validator changes See https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2248 for relayer and e2e test changes ### Drive-by changes Merkle index also optional ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2192 ### Backward compatibility - new ISM deployment is necessary (we could upgrade implementation in theory) - Validator and relayer upgrades ### Testing Unit (fuzz) Tests, E2E tests
2 years ago
derive_more = "0.99"
feat: Relayer heap profiling (#4180) ### Description During the scalability audit we've identified relayer memory usage as a cause of concern. This PR runs the profiler each time e2e is run and outputs a report called `dhat-heap.json` in the current dir. That file can be visualised with a dhat viewer, such as the one hosted by the author [here](https://nnethercote.github.io/dh_view/dh_view.html). It adds a conditionally compiled heap memory profiler ([dhat-rs](https://docs.rs/dhat/latest/dhat/)), which is only included when both the `memory-profiling` feature is enabled and the `memory-profiling` cargo profile is used. The report can order the profiling results by total lifetime allocated bytes, peak allocated bytes, total allocation count, etc. Below is the result of sorting by total lifetime allocated bytes, which reveals that the biggest memory hogs are the hook indexing channel [senders](https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/rust/hyperlane-base/src/contract_sync/mod.rs#L52) (one per origin chain), taking up 100+ MB. Its size can most likely be reduced from 1M to 1k. ![Screenshot 2024-07-23 at 14 32 21](https://github.com/user-attachments/assets/f551ebfe-3ee0-40de-b53f-e5de1bc56dfa) ### Drive-by changes Adds the remaining IDs in the channel as a field to the hook indexing log, to know if it's safe to lower the channel size. ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/1293 ### Backward compatibility Yes, since everything is conditionally compiled / isolated in a new cargo profile. ### Testing Manual
4 months ago
dhat = "0.3.3"
ed25519-dalek = "~1.0"
eyre = "=0.6.8"
fixed-hash = "0.8.0"
fuels = "0.65.0"
fuels-code-gen = "0.65.0"
futures = "0.3"
futures-util = "0.3"
generic-array = { version = "0.14", features = ["serde", "more_lengths"] }
# Required for WASM support https://docs.rs/getrandom/latest/getrandom/#webassembly-support
bech32 = "0.9.1"
elliptic-curve = "0.12.3"
getrandom = { version = "0.2", features = ["js"] }
hex = "0.4.3"
http = "*"
hyper = "0.14"
hyper-tls = "0.5.0"
hyperlane-cosmwasm-interface = "=0.0.6-rc6"
injective-protobuf = "0.2.2"
injective-std = "=0.1.5"
Cosmos grpc fallbackprovider (#3139) ### Description Implements grpc fallback provider logic for cosmos - initially tried implementing the fallback provider deprioritization logic at middleware level like in the EVM. The difference between ethers and cosmrs is that in the latter, middleware can only live at the transport layer (`tower` crate level). - based on this github [issue](https://github.com/hyperium/tonic/issues/733), that actually doesn't look possible, because the http::Request type isn't `Clone` so it can't be submitted to multiple providers - ended up implementing the fallback provider at the application layer, by keeping an array of grpc channels - There is now a `call` method in `hyperlane_core::FallbackProvider` which I'm actually really happy with. This method handles the fallbackprovider-specific logic by taking in an async closure, running it on each provider, and iterating providers if the closure call fails. In `grpc.rs` you can see how this is slightly verbose but I think it's quite manageable. The only part that bugs me is having to duplicate `Pin::from(Box::from(future))`, but that's need afaict because the regular closure returns an anonymous type - adds `grpcUrls` and `customGrpcUrls` config items - tests the cosmos fallback provider e2e ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues - Fixes: https://github.com/hyperlane-xyz/issues/issues/998 ### 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 -->
10 months ago
itertools = "*"
jobserver = "=0.1.26"
jsonrpc-core = "18.0"
k256 = { version = "0.13.1", features = ["std", "ecdsa"] }
log = "0.4"
macro_rules_attribute = "0.2"
maplit = "1.0"
mockall = "0.11"
nix = { version = "0.26", default-features = false }
num = "0.4"
num-bigint = "0.4"
num-derive = "0.4.0"
num-traits = "0.2"
once_cell = "1.18.0"
parking_lot = "0.12"
paste = "1.0"
pretty_env_logger = "0.5.0"
primitive-types = "=0.12.1"
prometheus = "0.13"
protobuf = "*"
rand = "0.8.5"
regex = "1.5"
reqwest = "0.11"
ripemd = "0.1.3"
rlp = "=0.5.2"
rocksdb = "0.21.0"
sea-orm = { version = "0.11.1", features = [
"sqlx-postgres",
"runtime-tokio-native-tls",
"with-bigdecimal",
"with-time",
"macros",
] }
sea-orm-migration = { version = "0.11.1", features = [
"sqlx-postgres",
"runtime-tokio-native-tls",
] }
semver = "1.0"
serde = { version = "1.0", features = ["derive"] }
serde_bytes = "0.11"
serde_derive = "1.0"
serde_json = "1.0"
sha2 = { version = "0.10.6", default-features = false }
sha256 = "1.1.4"
sha3 = "0.10"
solana-account-decoder = "=1.14.13"
solana-banks-client = "=1.14.13"
solana-banks-interface = "=1.14.13"
solana-banks-server = "=1.14.13"
solana-clap-utils = "=1.14.13"
solana-cli-config = "=1.14.13"
solana-client = "=1.14.13"
solana-program = "=1.14.13"
solana-program-test = "=1.14.13"
solana-sdk = "=1.14.13"
solana-transaction-status = "=1.14.13"
solana-zk-token-sdk = "=1.14.13"
spl-associated-token-account = { version = "=1.1.2", features = [
"no-entrypoint",
] }
spl-noop = { version = "=0.1.3", features = ["no-entrypoint"] }
spl-token = { version = "=3.5.0", features = ["no-entrypoint"] }
spl-token-2022 = { version = "=0.5.0", features = ["no-entrypoint"] }
spl-type-length-value = "=0.1.0"
Better Agent Configuration Parsing (#2070) ### Description This is a significant change to how we parse user configs. The main goal of this PR is to give a clear path and env key to any errors that are encountered when parsing configuration. In order to accomplish this, I have crated a new trait `FromRawConf` which defines a set of steps to validate and convert individual fields. Also for every major config struct, there is now a `Raw*` variant of it which is used by the `config` library to reduce errors that occur during deserialization itself. `Raw*` types should always use the most basic form of a value, such as `String`, `StrOrInt`, `bool`, and ideally optional in all cases. Missing values should be handled during the raw conversion and not by `config`. I also needed to make changes to a number of types stored in the parsed config types to force validation forward to the parsing step instead of doing it when we read the config value. This also required me to create a filter to prevent trying to validate certain configs that we would not ever need to load. These changes can also be built on later to support something other than `config` if we choose to, or add support for merging configs from multiple sources since everything is optional. ### Drive-by changes - Default to `http` for connection type - Default to no gas payment enforcement if not specified instead of failing - `ChainSetup` -> `ChainConf` - `GasPaymentEnforcementConfig` -> `GasPaymentEnforcementConf` - Made ethereum connection configuration more forgiving - Moved hyperlane base settings from `mod.rs` to `base.rs` - Moved config chain tests in hyperlane core to `tests` dir to fix a cyclical import problem - Extension traits to help with config in hyperlane core - Moved `StrOrInt` to new hyperlane core `config` module - Support for parsing `U256` from `StrOrInt` - Removed `HexString` type which is now redundant - Updated base settings to use hyperlane domain - Use `heyKey` as signer type if `type` is not specified and `key` is - Moved hyperlane ethereum chain config to a new module ### Related issues - Fixes #2033 - Fixes #2012 ### Backward compatibility _Are these changes backward compatible?_ Yes - This should take in configs in the same shape but be more forgiving in a few places _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?_ Manual Unit Test
2 years ago
static_assertions = "1.1"
strum = "0.26.2"
strum_macros = "0.26.2"
tempfile = "3.3"
tendermint = "0.32.2"
tendermint-rpc = { version = "0.32.0", features = ["http-client", "tokio"] }
thiserror = "1.0"
time = "0.3"
tiny-keccak = "2.0.2"
tokio = { version = "1.4", features = ["parking_lot", "tracing"] }
tokio-metrics = { version = "0.3.1", default-features = false }
tokio-test = "0.4"
toml_edit = "0.19.14"
tonic = "0.9.2"
tracing = { version = "0.1" }
tracing-error = "0.2"
tracing-futures = "0.2"
tracing-subscriber = { version = "0.3", default-features = false }
Sequence-aware indexing refactor (#3262) ### Description Part 1 of an indexing refactor. This mostly focuses on the sequence-aware cursors. Changes: - Some renames, e.g. `SequenceIndexer` -> `SequenceAwareIndexer`, `sequence_and_tip` -> `latest_sequence_count_and_tip` - Moved cursors out of `contract_sync/cursor.rs` into `contract_sync/cursors/*` - The goal was to make the the Forward sequence-aware cursor, the Backward sequence-aware, and the ForwardBackward sequence aware cursors more resilient, easier to understand, and better tested. - General strategy for doing this was to: - Only move onto a new range to index if the logs passed into the cursor's `update` function justify this - If updated with any weird data, like gaps in logs, rewind the cursor and retry previously queried ranges I'd recommend starting the review in the following order: 1. `rust/hyperlane-base/src/contract_sync/cursors/sequence_aware/forward.rs` - where `ForwardSequenceAwareSyncCursor` & tests live 2. `rust/hyperlane-base/src/contract_sync/cursors/sequence_aware/backward.rs` - where `BackwardSequenceAwareSyncCursor` & tests live 3. `rust/hyperlane-base/src/contract_sync/cursors/sequence_aware/mod.rs` - where `ForwardBackwardSequenceAwareSyncCursor` lives ### 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 -->
9 months ago
tracing-test = "0.2.2"
typetag = "0.2"
uint = "0.9.5"
ureq = { version = "2.4", default-features = false }
Better Agent Configuration Parsing (#2070) ### Description This is a significant change to how we parse user configs. The main goal of this PR is to give a clear path and env key to any errors that are encountered when parsing configuration. In order to accomplish this, I have crated a new trait `FromRawConf` which defines a set of steps to validate and convert individual fields. Also for every major config struct, there is now a `Raw*` variant of it which is used by the `config` library to reduce errors that occur during deserialization itself. `Raw*` types should always use the most basic form of a value, such as `String`, `StrOrInt`, `bool`, and ideally optional in all cases. Missing values should be handled during the raw conversion and not by `config`. I also needed to make changes to a number of types stored in the parsed config types to force validation forward to the parsing step instead of doing it when we read the config value. This also required me to create a filter to prevent trying to validate certain configs that we would not ever need to load. These changes can also be built on later to support something other than `config` if we choose to, or add support for merging configs from multiple sources since everything is optional. ### Drive-by changes - Default to `http` for connection type - Default to no gas payment enforcement if not specified instead of failing - `ChainSetup` -> `ChainConf` - `GasPaymentEnforcementConfig` -> `GasPaymentEnforcementConf` - Made ethereum connection configuration more forgiving - Moved hyperlane base settings from `mod.rs` to `base.rs` - Moved config chain tests in hyperlane core to `tests` dir to fix a cyclical import problem - Extension traits to help with config in hyperlane core - Moved `StrOrInt` to new hyperlane core `config` module - Support for parsing `U256` from `StrOrInt` - Removed `HexString` type which is now redundant - Updated base settings to use hyperlane domain - Use `heyKey` as signer type if `type` is not specified and `key` is - Moved hyperlane ethereum chain config to a new module ### Related issues - Fixes #2033 - Fixes #2012 ### Backward compatibility _Are these changes backward compatible?_ Yes - This should take in configs in the same shape but be more forgiving in a few places _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?_ Manual Unit Test
2 years ago
url = "2.3"
walkdir = "2"
warp = "0.3"
which = "4.3"
ya-gcp = { version = "0.11.3", features = ["storage"] }
## TODO: remove this
cosmwasm-schema = "1.2.7"
[profile.release.package.access-control]
overflow-checks = true
[profile.release.package.account-utils]
overflow-checks = true
[profile.release.package.ecdsa-signature]
overflow-checks = true
[profile.release.package.hyperlane-sealevel-interchain-security-module-interface]
overflow-checks = true
[profile.release.package.hyperlane-sealevel-message-recipient-interface]
overflow-checks = true
[profile.release.package.multisig-ism]
overflow-checks = true
[profile.release.package.serializable-account-meta]
overflow-checks = true
[profile.release.package.hyperlane-sealevel-mailbox]
overflow-checks = true
[profile.release.package.hyperlane-sealevel-igp]
overflow-checks = true
[profile.release.package.hyperlane-sealevel-multisig-ism-message-id]
overflow-checks = true
[profile.release.package.hyperlane-sealevel-validator-announce]
overflow-checks = true
[workspace.dependencies.ethers]
features = []
git = "https://github.com/hyperlane-xyz/ethers-rs"
tag = "2024-04-25"
[workspace.dependencies.ethers-contract]
features = ["legacy"]
git = "https://github.com/hyperlane-xyz/ethers-rs"
tag = "2024-04-25"
[workspace.dependencies.ethers-core]
features = []
git = "https://github.com/hyperlane-xyz/ethers-rs"
tag = "2024-04-25"
[workspace.dependencies.ethers-providers]
features = []
git = "https://github.com/hyperlane-xyz/ethers-rs"
tag = "2024-04-25"
[workspace.dependencies.ethers-signers]
features = ["aws"]
git = "https://github.com/hyperlane-xyz/ethers-rs"
tag = "2024-04-25"
[patch.crates-io.curve25519-dalek]
branch = "v3.2.2-relax-zeroize"
git = "https://github.com/Eclipse-Laboratories-Inc/curve25519-dalek"
version = "3.2.2"
[patch.crates-io.ed25519-dalek]
branch = "main"
git = "https://github.com/Eclipse-Laboratories-Inc/ed25519-dalek"
version = "1.0.1"
[patch.crates-io.primitive-types]
branch = "hyperlane"
git = "https://github.com/hyperlane-xyz/parity-common.git"
version = "=0.12.1"
[patch.crates-io.rlp]
branch = "hyperlane"
git = "https://github.com/hyperlane-xyz/parity-common.git"
version = "=0.5.2"
[patch.crates-io.solana-account-decoder]
git = "https://github.com/hyperlane-xyz/solana.git"
tag = "hyperlane-1.14.13-2023-07-04"
version = "=1.14.13"
[patch.crates-io.solana-clap-utils]
git = "https://github.com/hyperlane-xyz/solana.git"
tag = "hyperlane-1.14.13-2023-07-04"
version = "=1.14.13"
[patch.crates-io.solana-cli-config]
git = "https://github.com/hyperlane-xyz/solana.git"
tag = "hyperlane-1.14.13-2023-07-04"
version = "=1.14.13"
[patch.crates-io.solana-client]
git = "https://github.com/hyperlane-xyz/solana.git"
tag = "hyperlane-1.14.13-2023-07-04"
version = "=1.14.13"
[patch.crates-io.solana-program]
git = "https://github.com/hyperlane-xyz/solana.git"
tag = "hyperlane-1.14.13-2023-07-04"
version = "=1.14.13"
[patch.crates-io.solana-sdk]
git = "https://github.com/hyperlane-xyz/solana.git"
tag = "hyperlane-1.14.13-2023-07-04"
version = "=1.14.13"
[patch.crates-io.solana-transaction-status]
git = "https://github.com/hyperlane-xyz/solana.git"
tag = "hyperlane-1.14.13-2023-07-04"
version = "=1.14.13"
[patch.crates-io.solana-zk-token-sdk]
git = "https://github.com/hyperlane-xyz/solana.git"
tag = "hyperlane-1.14.13-2023-07-04"
version = "=1.14.13"
[patch.crates-io.spl-associated-token-account]
branch = "hyperlane"
git = "https://github.com/hyperlane-xyz/solana-program-library.git"
version = "=1.1.2"
[patch.crates-io.spl-noop]
branch = "hyperlane"
git = "https://github.com/hyperlane-xyz/solana-program-library.git"
version = "=0.1.3"
[patch.crates-io.spl-token]
branch = "hyperlane"
git = "https://github.com/hyperlane-xyz/solana-program-library.git"
version = "=3.5.0"
[patch.crates-io.spl-token-2022]
branch = "hyperlane"
git = "https://github.com/hyperlane-xyz/solana-program-library.git"
version = "=0.5.0"
[patch.crates-io.spl-type-length-value]
version = "=0.1.0"
git = "https://github.com/hyperlane-xyz/solana-program-library.git"
branch = "hyperlane"
[patch.crates-io.tendermint]
branch = "trevor/0.32.2-fork"
git = "https://github.com/hyperlane-xyz/tendermint-rs.git"
version = "=0.32.2"
[patch.crates-io.tendermint-rpc]
branch = "trevor/0.32.2-fork"
git = "https://github.com/hyperlane-xyz/tendermint-rs.git"
version = "=0.32.2"