hyperlane-monorepo

Commit Graph

Author	SHA1	Message	Date
Danil Nemirovsky	c064881727	feat: Scraper populates transaction fields for Solana (#4801 ) ### Description Scraper populates transaction fields for Solana ### Related issues - Contributes into https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/4272 ### Backward compatibility Yes (configuration is updated) ### Testing Manual test of Scraper Run E2E tests for Ethereum and Solana --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>	3 weeks ago
Danil Nemirovsky	14e4719f00	feat: Use H512 as transaction hash in HyperlaneProvider and Scraper (#4759 ) ### Description Use H512 as transaction hash in HyperlaneProvider and Scraper. ### Related issues - Contributes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/4272 ### Backward compatibility Yes ### Testing Manual run of Scraper for Ethereum and Neutron --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>	1 month ago
Daniel Savu	ad4d61f962	chore: agave 2.x validator in sealevel e2e (#4643 ) ### Description Solana Mainnet is hard forking in 1-2 weeks and one of the RPC methods we were using will be removed. This PR updates that RPC and runs e2e with an agave `v2.x` network to ensure compatibility. As in the [svm warp route guide](https://docs.hyperlane.xyz/docs/guides/deploy-svm-warp-route), we still use `v1.14.x` to compile programs. More details: - `v2.0` migration [guide](https://github.com/anza-xyz/agave/wiki/Agave-v2.0-Transition-Guide) - `v2.0` release [schedule](https://github.com/anza-xyz/agave/wiki/v2.0-Release-Schedule) - `solana` to `agave` client transition [guide](https://github.com/anza-xyz/agave/wiki/Agave-Transition) ### Drive-by changes The solana cli installer logic in e2e is parameterized with `version` and `url` ### Backward compatibility Yes - no dependency upgrade was needed to switch to the new rpc method ### Testing E2E for general network compatiblity. The Jito submission retry logic (where the new rpc is used) wasn't tested - I'm confident it works but this is non-critical, as failed submission will eventually end up in the prep queue again	2 months ago
Danil Nemirovsky	e490e77445	feat: Generate Cosmos address for Injective (#4618 ) ### Description Injective uses different logic compared to Neutron and Osmosis to generate account addresses from public key. It is implemented in this PR so that sender address is correctly generated from signer info of transaction. Depending on the type of public key communicated in the transaction, we shall generate either Bitcoin-like or Ethereum-like address for Injective. We can also specify the type of account id for the signer. Bitcoin-like will be chosen by default, so, we don't need to change the configuration of Relayer. ### Drive-by changes Made some errors to be warnings. We'll add metrics to measure how frequent the issues are and decide how to fix them: 1. transaction contains multiple contract execution messages 2. transaction contains fees in unsupported denominations Made Scraper to refrain from recording transaction which it cannot parse properly. ### Backward compatibility Yes ### Testing Added unit tests Manual testing with Injective blockchain --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>	2 months ago
Paul Balaji	3c819c777e	revert: "feat: Generate cosmos account addresses for Injective" (#4615 ) Reverts hyperlane-xyz/hyperlane-monorepo#4576 context: https://discord.com/channels/935678348330434570/1291354470730436680/1291357041624875010 > The problem is that Injective supports both "normal cosmos" signing with the bitcoin style address, and also ethereum style addresses. They disambiguate depending on the type of the pubkey that's signed in the tx > The relayer signs things using a bitcoin style address on Injective bc this was easier than making code changes to have it do ethereum-style (which isn't supported easily out of the box with the cosmos libs we use) > So we want the relayer account balance metric to look at the bitcoin-style address relating to our relayer key, not the Ethereum-style one at least this is the theory behind what happened	2 months ago
Danil Nemirovsky	22871425d6	feat: Dispatch messages before and after start of the agents (#4604 ) ### Description Dispatch messages before and after start of the agents so that we test both forward and backward looking sequence based indexers. ### Related issues - Successfully scrape Cosmos chains in e2e test #3355 ### Backward compatibility Yes ### Testing - E2E Cosmos Test - Manual check on E2E Cosmos Test logs --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>	2 months ago
Danil Nemirovsky	6e787a9b39	feat: Generate cosmos account addresses for Injective (#4576 ) ### Description Injective uses different logic on generating account addresses from public key. It is implemented in this PR so that sender address is correctly generated from signer info of transaction. ### Backward compatibility Yes ### Testing Added unit tests Manual testing with Injective blockchain --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>	2 months ago
Danil Nemirovsky	5cb1787044	feat: E2E Test Cosmos Scraper Invariant (#4536 ) ### Description - Add metrics based Scraper invariant into E2E Test for Cosmos - Report error if transaction contains multiple contract execution messages - Report error if fee are expressed in unsupported denomination ### Related issues - Successfully scrape Cosmos chains in e2e test #3355 ### Backward compatibility Yes ### Testing E2E Testing --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>	2 months ago
Paul Balaji	1ab8751afb	fix: docker agent build (#4481 ) fix: docker agent build - update image from 1.72.1 -> 1.80.1 drive-by: update more `rust/` --> `rust/main/` drive-by: consolidate e2e non-cosmwasm cache, multiple cache steps per job can get in the way of each other --------- Signed-off-by: pbio <10051819+paulbalaji@users.noreply.github.com>	3 months ago
Mantas-M	096aeff13e	feat: Splitting `rust` workspace into `main` and `sealevel` (#4438 ) ### Description The single rust workspace has been split into 2 workspaces. The sealevel workspace includes the contents of the previous `sealevel` folder and the main workspace includes everything else. The workspaces differ in rust versions as the sealevel has the old one to ensure compatability, the main workspace has and updated `rustc` version of `1.80.1`. Some dependencies and sub-dependencies have been locked in versions of the old pre-split workspace to ensure no breaking code changes. The rust CI workflow has been updated to include both workspaces in the tests. ### Drive-by changes N/A ### Related issues Relates to https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/4361 ### Backward compatibility No. ### Testing Rust Unit tests from the CI	3 months ago

10 Commits (3ce70725ee62069272f6de51987fbc8a4b1ee7d6)