feat: zksync verification classes [ZK-003]#22
feat: zksync verification classes [ZK-003]#22ljankovic-txfusion wants to merge 259 commits intofeat/zksync-deployment-functionsfrom
Conversation
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…ne-xyz#5468) ### Description - More frequent retries for the first ~30 mins, meant to accommodate the upcoming CCIP ISM which is known to take ~25 mins on some origins After this change: ``` Retry #0: cumulative duration from beginning is 0:0:0, since last attempt is 0:0:0 Retry #1: cumulative duration from beginning is 0:0:0, since last attempt is 0:0:10 Retry #2: cumulative duration from beginning is 0:0:10, since last attempt is 0:0:10 Retry #3: cumulative duration from beginning is 0:0:20, since last attempt is 0:0:10 Retry #4: cumulative duration from beginning is 0:0:30, since last attempt is 0:0:10 Retry #5: cumulative duration from beginning is 0:0:40, since last attempt is 0:0:10 Retry #6: cumulative duration from beginning is 0:0:50, since last attempt is 0:0:10 Retry #7: cumulative duration from beginning is 0:1:0, since last attempt is 0:0:10 Retry #8: cumulative duration from beginning is 0:1:10, since last attempt is 0:0:10 Retry #9: cumulative duration from beginning is 0:1:20, since last attempt is 0:0:10 Retry #10: cumulative duration from beginning is 0:1:30, since last attempt is 0:1:30 Retry #11: cumulative duration from beginning is 0:3:0, since last attempt is 0:1:30 Retry #12: cumulative duration from beginning is 0:4:30, since last attempt is 0:1:30 Retry #13: cumulative duration from beginning is 0:6:0, since last attempt is 0:1:30 Retry #14: cumulative duration from beginning is 0:7:30, since last attempt is 0:1:30 Retry #15: cumulative duration from beginning is 0:9:0, since last attempt is 0:2:0 Retry #16: cumulative duration from beginning is 0:11:0, since last attempt is 0:2:0 Retry #17: cumulative duration from beginning is 0:13:0, since last attempt is 0:2:0 Retry #18: cumulative duration from beginning is 0:15:0, since last attempt is 0:2:0 Retry #19: cumulative duration from beginning is 0:17:0, since last attempt is 0:2:0 Retry #20: cumulative duration from beginning is 0:19:0, since last attempt is 0:2:0 Retry #21: cumulative duration from beginning is 0:21:0, since last attempt is 0:2:0 Retry #22: cumulative duration from beginning is 0:23:0, since last attempt is 0:2:0 Retry #23: cumulative duration from beginning is 0:25:0, since last attempt is 0:2:0 Retry #24: cumulative duration from beginning is 0:27:0, since last attempt is 0:2:0 Retry #25: cumulative duration from beginning is 0:29:0, since last attempt is 0:3:0 Retry #26: cumulative duration from beginning is 0:32:0, since last attempt is 0:4:30 Retry #27: cumulative duration from beginning is 0:36:30, since last attempt is 0:6:0 Retry #28: cumulative duration from beginning is 0:42:30, since last attempt is 0:7:30 Retry #29: cumulative duration from beginning is 0:50:0, since last attempt is 0:9:0 Retry #30: cumulative duration from beginning is 0:59:0, since last attempt is 0:10:30 Retry hyperlane-xyz#31: cumulative duration from beginning is 1:9:30, since last attempt is 0:12:0 Retry hyperlane-xyz#32: cumulative duration from beginning is 1:21:30, since last attempt is 0:13:30 Retry hyperlane-xyz#33: cumulative duration from beginning is 1:35:0, since last attempt is 0:15:0 Retry hyperlane-xyz#34: cumulative duration from beginning is 1:50:0, since last attempt is 0:16:30 Retry hyperlane-xyz#35: cumulative duration from beginning is 2:6:30, since last attempt is 0:18:0 Retry hyperlane-xyz#36: cumulative duration from beginning is 2:24:30, since last attempt is 0:19:30 Retry hyperlane-xyz#37: cumulative duration from beginning is 2:44:0, since last attempt is 0:21:0 Retry hyperlane-xyz#38: cumulative duration from beginning is 3:5:0, since last attempt is 0:22:30 Retry hyperlane-xyz#39: cumulative duration from beginning is 3:27:30, since last attempt is 0:24:0 Retry hyperlane-xyz#40: cumulative duration from beginning is 3:51:30, since last attempt is 0:30:0 Retry hyperlane-xyz#41: cumulative duration from beginning is 4:21:30, since last attempt is 0:30:0 Retry hyperlane-xyz#42: cumulative duration from beginning is 4:51:30, since last attempt is 0:30:0 Retry hyperlane-xyz#43: cumulative duration from beginning is 5:21:30, since last attempt is 0:30:0 Retry hyperlane-xyz#44: cumulative duration from beginning is 5:51:30, since last attempt is 0:30:0 Retry hyperlane-xyz#45: cumulative duration from beginning is 6:21:30, since last attempt is 1:0:0 Retry hyperlane-xyz#46: cumulative duration from beginning is 7:21:30, since last attempt is 1:0:0 Retry hyperlane-xyz#47: cumulative duration from beginning is 8:21:30, since last attempt is 1:0:0 Retry hyperlane-xyz#48: cumulative duration from beginning is 9:21:30, since last attempt is 1:0:0 Retry hyperlane-xyz#49: cumulative duration from beginning is 10:21:30, since last attempt is 1:0:0 Retry hyperlane-xyz#50: cumulative duration from beginning is 11:21:30, since last attempt is 2:38:56 Retry hyperlane-xyz#51: cumulative duration from beginning is 14:0:26, since last attempt is 8:6:55 Retry hyperlane-xyz#52: cumulative duration from beginning is 22:7:21, since last attempt is 8:24:34 Retry hyperlane-xyz#53: cumulative duration from beginning is 30:31:55, since last attempt is 12:32:21 Retry hyperlane-xyz#54: cumulative duration from beginning is 43:4:16, since last attempt is 15:56:31 Retry hyperlane-xyz#55: cumulative duration from beginning is 59:0:47, since last attempt is 15:29:51 Retry hyperlane-xyz#56: cumulative duration from beginning is 74:30:38, since last attempt is 14:13:18 Retry hyperlane-xyz#57: cumulative duration from beginning is 88:43:56, since last attempt is 16:55:33 Retry hyperlane-xyz#58: cumulative duration from beginning is 105:39:29, since last attempt is 22:51:56 Retry hyperlane-xyz#59: cumulative duration from beginning is 128:31:25, since last attempt is 23:20:42 Retry hyperlane-xyz#60: cumulative duration from beginning is 151:52:7, since last attempt is 24:5:0 Retry hyperlane-xyz#61: cumulative duration from beginning is 175:57:7, since last attempt is 26:51:36 Retry hyperlane-xyz#62: cumulative duration from beginning is 202:48:43, since last attempt is 30:55:26 Retry hyperlane-xyz#63: cumulative duration from beginning is 233:44:9, since last attempt is 32:33:46 Retry hyperlane-xyz#64: cumulative duration from beginning is 266:17:55, since last attempt is 33:58:37 Retry hyperlane-xyz#65: cumulative duration from beginning is 300:16:32, since last attempt is 35:31:14 Retry hyperlane-xyz#66: cumulative duration from beginning is 335:47:46, since last attempt is 38:37:22 Retry hyperlane-xyz#67: cumulative duration from beginning is 374:25:8, since last attempt is 36:1:47 Retry hyperlane-xyz#68: cumulative duration from beginning is 410:26:55, since last attempt is 42:42:1 Retry hyperlane-xyz#69: cumulative duration from beginning is 453:8:56, since last attempt is 42:7:4 Retry hyperlane-xyz#70: cumulative duration from beginning is 495:16:0, since last attempt is 47:45:25 Retry hyperlane-xyz#71: cumulative duration from beginning is 543:1:25, since last attempt is 47:20:15 Retry hyperlane-xyz#72: cumulative duration from beginning is 590:21:40, since last attempt is 50:42:29 Retry hyperlane-xyz#73: cumulative duration from beginning is 641:4:9, since last attempt is 50:36:53 Retry hyperlane-xyz#74: cumulative duration from beginning is 691:41:2, since last attempt is 53:25:8 Retry hyperlane-xyz#75: cumulative duration from beginning is 745:6:10, since last attempt is 54:32:25 Retry hyperlane-xyz#76: cumulative duration from beginning is 799:38:35, since last attempt is 55:46:58 Retry hyperlane-xyz#77: cumulative duration from beginning is 855:25:33, since last attempt is 59:21:28 Retry hyperlane-xyz#78: cumulative duration from beginning is 914:47:1, since last attempt is 58:47:29 Retry hyperlane-xyz#79: cumulative duration from beginning is 973:34:30, since last attempt is 63:38:16 Retry hyperlane-xyz#80: cumulative duration from beginning is 1037:12:46, since last attempt is 64:29:15 Retry hyperlane-xyz#81: cumulative duration from beginning is 1101:42:1, since last attempt is 66:44:38 Retry hyperlane-xyz#82: cumulative duration from beginning is 1168:26:39, since last attempt is 67:13:25 Retry hyperlane-xyz#83: cumulative duration from beginning is 1235:40:4, since last attempt is 71:38:16 Retry hyperlane-xyz#84: cumulative duration from beginning is 1307:18:20, since last attempt is 70:59:58 Retry hyperlane-xyz#85: cumulative duration from beginning is 1378:18:18, since last attempt is 73:16:27 Retry hyperlane-xyz#86: cumulative duration from beginning is 1451:34:45, since last attempt is 75:50:17 Retry hyperlane-xyz#87: cumulative duration from beginning is 1527:25:2, since last attempt is 80:23:55 Retry hyperlane-xyz#88: cumulative duration from beginning is 1607:48:57, since last attempt is 81:41:11 Retry hyperlane-xyz#89: cumulative duration from beginning is 1689:30:8, since last attempt is 83:48:29 Retry hyperlane-xyz#90: cumulative duration from beginning is 1773:18:37, since last attempt is 82:24:16 Retry hyperlane-xyz#91: cumulative duration from beginning is 1855:42:53, since last attempt is 88:31:19 Retry hyperlane-xyz#92: cumulative duration from beginning is 1944:14:12, since last attempt is 88:53:21 Retry hyperlane-xyz#93: cumulative duration from beginning is 2033:7:33, since last attempt is 91:55:18 Retry hyperlane-xyz#94: cumulative duration from beginning is 2125:2:51, since last attempt is 90:38:51 Retry hyperlane-xyz#95: cumulative duration from beginning is 2215:41:42, since last attempt is 96:53:4 Retry hyperlane-xyz#96: cumulative duration from beginning is 2312:34:46, since last attempt is 96:9:40 Retry hyperlane-xyz#97: cumulative duration from beginning is 2408:44:26, since last attempt is 99:26:42 Retry hyperlane-xyz#98: cumulative duration from beginning is 2508:11:8, since last attempt is 98:48:58 Retry hyperlane-xyz#99: cumulative duration from beginning is 2607:0:6, since last attempt is 102:43:45 ``` Before: ``` 0: cumulative duration from beginning is 0:0:0, since last attempt is 0:0:0 1: cumulative duration from beginning is 0:0:0, since last attempt is 0:0:10 2: cumulative duration from beginning is 0:0:10, since last attempt is 0:0:10 3: cumulative duration from beginning is 0:0:20, since last attempt is 0:0:10 4: cumulative duration from beginning is 0:0:30, since last attempt is 0:0:10 5: cumulative duration from beginning is 0:0:40, since last attempt is 0:0:10 6: cumulative duration from beginning is 0:0:50, since last attempt is 0:0:10 7: cumulative duration from beginning is 0:1:0, since last attempt is 0:0:10 8: cumulative duration from beginning is 0:1:10, since last attempt is 0:0:10 9: cumulative duration from beginning is 0:1:20, since last attempt is 0:0:10 10: cumulative duration from beginning is 0:1:30, since last attempt is 0:0:10 11: cumulative duration from beginning is 0:1:40, since last attempt is 0:0:10 12: cumulative duration from beginning is 0:1:50, since last attempt is 0:1:30 13: cumulative duration from beginning is 0:3:20, since last attempt is 0:3:0 14: cumulative duration from beginning is 0:6:20, since last attempt is 0:4:30 15: cumulative duration from beginning is 0:10:50, since last attempt is 0:6:0 16: cumulative duration from beginning is 0:16:50, since last attempt is 0:7:30 17: cumulative duration from beginning is 0:24:20, since last attempt is 0:9:0 18: cumulative duration from beginning is 0:33:20, since last attempt is 0:10:30 19: cumulative duration from beginning is 0:43:50, since last attempt is 0:12:0 20: cumulative duration from beginning is 0:55:50, since last attempt is 0:13:30 21: cumulative duration from beginning is 1:9:20, since last attempt is 0:15:0 22: cumulative duration from beginning is 1:24:20, since last attempt is 0:16:30 23: cumulative duration from beginning is 1:40:50, since last attempt is 0:18:0 24: cumulative duration from beginning is 1:58:50, since last attempt is 0:30:0 25: cumulative duration from beginning is 2:28:50, since last attempt is 0:30:0 26: cumulative duration from beginning is 2:58:50, since last attempt is 0:30:0 27: cumulative duration from beginning is 3:28:50, since last attempt is 0:30:0 28: cumulative duration from beginning is 3:58:50, since last attempt is 0:30:0 29: cumulative duration from beginning is 4:28:50, since last attempt is 0:30:0 ``` ### 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 -->
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
…' into feat/zksync-verification-classes
ltyu
left a comment
There was a problem hiding this comment.
Pretty big but manageable PR. mostly looks good on my end, but will take one more look and test out.
some notes for myself for another review:
- compared BaseContractVerifier to the original ContractVerifier. most fns have no diffs.
- abstract functions are implemented in the child classes
|
|
||
| const explorerApi = this.multiProvider.tryGetExplorerApi(chain); | ||
|
|
||
| await sleep( |
There was a problem hiding this comment.
why is this needed, and why only for etherscan? whats the difference of sleeping here and also in submitForm()
There was a problem hiding this comment.
on etherscan, it took a while after contract deployment that etherscan servers can notify that this contract is deployed
so we wait a bit then request for verification.
on others did not have any problem when request for instant verification after deployment.
There was a problem hiding this comment.
On submit form we wait for verification but here we wait for explorer to scan recently deployed contract. as the way explorers work is scanning blockchain and storing data on DB, this would be required here.
…lane-xyz#5874) ### Description feat(cosmos-sdk): use prebuilt simapp image for docker-compose - create pipeline that can be manually triggered to create new `hyperlane-cosmos-simapp` images - use prebuilt simapp image in docker-compose to save time pulling before e2e ### 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 ci - https://github.com/hyperlane-xyz/hyperlane-monorepo/actions/runs/14361666216 --------- Co-authored-by: Troy Kessler <troy.kessler99@gmail.com>
…' into feat/zksync-verification-classes
…z#5931) ### Description This PR adds the proxyAdmin.owner to the Checker ownerOverrides such that it checks proxyAdmin.owner instead of the top-level owner. This is needed for edge cases where we have proxyAdmin owner that is different than the top-level owner. For example `LUMIA/arbitrum-avalanche-base-bsc-ethereum-lumiaprism-optimism-polygon` has not transferred their proxyAdmin.owner ### Backward compatibility Yes - only checks if proxyAdmin is explicitly supplied. ### Testing Manual, tested by rebasing ontop of another [PR](hyperlane-xyz#5886) which reads an offending config (LUMIA/arbitrum-avalanche-...) from the registry
### Description - Moving to `aws-sdk-s3` instead of rusoto for all S3 operations. We still require rusoto for KMS - Moved to a static set of S3 clients that are used globally for all anonymous S3 operations. Clients are region specific so there are some ugly types. I preferred the static set to minimize how invasive this change is - Some context here https://hyperlaneworkspace.slack.com/archives/C08GR6PBPGT/p1744561237142619?thread_ts=1744392583.189179&cid=C08GR6PBPGT - Web Identity support is still there despite it being deleted, see https://docs.aws.amazon.com/sdk-for-rust/latest/dg/credproviders.html and https://docs.rs/aws-config/latest/aws_config/web_identity_token/index.html#environment-variable-configuration ### Drive-by changes - sets `resolver = "2"`. This resulted in some slightly different compile warnings / errors due to various features now being activated or not activated ### 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 - I tested locally with my local prepares but tbh there isn't a nice way of testing functionality in e2e or unit tests with a lot of this. So I'll roll out to RC cautiously
… from the registry and checks them (hyperlane-xyz#5864) ### Description This PR updates check-warp-deploy to fetch all warp route configurations from the registry and checks them. ### Drive-by changes ### Related issues - Fixes hyperlane-xyz#5242 ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
### Description Contains following changes: - New `MetadataBuildError` when the MultiSig contains more than `50` validators - Fetch metadata in S3 buckets and check for size constraints first (50KiB) - Stricter S3 Request Timeout when fetching objects (30s -> 10s) - Parallelized checkpoint fetching logic: - Use `1-10` workers to fetch signatures for one checkpoint index <!-- What's included in this PR? --> ### Drive-by changes None <!-- Are there any minor or drive-by changes also included? --> ### Related issues [Github](hyperlane-xyz/issues#401) - [Linear](https://linear.app/hyperlane-xyz/issue/BACK-130/pre-tge-fixes-for-known-dos-vectors-are-documented-known) Also includes https://linear.app/hyperlane-xyz/issue/BACK-146/make-multisigcheckpointsyncerget-validator-latest-checkpoints-and <!-- - 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 Wrote a unit test for ensuring the logic stays the same. Can be executed with ``` cargo test --package hyperlane-base --lib -- types::multisig::test::test_s3_checkpoint_syncer --exact --show-output ``` <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
### Description This PR compresses the size of Starknet logo ### Drive-by changes None ### Related issues None ### Backward compatibility Yes ### Testing None
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or [setup this action to publish automatically](https://github.com/changesets/action#with-publishing). If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @hyperlane-xyz/starknet-core@13.0.0 ### Major Changes - f8696c7: feat: Add Starknet contract ABI fetching and contract artifact generation ## @hyperlane-xyz/cosmos-sdk@13.0.0 ### Minor Changes - 2724559: add cosmos native routing ism cosmos-sdk and types ### Patch Changes - Updated dependencies [2724559] - @hyperlane-xyz/cosmos-types@13.0.0 ## @hyperlane-xyz/cosmos-types@13.0.0 ### Minor Changes - 2724559: add cosmos native routing ism cosmos-sdk and types ## @hyperlane-xyz/sdk@13.0.0 ### Minor Changes - 72b90f8: add cosmos native core module & reader - bc58283: feat: Starknet SDK logic integration - 2724559: add cosmos native routing ism cosmos-sdk and types ### Patch Changes - Updated dependencies [0de63e0] - Updated dependencies [f8696c7] - Updated dependencies [2724559] - @hyperlane-xyz/utils@13.0.0 - @hyperlane-xyz/starknet-core@13.0.0 - @hyperlane-xyz/cosmos-sdk@13.0.0 - @hyperlane-xyz/core@7.1.6 ## @hyperlane-xyz/utils@13.0.0 ### Minor Changes - 0de63e0: Add Starknet address and tx utils ## @hyperlane-xyz/core@7.1.6 ### Patch Changes - Updated dependencies [0de63e0] - @hyperlane-xyz/utils@13.0.0 ## @hyperlane-xyz/helloworld@13.0.0 ### Patch Changes - Updated dependencies [72b90f8] - Updated dependencies [bc58283] - Updated dependencies [2724559] - @hyperlane-xyz/sdk@13.0.0 - @hyperlane-xyz/core@7.1.6 ## @hyperlane-xyz/widgets@13.0.0 ### Patch Changes - 1a7222b: Compress Starknet logo - Updated dependencies [72b90f8] - Updated dependencies [bc58283] - Updated dependencies [0de63e0] - Updated dependencies [2724559] - @hyperlane-xyz/sdk@13.0.0 - @hyperlane-xyz/utils@13.0.0 - @hyperlane-xyz/cosmos-sdk@13.0.0 ## @hyperlane-xyz/cli@13.0.0 ## @hyperlane-xyz/infra@13.0.0 ### Patch Changes - Updated dependencies [72b90f8] - Updated dependencies [bc58283] - Updated dependencies [0de63e0] - Updated dependencies [2724559] - @hyperlane-xyz/sdk@13.0.0 - @hyperlane-xyz/utils@13.0.0 - @hyperlane-xyz/helloworld@13.0.0 ## @hyperlane-xyz/ccip-server@13.0.0 ## @hyperlane-xyz/github-proxy@13.0.0 --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…#6266) ### Description fix: special-case mac in fetch-contracts-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 - ubuntu test is fine https://github.com/hyperlane-xyz/hyperlane-monorepo/actions/runs/15111483420/job/42471852313?pr=6266#step:4:13 - macos test is fine https://github.com/hyperlane-xyz/hyperlane-monorepo/actions/runs/15111483420/job/42471853847?pr=6266#step:4:13 - windows test is fine https://github.com/hyperlane-xyz/hyperlane-monorepo/actions/runs/15111483420/job/42471854670?pr=6266#step:4:13
…ne-xyz#6254) ### Description chore: update print-latest-checkpoints to support all 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 tested with forma, which is not in the core supported chains list but we can read checkpoints for now! <img width="1429" alt="image" src="https://github.com/user-attachments/assets/8eec18a1-177c-4f28-a635-370433d80e52" />
### Description Add `MIRAI/abstract-bsc-solanamainnet` token config and program IDs. ### Drive-by changes N/A ### Backward compatibility Yes ### Testing N/A --------- Co-authored-by: xeno097 <xeno097.cp@gmail.com>
### Description This PR adds USDC to subtensor ### Testing checker
…e-xyz#6268) ### Description Avoid holding lock on nonce manager with a remote call. Now we are using internal mutability to update the number of non finalized transactions in nonce manager ### Backward compatibility Yes ### Testing None Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues - Fixes hyperlane-xyz#6147 ### 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: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description fix: storage diff-check ### 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 chore: depot docker recommendations - update dockerfiles based on the depot recommendations ### 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 - [x] ci - [x] monorepo image on keyfunder - [x] agent image on rc
- use [turbo](https://turbo.build/repo/docs) for faster build times - automatic build task scheduling/dependency ordering - automatic build caching - faster build times - see turbo docs for more info - better integration with depot cache - use depot's turbo cache https://depot.dev/docs/cache/reference/turbo - use more depot runners to speed up recovery of yarn-build-with-cache action - depot runners will make use of depot's caching backend over github-native or buildjet
### Description This PR finally adds support for Cosmos Native Core Init, Read, Deploy & Apply. Note that this is the fifth and last PR of hyperlane-xyz#6050 which is being split up in order to make it easier to review ### Drive-by changes - ### Related issues - ### Backward compatibility Yes ### Testing Manual Tests
### Description hyperlane-xyz#6144 made relayer initialization very slow. It creates a signing provider within nested for loops, spending quadratic time (based on chain count) to create message contexts. At 110 chains and 200ms per network call that's ~40 mins (`110*110*200/(1000*60)`). since the origin and destination chains are identical in the relayer, the first commit optimizes this by only initializing the provider in the upper for-loop, making it linear. This got us down to ~30s of initialization overhead added by the ccip read initialization. the second commit moves out the provider building out of the for loops and just awaits the futures in parallel. AWS KMS rate limits shouldn't be a concern since it's just `chain_count` calls. After releasing to RC, the initialization overhead dropped to near zero see the three logs [here](https://cloudlogging.app.goo.gl/H7LmsVr5hgzJSSdk7) for performance comparison: - first log is without the CCIP-read feature (30 sec baseline) - second log is with linear provider building (60 sec, so 30s overhead) - third log is with the parallelized provider building (30 sec, back to the baseline) ### 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 require ssl for connection ### Testing Manual
### Description Applies changes from hyperlane-xyz/ethers-rs#35 - tested on Base and we now pay 80x less
…yperlane-xyz#6242) ### Description - update monitor image to include new token standard handling
### Description This PR fixes the token metadata handling by changing the return type of `deriveTokenMetadata` to TokenMetadataMap`, enabling support for multiple different token metadata. ### Drive-by changes - `assertWarpRouteConfig` expects the mailbox address to verify the correct deployed mailbox. - remove `./test-configs/anvil/deployments` before running e2e-tests ### Backward compatibility Yes ### Testing Added E2E test to verify that for `collateralFiat` and `collateral` with two different metadata, token is deployed with two different metadata. --------- Co-authored-by: Morteza Shojaei <morteza@txfusion.io>
…erlane-xyz#6298) ### Description Scraper is failing to index some message dispatches due to obsolete Solana SDK we are using. We pinned the dependency version to 1.14.13. Since then enum `TransactionError` added a few enum invariants. New tag of the Solana SDK dependencies brings these invariants from upstream. ### Backward compatibility Yes ### Testing Tested with experimental image Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### 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 chore: reduce release-e2e-matrix frequency - previously we would run the release cli test matrix if there were no changesets - no changesets _implied_ that a release is to be done, but in cases where packages are published but no new publishable changes have landed yet - we're still churning through these tests for no good reason - this PR changes the behaviour such that we always try and do prepare-release so that the Changesets PR is updated, but we also in parallel check if the _current_ package versions are published and only run the tests if we detect that there are packages that need to be published ### 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 tested here https://github.com/hyperlane-xyz/hyperlane-monorepo/actions/runs/15161126534  
### Description Required fields on EVM transaction are overwritten when we estimate gas price in EVM adapter for Lander. It means that these fields are not set when transaction is submitted into a chain. This change ensures that all the required fields are copied from old transaction to the new one during gas price estimations. E2E tests do not pass with fields set, so, we use classical submitter for the time being. ### Backward compatibility Yes ### Testing E2E test Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description Upgrade Scraper to 197fd87-20250521-144619. ### Backward compatibility Yes ### Testing Tested in hyperlane Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description This PR adds support for ZKSync contract verification with custom compiler options. Key changes include: - Added `ZKSyncContractVerifier` class to handle ZKSync-specific contract verification - Extended `PostDeploymentContractVerifier` to support ZKSync explorer family - Added ZKSync-specific compiler options and types - Implemented constructor arguments retrieval for ZKSync contracts - Added utility functions for ZKSync contract verification [PR to feat/zksync-deployment-functions](txfusion#22) ### Drive-by changes - Refactored contract verification classes to better support different types of verifications - Extracted common verification logic into `BaseContractVerifier` - Added verification delay times for different explorer families - Improved error handling and logging for verification processes ### Related issues https://linear.app/hyperlane-xyz/issue/ENG-1152 ### Backward compatibility Yes - These changes are backward compatible. The existing contract verification functionality for other chains refactored with same interface. ### Testing Build passing --------- Co-authored-by: Morteza Shojaei <31728528+mortezashojaei@users.noreply.github.com> Co-authored-by: ljankovic-txfusion <131957285+ljankovic-txfusion@users.noreply.github.com> Co-authored-by: ljankovic-txfusion <lazar@txfusion.io> Co-authored-by: Le Yu <6251863+ltyu@users.noreply.github.com> Co-authored-by: Paul Balaji <10051819+paulbalaji@users.noreply.github.com>
Description
This PR adds support for ZKSync contract verification with custom compiler options. Key changes include:
ZKSyncContractVerifierclass to handle ZKSync-specific contract verificationPostDeploymentContractVerifierto support ZKSync explorer familyDrive-by changes
BaseContractVerifierRelated issues
N/A
Backward compatibility
Yes - These changes are backward compatible. The existing contract verification functionality for other chains refactored with same interface.
Testing
Build passing