-
Notifications
You must be signed in to change notification settings - Fork 429
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
V3 agents rebase #2746
Conversation
Doesn't compile yet though |
Codecov Report
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
|
5a13f3c
to
f8008cb
Compare
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]>
This reverts commit 9f999a3.
@@ -28,3 +28,4 @@ yarn-error.log | |||
**/*.ignore | |||
.vscode | |||
|
|||
tsconfig.editor.json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whats this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added by @mattiecnvr afaik
/// 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, | ||
}, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
@@ -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>, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
// 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`. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
@@ -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(); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this 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
.map(|v| v.into()) | ||
.collect::<Vec<_>>() | ||
.try_into() | ||
.unwrap(); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
### Description Part of the remediations from #2746 --------- Co-authored-by: Trevor Porter <[email protected]>
### Description Part of the remediations from #2746 --------- Co-authored-by: Trevor Porter <[email protected]>
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:
Slightly more detailed overview of the work here: #2720 (comment)
Drive-by changes
Related issues
Backward compatibility
Testing