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

feat: FuelVM support for Hyperlane #4861

Open
wants to merge 39 commits into
base: main
Choose a base branch
from

Conversation

Mantas-M
Copy link
Contributor

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

Mantas-M and others added 23 commits October 2, 2024 10:58
Copy link

changeset-bot bot commented Nov 15, 2024

⚠️ No Changeset found

Latest commit: 1eeffaf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link

codecov bot commented Nov 18, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.53%. Comparing base (11cf66c) to head (30b898f).
Report is 21 commits behind head on main.

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           
Components Coverage Δ
core 87.80% <ø> (ø)
hooks 79.39% <ø> (ø)
isms 83.68% <ø> (ø)
token 91.27% <ø> (ø)
middlewares 79.80% <ø> (ø)

Copy link
Contributor

@aroralanuk aroralanuk left a comment

Choose a reason for hiding this comment

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

I left some comments; e2e as part of this PR will be necessary for approval but shouldn't be a blocker for audit.

}

// Implement `EventDataTransformer` for `GasPaymentEvent`
impl EventDataTransformer for GasPaymentEvent {
Copy link
Contributor

Choose a reason for hiding this comment

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

These implementations all look identical, is it possible to make them more generic?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

// These conversions are the `From` implementations for converting the `Receipt` schema from the Fuels Rust SDK
// since we cannot implement `From` for our custom Recipt schema on the `fuels::tx::Receipt` directly.

pub fn generate_receipt(schema: Receipt) -> Result<FuelRecepit, ConversionError> {
Copy link
Contributor

Choose a reason for hiding this comment

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

kinda suprised there's no library for this code?

Copy link
Contributor

Choose a reason for hiding this comment

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

nit: FuelRecepit spelling

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Spelling fixed

No library as from what I've seen, the types are ripped from the FuelSDK and redone since the types they have do not support all the GraphQL operations that are used to make the indexer optimized. The only supported ones are the ones which the SDK exposes as functions and chaining those together to make the indexer work is very inefficient.

Even though this code is quite ugly, it allows us to index Fuel using a single query, which is great for not spamming RPC requests.

.into(),
),
pc: schema
.pc
Copy link
Contributor

Choose a reason for hiding this comment

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

out of curosity, what's pc here - program counter?

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 is a hexadecimal string representation of a 64-bit unsigned integer; value of register $pc.

}

impl FuelInterchainGasPaymaster {
/// Create a new fuel validator announce contract
Copy link
Contributor

Choose a reason for hiding this comment

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

validator announce?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

#[cynic::schema("fuel")]
mod schema {}

// The following macros and conversions are copied from the Fuels Rust SDK
Copy link
Contributor

Choose a reason for hiding this comment

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

can we not import 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.

It's needed for the schema builder

.with_tx_policies(tx_policies)
.determine_missing_contracts(Some(3))
.determine_missing_contracts(Some(10))
Copy link
Contributor

Choose a reason for hiding this comment

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

can we make 10 a constant as max reattempts globally

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Conveniently, that is the default is we pass in None
Updated ✅

.tree()
.simulate(Execution::StateReadOnly)
.await
.map_err(ChainCommunicationError::from_other)
Copy link
Contributor

Choose a reason for hiding this comment

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

from_other_str

Copy link
Contributor Author

Choose a reason for hiding this comment

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

.count()
.simulate(Execution::StateReadOnly)
.await
.map_err(ChainCommunicationError::from_other)
Copy link
Contributor

Choose a reason for hiding this comment

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

ditto

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@@ -81,6 +82,20 @@ impl Settings {
.ok_or_else(|| eyre!("No chain setup found for {domain}"))
}

/// Check and warn if reorg period is set for FuelVM domains.
pub fn check_fuel_reorg(&self) {
Copy link
Contributor

Choose a reason for hiding this comment

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

not sure why you need this? we can just ignore the param

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was suggested to be added by @daniel-savu, the param is ignored, just adds a warning that the config has an invalid value

pub async fn new(
conf: &ConnectionConf,
locator: ContractLocator<'_>,
mut wallet: WalletUnlocked,
Copy link
Contributor

Choose a reason for hiding this comment

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

Wallet (readonly) seems sufficient in a lot of these places or is WalletUnlocked just for consistency?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Consistency mostly, since we need an unlocked wallet anyway, it's cleaner to manage only one instance instead of using one for reads and one for writes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Review
Development

Successfully merging this pull request may close these issues.

2 participants