feat: FuelVM support for Hyperlane #4861
Conversation
…structure/hyperlane-monorepo into feat/fuel-integration
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4861 +/- ##
=======================================
Coverage 77.53% 77.53%
=======================================
Files 103 103
Lines 2110 2110
Branches 190 190
=======================================
Hits 1636 1636
Misses 453 453
Partials 21 21
|
rust/main/chains/hyperlane-fuel/src/indexer/query/conversions.rs
Outdated
Show resolved
Hide resolved
|
|
||
| impl FromBits256Array for Vec<Bits256> { | ||
| fn into_h256_array(self) -> [H256; 32] { | ||
| assert!(self.len() == 32); |
There was a problem hiding this comment.
could we maybe make this return an Err instead of panicking? afaict it's only used for the merkle tree which is trusted and should never be other than 32 elements in length, but I wanna make sure we don't accidentally use this elsewhere and panic
| .filter_map(move |(index, tx)| { | ||
| if !tx.is_valid() | ||
| || !self.is_transaction_from_contract(&tx) | ||
| || !self.has_event(&tx) |
There was a problem hiding this comment.
nit: I see that has_event basically does the same work as extract_log later on. Should we consolidate?
| let decoder = &self.log_decoder; | ||
| for (index, receipt) in receipts.into_iter().enumerate() { | ||
| if let Ok(decoded_logs) = decoder.decode_logs_with_type::<E>(&[receipt]) { | ||
| if !decoded_logs.is_empty() && decoded_logs.len() == 1 { |
There was a problem hiding this comment.
would it ever be possible to have multiple decoded logs here? I guess not because a single receipt can at most relate to one log? https://docs.fuel.network/docs/specs/abi/receipts/#logdata-receipt
| false | ||
| } | ||
|
|
||
| fn extract_log<T>(&self, receipts: Vec<Receipt>) -> Option<(T, usize)> |
There was a problem hiding this comment.
what if these receipts include multiple logs? for example, if a transaction sends two messages, iiuc we'd pass in all the receipts from that transaction here and we'd only return the first event. Should this return a Vec instead?
| where | ||
| T: Into<Indexed<T>> + PartialEq + Send + Sync + Debug + 'static + From<E>, | ||
| { | ||
| data.blocks |
There was a problem hiding this comment.
I assume there is no better way of just querying the events we care about? Going through each and every transaction to ever exist is unfortunate as it'll mean backfill indexing will take a super long time
| } | ||
|
|
||
| #[derive(cynic::QueryFragment, Clone, Debug)] | ||
| pub struct Receipt { |
There was a problem hiding this comment.
why do we need to define this ourselves instead of the Receipt from fuels?
There was a problem hiding this comment.
It all boils down to them not having the full data of their GraphQL implemented with cynic.
The main culprit here is the Block,which does not return all the data we would use when indexing. That's one of the main reasons why indexing by using their SDK would be inefficient.
Due to that, and because we cannot mix different cynic schemas, we need to redefine the fragments, which are useful and relevant, along with some needed boilerplate.
| fn process_calldata(&self, message: &HyperlaneMessage, metadata: &[u8]) -> Vec<u8> { | ||
| // Seems like this is not needed for Fuel, as it's only used in mocks | ||
| todo!() | ||
| fn process_calldata(&self, _message: &HyperlaneMessage, _metadata: &[u8]) -> Vec<u8> { |
There was a problem hiding this comment.
ha yeah we should probably remove this from the trait, but we can do that later
| network.config.node.bound_address().to_string() | ||
| ), | ||
| }], | ||
| grpc_urls: vec![], |
There was a problem hiding this comment.
are these necessary for Fuel? this and the bech32 prefix are cosmos specific iiuc?
| @@ -0,0 +1 @@ | |||
|
|
|||
| @@ -0,0 +1,6 @@ | |||
| [ | |||
There was a problem hiding this comment.
this whole rust/main/utils/run-locally/src/fuel/fuel-contracts dir including the .bin and jsons is pretty massive
Is there any way to more tightly integrate this with the fuel contracts? E.g. pull this release as part of e2e or something?
Description
Support FuelVM chains on the Hyperlane Protocol
Configurations for FuelTestnet and FuelIgnition
Backward compatibility
Yes
Testing
Contract repo E2E testing on local Fuel and EVM nodes
Contract repo E2E testing on Fuel Testnet and Base Sepolia
Notes
The configurations for the Fuel Testnet and Ignition are still WIP