hyperlane-monorepo

Commit Graph

Author	SHA1	Message	Date
Yorke Rhodes	46f5311a95	Init immutable mailbox v3 and native hooks Simplify mailbox and make interfaces payable Update version constant Keep message ID events	1 year ago
Alex	da25b06254	CCIP Read ISM (#2398 ) ### Description CCIP Read ISM implementation, - [x] Contracts - [x] Relayer - [x] Example HTTP backend ### Drive-by changes _Are there any minor or drive-by changes also included?_ ### Related issues - Fixes #[2211] ### Backward compatibility _Are these changes backward compatible?_ Yes, relayers will skip messages they can't handle. _Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling?_ Yes, relayers won't be able to submit messages that have a CCIP Read ISM. ### Testing _What kind of testing have these changes undergone?_ - [x] Manual - [x] Unit Tests ### General approach - [x] Get a basic [CCIP Read implementation working](https://github.com/AlexBHarley/permissionless-chainlink-feeds/tree/main/contracts) - [x] Build a [mock service that serves CCIP Read compatible data](https://github.com/AlexBHarley/permissionless-chainlink-feeds/tree/main/apps/api) - [x] Update the Relayer to support CCIP Read ISMs	1 year ago
Kunal Arora	d69a3f639a	No metadata relayer support for hooks (#2495 ) ### Description - Adding `NoMetadataRelayer` moduleType which returns an empty `vec![]` on `MetadataBuilder::build()` - Adding `HyperlaneHookDeployer` which lets you deploy the hook, ISM and a testRecipient which specifies to use the `AbtractNativeISM` ### Drive-by changes - none ### Related issues - Accompanies #2316 - Fixes https://github.com/hyperlane-xyz/issues/issues/379 for Optimism - Related to adding native hooks to Mailbox V3 https://github.com/hyperlane-xyz/issues/issues/486 ### Backward compatibility Backward compatible? Yes Tooling changes needed? Need to update node to ^18 ### Testing - Manual on testnet3	1 year ago
Kunal Arora	445da4fb0d	Adding Optimism native bridge support (#2316 ) ### Description - Adds support for the native Optimism bridge (L1->L2) to send messageID to be verified by the custom ISM on the rollup. - Only the smart contract component. - Outside Mailbox and needs to be called separately. - Uses Openzeppelin's CrossChainEnabled pattern for ensuring the right cross chain sender address. ### Drive-by changes - None ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/379 - Opens https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2409 - Related to https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2381 ### Backward compatibility - Needs modifying the relayer to read OptimismISM's storage to wait for `receivedEmitters` mapping to get updated before retrying `process` on the mailbox. ### Testing - Unit Tests with Foundry forks and Optimism's L1-L2 messenger contracts. --------- Co-authored-by: Asa Oines <asaoines@gmail.com>	1 year ago
Yorke Rhodes	50f04db1fa	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
Asa Oines	f8d645e580	Add RoutingIsm (#1985 ) ### Description This PR adds `IRoutingIsm` and three implementations: - AbstractRoutingIsm, which folks building RoutingIsms can inherit from - DomainRoutingIsm, which routes based on message origin - InterchainAccountIsm, which routes based on the ISM in the InterchainAccountMessage ### Drive-by changes - Some related testing changes ### Related issues - Fixes #1521 ### Backward compatibility _Are these changes backward compatible?_ Yes _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?_ Unit Tests	2 years ago
Yorke Rhodes	55f40ad760	Merge audit v2 remediation to main (#1727 ) ### Description Merge [`audit-v2`](https://github.com/hyperlane-xyz/hyperlane-monorepo/releases/tag/audit-v2) into `main` See [changelog](`034e75b632`...audit-v2)	2 years ago
Asa Oines	63558af85d	Use interfaces in agents (#2022 ) ### Description Move agents to use contract interfaces artifacts rather than the artifacts themselves. This ensures we don't anything that we can't guarantee is in every implementation of that interface. Particularly relevant for IGPs and ISMs. ### Drive-by changes - Moves `solidity/interfaces` to `solidity/contracts/interfaces` so that their artifacts can be used in `update_abis.sh` ### Related issues - #1757 ### Backward compatibility _Are these changes backward compatible?_ Yes _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?_ None	2 years ago

8 Commits (46f5311a95d4871b525ab899af546d8771598566)