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/.gitignore

9 lines
105 B

target
validatordb
relayerdb
kathydb
hyperlane_db
Refactor IGP related code out of HyperlaneCore (#1907) ### Description A number of changes intended to make the SDK more easily consumed by hyperlane-deploy - Splits the IGP related code out of HyperlaneCore* into HyperlaneIgp* - Moves agent config building from infra to SDK so that it can be accessed by hyperlane-deploy - Modifies CoreConfig to specify a ChainMap<MultisigIsmConfig> (i.e. specify everything that you need to know to deploy to a chain in that chain's CoreConfig) - Removes core.extendWithConnectionClientConfig - Moves common logic into HyperlaneAppGovernor to be shared between HyperlaneCoreGovernor and HyperlaneIgpGovernor - Adds TestRecipient contract addresses to the SDK addresses for consumption by hyperlane-deploy - Allow buildContracts to build when address keys are a superset of factory keys (via filterContracts). This is useful as it allows us to just throw all the addresses at a HyperlaneApp constructor without needing to remove the ones that aren't relevant - Removes InterchainGasCalculator, the logic we want to keep now lives in HyperlaneIgp - Allows chains to be added to a MultiProvider ### Drive-by changes - Merges the infra govern script into the check script (to dedupe) - Some minor renaming where "Core" was being used liberally - Default to using whatever is configured in `owners.ts` in the router configs for infra (for ICA, IQS, HelloWorld, and LL deployment) ### Related issues - Fixes #[issue number here] ### Backward compatibility _Are these changes backward compatible?_ No, existing consumers of the SDK may need to adjust. _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 Tests
2 years ago
config/test_config.json
feat: add dry-run support for warp deploy + gas stats (#3586) ### Description * New feature to allow users to dry-run the warp deploy script against a forked (base/origin) network of their choice * To run: `yarn build && yarn hyperlane deploy warp --dry-run` || `yarn build && yarn hyperlane deploy warp -d` * Externally enables: `hyperlane deploy warp --dry-run` || `hyperlane deploy warp -d` * Also adds gas usage util for both warp & core deployments in all contexts, e.g. * When running a vanilla core deploy, for example, between alfajores and fuji, you will now see: ``` ⛽️ Gas Usage Statistics - Gas required for core deploy on alfajores: 0.0058686745 CELO - Gas required for core deploy on fuji: 0.0239308515 AVAX ``` ### Drive-by changes * None ### Related issues * Fixes https://github.com/hyperlane-xyz/issues/issues/819 ### Backward compatibility * Yes ### Testing * Note: `hl` == `yarn build && yarn hyperlane`. The below tests are only a sample and are not inclusive. #### Manual Testing * With `anvil` NOT running in separate instance: * `hl deploy warp -d` * Throws: ``` Error: No active anvil node detected. Please run `anvil` in a separate instance. ``` * With `anvil` running in separate instance: * `hl deploy warp -d -k c0052e22df5d1f4ae7c51e254Xx00Xx0eb833453eaed6301xXxxx8a30d92d10a` (any private key) * Throws `Error: Invalid address length. Please ensure you are passing an address and not a private key.` * `hl deploy warp -d -k 0x16F4898F47c085C41d7Cc6b1dc0xX0xXX017dcBb` (any public address) * Output: ``` 🔎 Verifying anvil node is running... ✅ Successfully verified anvil node is running Using warp route deployment config at ./configs/warp-route-deployment.yaml No chain config file provided ? Do you want to use some core deployment address artifacts? This is required for PI chains (non-core chains). no Forking alfajores for dry-run... ✅ Successfully forked alfajores for dry-run Impersonating account (0x16F4898F47c085C41d7Cc6b1dc72B91EA617dcBb)... ✅ Successfully impersonated account (0x16F4898F47c085C41d7Cc6b1dc72B91EA617dcBb) ... ✅ Hyp token deployments complete Writing deployment artifacts Deployment is complete! Contract address artifacts are in artifacts/dry-run_warp-route-deployment-2024-04-16-12-27-02.json Warp config is in artifacts/dry-run_warp-config-2024-04-16-12-27-02.json ⛽️ Gas Usage Statistics - Gas required for warp dry-run on alfajores: 0.013310162514578124 CELO Resetting forked network... ✅ Successfully reset forked network ✅ Warp dry-run completed successfully ``` #### CI Testing * Successful CI-backed integration/regression testing via `ci-test.sh`
7 months ago
validator_db_anvil*
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-heap*