Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V3 agents rebase #2746

Merged
merged 65 commits into from
Oct 4, 2023
Merged

V3 agents rebase #2746

merged 65 commits into from
Oct 4, 2023

Conversation

daniel-savu
Copy link
Contributor

Description

It's your favourite PR coming right back... V3 agents!

Closes https://github.com/hyperlane-xyz/issues/issues/561

Builds on top of #2742

Depends on #2681 for e2e testing

This PR includes:

  • Merkle tree hook indexer
  • Merkle tree builder task
  • Update submitter to trigger retries if no proof is available yet

Slightly more detailed overview of the work here: #2720 (comment)

Drive-by changes

Related issues

Backward compatibility

Testing

@daniel-savu
Copy link
Contributor Author

Doesn't compile yet though

@codecov
Copy link

codecov bot commented Sep 21, 2023

Codecov Report

Merging #2746 (863ecfd) into v3 (a60ec18) will increase coverage by 0.56%.
The diff coverage is 0.00%.

Additional details and impacted files
@@            Coverage Diff             @@
##               v3    #2746      +/-   ##
==========================================
+ Coverage   63.92%   64.49%   +0.56%     
==========================================
  Files          97       97              
  Lines         973      966       -7     
  Branches      101      100       -1     
==========================================
+ Hits          622      623       +1     
+ Misses        314      307       -7     
+ Partials       37       36       -1     
Components Coverage Δ
core 51.61% <ø> (ø)
hooks 67.93% <ø> (ø)
isms 68.65% <ø> (+0.74%) ⬆️
token 84.84% <ø> (ø)
middlewares 73.17% <ø> (ø)

daniel-savu and others added 13 commits October 3, 2023 17:37
Continues the updates to the rust config shapes by updating deployment
and runtime expectations. This PR also attempts to rely on the new
single source of truth created by the schema in the SDK as much as
reasonably possible which helped delete more code but also give some
guarantees of consistency.

THIS IS A BREAKING CHANGE! It changes the config shapes the agents want
and we should not merge this until we are ready.

Fixes #2215

---------

Co-authored-by: Guillaume Bouvignies <[email protected]>
Co-authored-by: Yorke Rhodes <[email protected]>
Co-authored-by: Guillaume Bouvignies <[email protected]>
@@ -28,3 +28,4 @@ yarn-error.log
**/*.ignore
.vscode

tsconfig.editor.json
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whats this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added by @mattiecnvr afaik

rust/agents/relayer/src/error.rs Outdated Show resolved Hide resolved
Comment on lines -53 to -58
/// Nonce was not found in DB, despite batch providing messages after
#[error("Nonce was not found {nonce:?}")]
UnavailableNonce {
/// Root of prover's local merkle tree
nonce: u32,
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we dont need this anymore?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

didn't find any uses of it

rust/hyperlane-base/src/db/rocks/hyperlane_db.rs Outdated Show resolved Hide resolved
@@ -76,6 +77,8 @@ pub struct CoreContractAddresses {
pub interchain_gas_paymaster: H256,
/// Address of the ValidatorAnnounce contract
pub validator_announce: H256,
/// Address of the MerkleTreeHook contract
pub merkle_tree_hook: Option<H256>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if this is None?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be none if there's no deployment. The agents default to querying the mailbox for the merkle tree count in this case (e.g. in sealevel)

rust/chains/hyperlane-ethereum/src/mailbox.rs Show resolved Hide resolved
rust/chains/hyperlane-ethereum/src/mailbox.rs Show resolved Hide resolved
rust/chains/hyperlane-ethereum/tests/signer_output.rs Outdated Show resolved Hide resolved
rust/chains/hyperlane-ethereum/tests/signer_output.rs Outdated Show resolved Hide resolved
Comment on lines +137 to +139
// TODO: if `SequenceIndexer` turns out to not depend on `Indexer` at all, then the supertrait
// dependency could be removed, even if the builder would still need to return a type that is both
// ``SequenceIndexer` and `Indexer`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we be tracking this somewhere? I'm not sure I understand all the implications @tkporter

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we do get around to revamping indexing, this will certainly be addressed one way or another. But I think it's low prio for now

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 this 100% needs refactoring at some point but it is a big undertaking

I'd probably put this in the realm of #2313

rust/agents/relayer/src/error.rs Outdated Show resolved Hide resolved
rust/agents/relayer/src/error.rs Outdated Show resolved Hide resolved
rust/agents/relayer/src/merkle_tree/builder.rs Outdated Show resolved Hide resolved
rust/agents/relayer/src/merkle_tree/builder.rs Outdated Show resolved Hide resolved
rust/agents/relayer/src/merkle_tree/processor.rs Outdated Show resolved Hide resolved
rust/agents/relayer/src/merkle_tree/processor.rs Outdated Show resolved Hide resolved
@@ -195,7 +194,7 @@ mod test {
test_utils::run_test_db(|db| async move {
let hyperlane_db =
HyperlaneRocksDB::new(&HyperlaneDomain::new_test_domain("test_no_match"), db);
let matching_list = serde_json::from_str(r#"[{"originDomain": 234}]"#).unwrap();
let matching_list = serde_json::from_str(r#"[{"origindomain": 234}]"#).unwrap();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this necessary? assuming this is from Mattie's config change but curious if this implies that originDomain doesn't work anymore

Copy link
Contributor Author

@daniel-savu daniel-savu Oct 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what this tests is whether the config is robust against casing inconsistencies and that originDomain will still work

rust/agents/relayer/src/msg/metadata/base.rs Show resolved Hide resolved
rust/agents/relayer/src/msg/metadata/base.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@tkporter tkporter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd definitely say all the lag block number stuff is not critical to change immediately btw, just should do it at some point

rust/agents/relayer/src/processor.rs Show resolved Hide resolved
.map(|v| v.into())
.collect::<Vec<_>>()
.try_into()
.unwrap();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we be unwrapping? dunno if this was there before - if it was, worth checking if we can easily remove, but if we can't then nbd

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the unwrap is safe here. It's required because although we're iterating over elements of a fixed-size array ([u8; 32]), collect can only produce a collection that implements FromIterator - which isn't the case for fixed-size arrays because an iterator has no knowledge about how many items it's iterating over. So we need the try_into() to convert the Vec<H256> into [H256; 32]. Alternative would be

        let mut branch: [H256; 32] = [Default::default(); 32];
        raw_tree
            .branch
            .iter()
            .enumerate()
            .for_each(|(index, v)| branch[index] = v.into());

This code can still panic with an out-of-bounds access if raw_tree.branch exceeds 32, and would probably be less obvious to debug than with the unwrap version. I'd prefer leaving as-is and adding a comment, what's your take?

.saturating_sub(lag)
.into();

// TODO: implement From<Tree> for IncrementalMerkle
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may not wanna do this because the Tree type is ethereum-specific and we should avoid leaking types like that into vm-agnostic code

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isnt this the ethereum crate?

Copy link
Collaborator

@tkporter tkporter Oct 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was originally saying this bc IncrementalMerkle is in hyperlane-core and this would require adding hyperlane-ethereum as a dependency to hyperlane-core (which imo we can't do), but maybe we could instead just do Into<IncrementalMerkle> for Tree inside hyperlane-ethereum

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

implemented inside the merkle tree hook module (this same file) since that's where it's used

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw that comment was already there. in general I kept the merkle tree code intact but it's good we get to revisit these

rust/chains/hyperlane-sealevel/src/mailbox.rs Show resolved Hide resolved
let ctx = "Building merkle tree hook";
// TODO: if the merkle tree hook is set for sealevel, it's still a mailbox program
// that the connection is made to using the pda seeds, which will not be usable.
let address = self
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like the silently different behavior tbh

I think we should make merkle_tree_hook mandatory for now, and just change Sealevel in the JSON configs to specify the Mailbox address as the merkleTreeHook

Eventually I could see us wanting to make hooks in general optional, but that feels out of the scope of what this PR should do

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just flagging that even though we have dummy implementations for the merkle tree indexers on sealevel, we won't be covering sealevel in e2e so panics could still occur

rust/utils/run-locally/src/invariants.rs Show resolved Hide resolved
@daniel-savu daniel-savu enabled auto-merge (squash) October 4, 2023 18:14
@daniel-savu daniel-savu merged commit af5bd88 into v3 Oct 4, 2023
@daniel-savu daniel-savu deleted the v3-agents-rebase branch October 4, 2023 18:42
@daniel-savu daniel-savu mentioned this pull request Oct 5, 2023
tkporter added a commit that referenced this pull request Oct 6, 2023
### Description

Part of the remediations from
#2746

---------

Co-authored-by: Trevor Porter <[email protected]>
yorhodes pushed a commit that referenced this pull request Oct 10, 2023
### Description

Part of the remediations from
#2746

---------

Co-authored-by: Trevor Porter <[email protected]>
@yorhodes yorhodes mentioned this pull request Nov 16, 2023
daniel-savu added a commit that referenced this pull request Dec 20, 2023
Remediations for
#2746, in
addition to
#2780
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

5 participants