6 Commits (c53e3302b3c70c21cd0b620e8f2365d48c2ce289)

Author	SHA1	Message	Date
Danil Nemirovsky	ffbe1dd82e	feat: Make HyperlaneProvider to request block by height, not by hash (#4727) ... ### Description Make HyperlaneProvider to request block by height, not by hash. Since it is hard to find a block by hash for Solana, we switch to use block height. We have to do it for all type of chains since we need to change signature of chain-agnostic method ### Drive-by changes * Small method rename ### Related issues - Contributes into https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/4272 ### Backward compatibility Yes ### Testing Manual run of Scraper for Ethereum and Neutron chains. --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>	1 month ago
Daniel Savu	937392b61d	chore(evm): optimize block number fetching (#4736) ... ### Description Fix for leftover [comment](https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/4629#discussion_r1811084234) from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/4629 ### 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 month ago
Alexander Pastushenka	c3e9268f1e	feat: Add block tag support in `reorgPeriod` parameter (#4629) ... ### Description <!-- What's included in this PR? --> Allows setting an arbitrary string in `reorgPeriod`, which is used as a block tag to get the finalized block. Currently, only the Ethereum connector supports this feature with the following tags: - finalized - safe - pending - latest - earliest This is currently useful for EVM-compatible chains that don't have a fixed reorganization period, but instead rely on the block tag `Finalized` to indicate finality. For such chains, you should set `reorgPeriod` to `finalized` instead of a number of blocks. ### 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 --> Yes ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com>	1 month ago
Daniel Savu	8809f37271	feat: checkpoint syncer fraud flag (#4587) ... Upon detection of a merkle root mismatch between the local merkle tree (built from indexed events) and the onchain one, reorg diagnostic data is posted to checkpoint storage. This PR focuses on the submitter logic and leaves two things for a follow up PR: - adding logic to not spin up the validator if a fraud flag has been posted - integration testing with S3 and GCP I assume rolling out to validators will happen after the follow up PR, but running with logic from this PR will already mean the reorg diagnostic flag is posted to S3 (though not tested).	2 months ago
Trevor Porter	78d6fcf5aa	fix: cap agent EVM tx limit to the latest block gas limit (#4489) ... ### Description - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/4239 - I think ideally we'd maybe cache this, but there isn't a super accessible way of doing this atm and we need this ASAP to accommodate Everclear. So personally am happy to take on the extra RPC per transaction and at some point we'll likely want to revisit our tx submission efficiency, plus we end up needing the latest block for eip 1559 estimation anyways ### 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 -->	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