fix: Zksync gas estimation fix for aggregation ISMs

[anson-caldera]

Description

The aggregation ISM was non-functional on zksync chains. This is because of a difference in the zksync rpc api which failed all eth_estimateGas calls without a sender. See zkSync-Community-Hub/zksync-developers#144.

Only aggregation ISMs are affected, because they are the only ones making eth_estimateGas calls (in order to determine the cheapest subset of ISMs to verify with).

  2025-01-17T02:16:05.703775Z ERROR hyperlane_ethereum::rpc_clients: Non-retryable JsonRpcError in http provider, error: (code: 3, message: invalid sender. can't start a transaction from a non-account, data: Some(String("0x")))
    at chains/hyperlane-ethereum/src/rpc_clients/mod.rs:89
    in hyperlane_ethereum::rpc_clients::fallback::request with fallback_count: 0, provider_index: 0, provider: PrometheusJsonRpcClient(Http { id: 4, url: https://zerion.calderachain.xyz/http })
    in hyperlane_ethereum::rpc_clients::fallback::request with self: FallbackProvider { chain_name: "dummyzeriontestnet", hosts: "zerion.calderachain.xyz" }, method: "eth_estimateGas", params: [Object {"data": String("0xf7e83aee000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000085000000000000000000000000895656a38e14290e6b3cfef3c744b763fc3487a68658982c9a3297a9548976c75f29cd7e13c9b9f97152d60b9f6edcb28eb79e930000002dc56c9c0fac10c265e51e414078125b913d8b661f1da1b369e3f6960b349fa6d178bb2300671c1f6e986b945ab115181200f3b7d0edcfb0ef89d7f095298a84151c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e6030000001600008157000000000000000000000000c41de2a4243e4304813c36cd8952366dcb36106a004405750000000000000000000000007d4155bae49688eeef7951241eb3fd95e89b6f75000000000d000081573bbd91ec85e9d1f7883ed9dd25bd20f6c220253500440575f1232b53551ae6d9b52c6702545b33a729547a63000000030034816e9ccd27ae4fb6cf4f68c8d6ade8fabd09d77e3b1a000000047bb96acb0044057515a0890800a50a87cbe50ce9c5de9a89447ff433000000047bb96acb00008157610dd9d9448cfb69ddeb24afc49b2a5ab8d3b40a000000047bb96acb0000000000000000000000000000000000000000000000000000"), "to": String("0x8b07842775cb3b0f1d174e5411c371492d5c88c7"), "type": String("0x00")}]
    in hyperlane_ethereum::ism::interchain_security_module::dry_run_verify with self
...

This PR fixes it by setting the from address to a random address for gas estimation. We are assuming that there is no vanity grinding for prefixes/gas optimization for the relayer account as this is uncommon.

Drive-by changes

n/a

Related issues

n/a

Backward compatibility

Yes

Testing

Manually tested on a zksync chain. Successful relay. https://zero-explorer.vercel.app/tx/0xc7cfd80b12585f507c2a0bf7fa9d6f84ff0b214c95960ca12293315c509f0e05#overview

[changeset-bot]

⚠️ No Changeset found

Latest commit: 3df07e7

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.53%. Comparing base (8104b76) to head (3df07e7).
Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5220   +/-   ##
=======================================
  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% <ø> (ø)

[daniel-savu]

appreciate the PR and investigation! 🙏

i had a look at zkSync-Community-Hub/zksync-developers#144 (reply in thread) and noticed it says that even when the from field is specified, estimation can still fail because from is not pointing to an actual smart account. This was the case with the Safe address in that thread:

When processing a transaction, the protocol checks the code of the from account and, in this case, as Safe accounts are not deployed as native accounts on zkSync (via createAccount or create2Account), it fails with the error above

so i wonder if it makes more sense to set from to the relayer's smart account address set in the provider, to avoid running into a similar error

[anson-caldera]

I believe this is because of Safe-specific behavior. In the comment they mentioned, Safe accounts are not deployed as native accounts on zkSync (via createAccount or create2Account). This is likely because they're contracts that weren't deployed as accounts. What they're saying in that thread is that it the from address has to be an account.

As I've successfully processed a transaction with this, it stands that the random addresses are interpreted as accounts despite not being initialized. This shouldn't encounter any errors, at least not above the probability of collision. It was probably failing for the Safe addresses because they were initialized as non-accounts.

[daniel-savu]

I see, can you please add this context to the comment

[daniel-savu]

actually i'm fairly certain estimation fails on certain chains if from has insufficient funds to theoretically pay for the simulated tx. We'd need to pass the signer address configured in the provider to make sure we don't run into that. Would you be down to do make that change as well?

[anson-caldera]

But then we'd run into the problem where if the relayer is a Safe on zksync it stops working, no? I've tested this on op bedrock, arb nitro, and zksync rollups, and it works on all three. Can you give an example chain where this might fail so I can test that?

[anson-caldera]

https://docs.ethers.org/v5/troubleshooting/errors/#help-INSUFFICIENT_FUNDS

I think that only applies when a gas price is specified, which isn't the case in this call. Happy to test this on the chains