hyperlane-monorepo

Commit Graph

Author	SHA1	Message	Date
Lee	dcd78e916d	fix: use sender as bytes variables (#3252 ) ### Description Fixes the CCIP read json body to use the `sender_as_bytes` variable. This fixes the issue of truncated sender ### 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: Le Yu <leyu@Les-MacBook-Pro.fios-router.home> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>	10 months ago
Daniel Savu	f11878ad08	CCIP Read metadata builder fix (#3246 ) ### Description `H160`'s `ToString` implementation adds ellipsis points instead of outputting the full hex string, for some reason (e.g. `0xc66a…7b6f`). This will result in an error when `Mailbox.process` is called on the CCIP Read ISM. ### 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 -->	10 months ago
Trevor Porter	87151c62bf	Increase injective reorg period (#3247 ) ### Description Seeing some issues possibly related to querying for logs in a range that an RPC server doesn't know about yet. Increasing the reorg period from 1 to 10 to be extra conservative ### Drive-by changes rm'd the unused finalityBlocks from mainnet3_config.json ### 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 -->	10 months ago
Daniel Savu	3cbb06a07a	feat: fetch chain-specific metrics in standalone task (#3214 ) ### Description Spawning a tokio task to fetch chain-specific metrics in provider middleware was wasteful because we ended up with 15 tasks doing the same job. Now there is a single task that is spawned inside the relayer, which I added in the struct that used to only fetch relayer balance. Some questions: - I'm realising in the current state I'm probably removing these metrics from validators. Lmk if yes and I'll add back - the chain-specific metrics were moved out of `MiddlewareMetrics` because they're no longer part of middleware, but I wasn't sure where to place them. Maybe `CoreMetrics` is a better place than the current `custom_metrics.rs` file? `tokio-metrics` turned out not to be useful because we'd need to instrument every call site of `tokio::spawn` with it. We should still do it but as a separate task imo. ### Drive-by changes - This PR also makes it very easy to add the metrics tasks for new chains, by extending the `HyperlaneProvider` trait with a `get_chain_metrics` call which seems reasonably general to me to have implemented by all providers. (Bc we currently only track these for evm chains) - the description, naming and logic of the `gas_price` metric was also changed to support new chains ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3047 ### Backward compatibility Yes ### Testing Still need to manually test	10 months ago
Trevor Porter	473b43f001	Injective & inevm agents (#3155 ) ### Description - Deploys injective & inevm validators, adds them to the hyperlane context relayer, and starts scraping inevm ### 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: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: nambrot <nambrot@googlemail.com> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com>	10 months ago
Ivan Temchenko	65e2ea50f9	Google Cloud Storage CheckpointSyncer implementation (#3156 ) ### Description GSC builder and implementer classes; Documentation comments; Examples; Anonymous test on public bucket access; ### Drive-by changes `cargo doc` build fixes: * replaced square braces of non-existing items with `'` ; * raw URL surrounded by `<>`; ### Related issues Fixes #2242 Part 1 ### Backward compatibility Yes ### Testing Unit Tests	10 months ago
Yorke Rhodes	0ff3e2b171	Deploy injective and inEVM (#3140 ) ### Description - Deploy core to injective and inEVM networks ### Drive-by changes - Update cw-hyperlane dependency ### Backward compatibility Yes ### Testing - Fork tests - e2e tests --------- Co-authored-by: J M Rossy <jm.rossy@gmail.com> Co-authored-by: Trevor Porter <trkporter@ucdavis.edu> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>	10 months ago
Daniel Savu	f2a0e92c7f	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
Trevor Porter	d1621b49d0	Add Neutron back to mainnet3_config.json (#3220 ) ### Description Looks like https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-edae1a4e631a67121d92119998e37740c0190bec5060e3c842cc86e4d3d26a4dL417 removed Neutron from mainnet3_config.json :( Seems like the Typescript tooling may have overridden it accidentally? Will need to figure out what to do there ### Drive-by changes ### 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 -->	10 months ago
Huulu	3ea5dd7b66	chore(rust): proofreading (#3152 ) Came across few typos while browsing ./rust. One of them is an error message displayed to the user, rest are comments. Hope I could be of any help. Have a nice week-end Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com>	10 months ago
Yorke Rhodes	8fe24830ee	Deploy viction core and warp routes (#3067 ) ### Description Deploys core and warp to viction ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/850 - Fixes https://github.com/hyperlane-xyz/issues/issues/859 ### Backward compatibility Yes ### Testing Fork tests --------- Co-authored-by: J M Rossy <jm.rossy@gmail.com> Co-authored-by: Trevor Porter <trkporter@ucdavis.edu> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>	10 months ago
Daniel Savu	9e6146518f	fix: potential rate-limiting bugfix (#3191 ) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2586 ### 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
Kunal Arora	ff771351b8	feat:update deployments to use `FallbackRoutingHook` (#3179 ) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork	10 months ago
Trevor Porter	3bb4d87dda	Injective / inevm agent code & config changes (#3185 ) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### 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 -->	10 months ago
Daniel Savu	c9ef41c109	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
Paul Balaji	0e8e169311	feat: aws validator terraform example (#3170 )	10 months ago
Trevor Porter	6845f9f4b8	Fix parsing sequences of H256s in a matchinglist via agent settings (#3180 ) ### Description Upon trying to use a blacklist with an array of H256s as the `recipientAddress`, was getting a panic: ``` running 1 test parse_value: Array [Object {"destinationdomain": Number(11155111), "origindomain": Number(1399811151), "recipientaddress": Array [String("0x6AD4DEBA8A147d000C09de6465267a9047d1c217"), String("0x6AD4DEBA8A147d000C09de6465267a9047d1c218")], "senderaddress": Array [String("0x6AD4DEBA8A147d000C09de6465267a9047d1c217"), String("0x6AD4DEBA8A147d000C09de6465267a9047d1c218")]}] "Expected matching list" thread 'settings::matching_list::test::supports_sequence_h256s' panicked at 'called `Result::unwrap()` on an `Err` value: ConfigParsingError([(ConfigPath([]), Expected matching list Caused by: invalid type: string "0x6AD4DEBA8A147d000C09de6465267a9047d1c217", expected a borrowed string Location: /Users/trevor/abacus-monorepo/rust/hyperlane-base/src/settings/parser/json_value_parser.rs:259:14)])', agents/relayer/src/settings/matching_list.rs:473:60 stack backtrace: 0: rust_begin_unwind at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/panicking.rs:593:5 1: core::panicking::panic_fmt at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/panicking.rs:67:14 2: core::result::unwrap_failed at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/result.rs:1651:5 3: core::result::Result<T,E>::unwrap at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/result.rs:1076:23 4: relayer::settings::matching_list::test::supports_sequence_h256s at ./src/settings/matching_list.rs:473:9 5: relayer::settings::matching_list::test::supports_sequence_h256s::{{closure}} at ./src/settings/matching_list.rs:459:34 6: core::ops::function::FnOnce::call_once at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/ops/function.rs:250:5 7: core::ops::function::FnOnce::call_once at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/ops/function.rs:250:5 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. test settings::matching_list::test::supports_sequence_h256s ... FAILED ``` Honestly not too sure about the implications of this being a String vs &str ### 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 -->	10 months ago
Trevor Porter	0cad4f7407	Support cosmos contract byte lengths other than 32 (#3147 ) ### Description fixes #3143 Initially went down a path that would use protocol-specific types for addresses as suggested by #3143. I had made a `HyperlaneConnectionConf` enum with protocol-specific variants whose values were `addresses: CoreContractAddresses<ProtocolSpecificAddressType>` and `connection: ProtocolSpecificConnectionConf`. This worked pretty well until I hit the ISM logic. Because hyperlane-core is where the Mailbox trait is defined, the return type of `recipient_ism` in the trait cannot involve protocol specific types. It can't be moved to hyperlane-base because hyperlane-base imports the chain crates, so we'd have a cyclic dependency. I experimented with moving away from H256 to something like a Vec<u8> or string, but this felt a bit weird. In the end we decided to keep H256s as the global representation for contract addresses for now, with the intent of eventually changing this, and to support the varying length situation in a cosmos config ### Drive-by changes - Added some cosmos specific agent configurations into the sdk - Moved to bech32_prefix in the agents for consistency with what the SDK's chain metadata already does - I guess no one's ran cargo test in a while so vectors/message.json got a new v3 message lol ### Related issues Fixes #3143 ### Backward compatibility Changes prefix to bech32_prefix in the agent config, and now requires `contractAddressBytes` ### Testing Tested merged with #3144 and all worked --------- Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com>	10 months ago
Daniel Savu	528a19022b	Deploy eclipse testnet (#3172 ) ### 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 --> --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>	10 months ago
Trevor Porter	5b4af6bf1d	Injective-specific account info protobuf (#3144 ) ### Description Only change needed was to correctly handle the account info. Because we may want to handle injective testnet, added `is_injective` fn to HyperlaneDomain instead of just doing the match directly. Happy to import some of the longer fully qualified names instead ### 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 -->	10 months ago
Trevor Porter	ae4476ad09	Move to reorg period of 1 for mantapacific (#3126 ) ### Description - Moves to a reorg period of 1 for mantapacific instead of 0 - this should avoid the IGP indexing bugs we're seeing where we first get the latest block, then make an eth_getLogs RPC, but the node servicing the latter RPC doesn't yet know of the new latest block ### Drive-by changes Remove some duplication of the reorg period ### Related issues n/a ### Backward compatibility backward compatible ### Testing none yet, other than deploying	10 months ago
Paul Balaji	d3d7ad7f97	feat: add foundry and rosetta setup steps (#3134 )	11 months ago
Daniel Savu	80f1a5688e	fix: support TLS gRPC endpoints (#3122 ) ### Description Supporting TLS gRPC endpoints is as simple as enabling the `tonic` crate features in this PR. However to maintain compatiblity with the plaintext endpoints, we need to always use `http` instead of `https`, otherwise `tonic` will try to establish a TLS connection to them and fail. ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/893 ### Backward compatibility No, in the sense that all prior plaintext urls need to be changed from `https` to `http` ### Testing Manual	11 months ago
Daniel Savu	cdbaf9ef02	fix: dedup eth logs (#3108 ) ### Description Deduplicates ethereum logs by collecting them into a HashSet before returning a Vec. I couldn't find a way to deduplicate using an ethers config, but since `fetch_logs` is only called once in hyperlane-base, I'm doing the deduplication there "globally". I also noted in doc comments that duplicates may be returned. ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3070 ### Backward compatibility Yes ### Testing Will rely on e2e passing but haven't added unit tests for this scenario	11 months ago
Trevor Porter	3f88aa6f6e	Observability of validators for relayers (#3057 ) ### Description Goal of this was to have insight into validators of important sets being "up" Introduces a new metric used by relayers: `hyperlane_observed_validator_latest_index`, e.g.: ``` hyperlane_observed_validator_latest_index{agent="relayer",app_context="default_ism",destination="test1",hyperlane_baselib_version="0.1.0",origin="test2",validator="0x9965507d1a55bcc2695c58ba16fb37d819b0a4dc"} 664 hyperlane_observed_validator_latest_index{agent="relayer",app_context="default_ism",destination="test1",hyperlane_baselib_version="0.1.0",origin="test3",validator="0x976ea74026e726554db657fa54763abd0c3a0aa9"} 641 hyperlane_observed_validator_latest_index{agent="relayer",app_context="default_ism",destination="test2",hyperlane_baselib_version="0.1.0",origin="test1",validator="0x15d34aaf54267db7d7c367839aaf71a00a2c6a65"} 670 hyperlane_observed_validator_latest_index{agent="relayer",app_context="default_ism",destination="test2",hyperlane_baselib_version="0.1.0",origin="test3",validator="0x976ea74026e726554db657fa54763abd0c3a0aa9"} 665 hyperlane_observed_validator_latest_index{agent="relayer",app_context="default_ism",destination="test3",hyperlane_baselib_version="0.1.0",origin="test1",validator="0x15d34aaf54267db7d7c367839aaf71a00a2c6a65"} 652 hyperlane_observed_validator_latest_index{agent="relayer",app_context="default_ism",destination="test3",hyperlane_baselib_version="0.1.0",origin="test2",validator="0x9965507d1a55bcc2695c58ba16fb37d819b0a4dc"} 664 hyperlane_observed_validator_latest_index{agent="relayer",app_context="testapp",destination="test1",hyperlane_baselib_version="0.1.0",origin="test2",validator="0x9965507d1a55bcc2695c58ba16fb37d819b0a4dc"} 658 hyperlane_observed_validator_latest_index{agent="relayer",app_context="testapp",destination="test1",hyperlane_baselib_version="0.1.0",origin="test3",validator="0x976ea74026e726554db657fa54763abd0c3a0aa9"} 641 ``` Tapping into metadata building for multisig ISMs, the relayer will update the metric with the latest indices for the validators in a set. In order to prevent the cardinality being ridiculously high, only certain validator sets are tracked. This is done by introducing an `app_context` label (I'm very open to other names here, for some reason whenever idk how to name some kind of identifier I end up calling it a context 😆) The app context can either be: - if a new setting, --metricAppContexts, is specified, a message will be classified based off the first matching list it matches. E.g. `--metricAppContexts '[{"name": "testapp", "matchingList": [{"recipient_address": "0xd84379ceae14aa33c123af12424a37803f885889", "destination_domain": 13371 }] }]'`. This is nice for e.g. warp route deployments, where the ISM is maybe not a default ISM, and can be changed - if a message doesn't get classified this way, it can also be classified with the "default_ism" app context, which is just for any message that happens to use the default ISM as its "root" ISM This way we have insight in to the default ISM and any application-specific ISMs. Some things to note: - it's possible for a message to actually have more than one validator set, e.g. if it's using an aggregation ISM. In this case, we'll have metrics on the union of all validator sets for that app context - Some effort is required to make sure that metrics don't stick around for a validator that has actually been removed from the set. To handle this, we cache the validator set for an app context and clear out the entire set each time we set the metrics ### Drive-by changes - Zod's nonempty function for strings is deprecated, moves to `.min(1)` instead ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/1762 ### Backward compatibility yes ### Testing Ran locally - I think i'll probably add something in e2e tests, but opening now	11 months ago
Trevor Porter	2b49baab02	Bump neutron gas price (#3096 ) ### Description Updates the neutron gas price to be slightly above the min that was recently updated :\| https://github.com/cosmos/chain-registry/blob/master/neutron/chain.json#L20 Deployed the Neutron relayer to include our recent changes that allow for the gas price to be easily configured ### 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 -->	11 months ago
Daniel Savu	c2cf7be8f2	feat(cosmos): ism dry-run (#3077 ) ### Description Implements `dry_run_verify` for the aggregation ISM on cosmwasm. One remaining issue is that the estimated gas is hardcoded to `1`, because we're actually [just querying](`37fea49429/contracts/isms/aggregate/src/lib.rs (L108)`) via rpc rather than simulating a tx. The `verify` tx isn't marked as a contract [entrypoint](https://book.cosmwasm.com/basics/entry-points.html) so it can't be called from outside iiuc. (here's the [verify](`37fea49429/contracts/isms/aggregate/src/lib.rs (L124)`) fn for reference). Worth mentioning that the query interface for the aggregation ISM is named incorrectly - it should return fields called `threshold` and `modules`, but instead copies the response from the multisig ISM and returns `threshold` and `validators`. This can be particularly misleading because validators have 20-bytes long addresses, whereas modules (contracts) have 32-bytes long addresses. ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/807 ### Backward compatibility yes ### Testing E2E. The ISM setup is `routing` -> `aggregation (1/1)` -> `multisig (1/1)`	11 months ago
Daniel Savu	f73ee0b273	last round of PR remediations (#2791 ) Remediations for https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2746, in addition to https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2780	11 months ago
Daniel Savu	d18f7ae8e1	Cosmos gas price config (#3042 ) ### Description Adds a cosmos-specific config item for setting the minimum gas price, in the format returned by the `cosmos.base.node.v1beta1.Service/Config` cosmos-sdk grpc endpoint. ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/810 ### Backward compatibility No. Will break existing cosmos configs. ### Testing None yet, will test in e2e	11 months ago
Daniel Savu	8e44bc1b81	feat: sealevel merkle indexer + e2e (#3053 ) Depends on https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3048 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3046 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2754	11 months ago
Daniel Savu	1f651b7afc	chore: remove neutron-related deployments from testnet4 context (#3071 ) ### Description Removes most occurences of lines that contain the `neutron` string from the testnet4 context. Where validators are set (e.g. [here](`3e685f9fb0/typescript/infra/config/environments/testnet4/validators.ts (L29)`)), the neutron context is required for type safety but can stay empty	12 months ago
Daniel Savu	42ea929785	Sealevel v3 contracts (#3048 ) ### Description MVP contracts for sealevel v3 - note this doesn't include hooks so IGP payments still have to be made separately. However contracts will now be compatible with the metadata format used by the other V3 deployments. ### Drive-by changes The unit tests in `rust/sealevel/programs/ism/multisig-ism-message-id/src/metadata.rs` are refactored to reuse struct creation logic. ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3044 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3045 ### Backward compatibility No, since this upgrades sealevel v2 to v3. ### Testing Unit tests	12 months ago
Nam Chu Hoai	a888cf7ce9	Actually default to none policy (#2921 ) (#3058 ) ### Description Cherry-picks #2921 which got merged into the wrong branch	12 months ago
Daniel Savu	86b7f98850	fix: cosmos balance parsing (#3036 ) @tkporter reported that cosmos balance strings were being interpreted as hex when parsed, causing them to appear much larger. This fixes by parsing as decimal. Tested manually by checking the metrics endpoint.	12 months ago
Daniel Savu	36de5bcc3c	chore: reduce agents log verbosity, reword (#3026 ) 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.	12 months ago
Daniel Savu	98bb228a96	Sealevel balance metrics (#3025 ) 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	12 months ago
Daniel Savu	77aa58c581	Relayer balance metrics (#2976 ) 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 https://github.com/hyperlane-xyz/issues/issues/701 Closes https://github.com/hyperlane-xyz/issues/issues/702 (because the balance becomes available in the metrics endpoint for polling)	12 months ago
Trevor Porter	ffd4de4110	Use new ethers-rs version that should work with BSC (#3000 ) ### Description Uses a version of our ethers fork with https://github.com/hyperlane-xyz/ethers-rs/pull/10, which adds back a change that I had reverted from https://github.com/hyperlane-xyz/ethers-rs/pull/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	1 year ago
Trevor Porter	c2288eb317	Update ethers-rs with polygon gas oracle fix (#2998 ) ### Description Update to latest ethers-rs (forked) version with https://github.com/hyperlane-xyz/ethers-rs/pull/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	1 year ago
Nam Chu Hoai	68d4f2f149	Infra for neutron & neutrontestnet (#2869 ) ### 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 --> --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>	1 year ago
ByeongSu Hong	50aed86517	fix: change domain id of cosmos localnet to random (#2977 ) ### Description We, Mitosis team will be using 26657 as the chain id, so it's good to change 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 -->	1 year ago
Trevor Porter	9b8ad55a6a	Update ethers-rs to use lower max priority fee (#2986 ) ### Description Cherry-picked the commit from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2903, which is now out of date ### Drive-by changes n/a ### Related issues n/a ### Backward compatibility yes ### Testing we're running the relayer with an image off of https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2903 Co-authored-by: -f <kunalarora1729@gmail.com>	1 year ago
Trevor Porter	1cebc39182	Use Polygon gas oracle (#2965 ) ### Description After investigating #2959, I found the following this is a known problem with Polygon, explanation here https://github.com/ethers-io/ethers.js/issues/2828#issuecomment-1283014250 Fun fact Asa looked into this once https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/771 Here's a discussion it in Foundry, which I found hoping that ethers-rs folks had ran into this before https://github.com/foundry-rs/foundry/issues/1703 Foundry fixed this by using the Polygon gas station oracle which seems to be recommended path https://github.com/foundry-rs/foundry/pull/3368/files#diff-c89a4bbf7a90da118dcf00c5fe70eba78f8e5d95662bb5f039a353113e95042bR205 There's actually a polygon ethers middleware for this https://docs.rs/ethers/latest/ethers/middleware/gas_oracle/polygon/struct.Polygon.html So I (originally) borrowed this code from Foundry https://github.com/foundry-rs/foundry/blob/master/crates/common/src/provider.rs#L254-L290 Changed to use Middlewares This also means we can remove our existing janky Polygon logic ### 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 -->	1 year ago
Trevor Porter	ece2be507a	Cosmos / CosmWasm agents (#2865 ) ### 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 --> --------- Co-authored-by: Mattie Conover <git@mconover.dev> Co-authored-by: hashableric <hashableric@gmail.com> Co-authored-by: byeongsu-hong <hong@byeongsu.dev> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>	1 year ago
Trevor Porter	c41345c64f	1k block chunk for scroll indexing (#2956 ) ### Description RPC URLs on scroll max out at 1k ### 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 -->	1 year ago
J M Rossy	00a91f8e68	Main-to-v3 update and V3 CLI (#2818 ) ### Description - Merge latest main into v3, including notably the new CLI package. - Update CLI code for V3 ### Drive-by changes Housekeeping of package.json files ### Related issues Fixes #2811 ### Testing Manual and CI test updates --------- Co-authored-by: Kunal <kunalarora1729@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>	1 year ago
Nam Chu Hoai	87796e2ac0	Set a default gas policy (#2830 ) ### Description When no gas enforcement policy is set, by default, we should apply None --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>	1 year ago
Nam Chu Hoai	e4eed2ae3d	fix: e2e working with aggregation 2/2 of `message_id` and `merkle_root` (#2861 ) ### Description - Removed the double mapping logic from the the `merkle_tree_builder.get_proof()` for fixing the following issue: > `get_proof` was expecting a nonce which it then uses to retrieve the `leaf_index` i.e. nonce -> message_id -> leaf_index and then `prove_against_previous` but in our case, we already got the leaf_index in merkle_tree_multisig.rs so what we end up doing is trying to look up the leaf_index twice and either not finding the message_id or proving wrong leaf_index which both causes the "cannot fetch metadata" for the merkle tree builder ### Drive-by changes - additional logging for aggregation to indicate which ism (moduleType, address) we are missing - trace -> debug logging for `sign_and_submit_checkpoint` ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/695 ### Backward compatibility Yes ### Testing e2e --------- Co-authored-by: -f <kunalarora1729@gmail.com> Co-authored-by: Kunal Arora <55632507+aroralanuk@users.noreply.github.com>	1 year ago
Yorke Rhodes	136e7c8d32	Fix validator checkpoint syncer latest index (#2858 ) Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2856	1 year ago
Kunal Arora	c44fd29914	Deploy contracts to mainnet3 (#2826 ) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>	1 year ago

1 2 3 4 5 ...

797 Commits (3283eefd6d870390c0f957e35449557c2151209c)