hyperlane-monorepo

Commit Graph

Author	SHA1	Message	Date
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	7dccf80b57	feat: do not start up validator if fraud was reported (#4627 ) ### Description Builds on top of https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/4587 Adds a check in the `CheckpointSubmitter` builder which emits a panic if a reorg flag was posted, since this potentially signals fraud ### Drive-by changes `CheckpointSubmitter::build` was made private, so any use of it is now replaced by the `build_and_submit` flow ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility Yes ### Testing Unit Tests - which is enough as long as `CheckpointSubmitter::build` is kept private	2 months 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
Daniel Savu	e2b5a4c785	feat: HyperlaneDb trait (#4609 ) ### Description Defines a `HyperlaneDb` trait for use in the validator submitter, so a mock can be passed in to simulate indexed data from reorged state. Although the `HyperlaneDb` trait can't be `Clone` to be object safe, as long as we use `Arc`s everywhere, all will be ok. Eventually the aim is to replace all direct usage of `HyperlaneRocksDb` with `Arc<dyn HyperlaneDb>`.	2 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	2 months ago

5 Commits (250853eff406565f9c0d33e914b0e3b75228294c)