Fuels-ts uses 4 queries to fulfill one `get` request

[diyahir]

Each ‘get’ query starts with

1. getConsensusParametersVersion
2. getChainAndNodeInfo
3. estimateGasPrice
4. dryRun

This is causing a ton of strain on the RPC

[diyahir]

What this fails to answer is why there needs to be a back and forth between the client and the server, this is just wasted time and bandwidth

I’m assuming the client will not change those values so instead of doing 4 rounds of communication, the server should just perform all of this logic internally and return either an error or the queried value, or add a flag to accept let the server handle everything other than these rounds of validation that the client is potentially doing?

For get fn calls specifically.

`.get()` method calls `dryRun` and `estimateGasPrice`

Is it expected that the .get() requests execute estimateGasPrice and dryRun ? Yes, this is expected. The .get() method internally performs a dryRun, which allows us to retrieve the contract call response without executing a real transaction and incurring costs. The estimateGasPrice step is necessary because, even during a dryRun, the gas and fees must be accurately estimated to ensure proper validation of the call. You can use the multiCall feature to execute multiple contract .get() calls w…

[Torres-ssf]

Hello @diyahir, regarding the requests you mentioned:

• getConsensusParametersVersion: This request isn’t triggered for every get call. It runs only once initially, with its result cached for one minute. After this time, the cache expires, allowing the function to run again to ensure the node’s version data remains current.
• getChainAndNodeInfo: This request also uses cached data. It fetches fresh data only if the cache is unavailable or if there’s a change in the node version, as determined by getConsensusParametersVersion.
• estimateGasPrice: This request cannot be skipped, as gas prices change with each new block. We need to estimate and set the transaction’s gas and fee for each dry run. Without it, the dry run would fail.

As a result, the only requests that are always required for each get call are estimateGasPrice and dryRun.

We’ve validated this workflow to ensure the caching and request frequency function as intended. However, it seems that all four requests are being triggered on your end with each .get call, right? I’ve created an issue to investigate this further and identify any discrepancies. Apologies for the inconvenience, and thank you for your patience, we will get to the bottom of this.

[diyahir]

Why does it need to communicate with the client the estimate gas price? Can’t it just do all this internally?

[Torres-ssf]

Hi @diyahir,

Unfortunately, this isn’t possible at the moment. However, we’re actively working on an improved solution for gas estimation across the stack and will address this in future updates.

I ran some tests and confirmed that the requests behave as mentioned earlier—not all four requests are triggered every time.

For each get call, only two requests are consistently made, while the other two use cached data. I monitored the requests using minidump and verified that everything is working as expected on my side.

Could you confirm if, on your end, all requests are indeed triggered every time?

[diyahir]

Okay, but every contract has

1. getConsensusParametersVersion
2. getChainAndNodeInfo

only to return the same information, is this information potentially contract specific or global params?

We have 20 contracts at fluid fluid-protocol/contracts at main · Hydrogen-Labs/fluid-protocol · GitHub

So we’re firing off 40 requests before we’ve even asked for anything from the chain, and then say we do 1 query per contract to load the state we’re at another 40 requests since each request has to cycle back to the client for the gas estimate

When we only intend to fire off 20, for example, this setup forces us to send off 80 queries

[Torres-ssf]

@diyahir Given that all 20 of your contracts are connected to the same network (e.g., testnet), the request getConsensusParametersVersion and getChainAndNodeInfo will only be triggered once, and this happens before the first contract makes a get call.

The 2 requests are triggered when you first instantiate a Provider, and then the returned data is cached. So your very first contract call and all other contract calls won’t be firing these 2 requests again.

getConsensusParametersVersion will continue to be triggered in 1-minute base intervals. getChainAndNodeInfo will only be fired again if the chain info is updated or an error happens.

These calls are not contract-related information but rather node and chain data.

Once the Provider is set up, every contract call will result in two requests: estimateGasPrice and the actual dryRun.

Unfortunately, right now it is not possible to avoid calling estimateGasPrice before every dryRun. This limitation is not specific to the TS SDK but is inherent to the entire stack.

However, we are actively working on a solution to address this problem and reduce it to one request only.

[diyahir]

@Torres-ssf

Given that all 20 of your contracts are connected to the same network (e.g., testnet), the request getConsensusParametersVersion and getChainAndNodeInfo will only be triggered once, and this happens before the first contract makes a get call.

This not what’s happening in practice, in practice each contract fires off getConsensusParametersVersion and getChainAndNodeInfo

[Torres-ssf]

@diyahir, this behavior shouldn’t be happening.

Could you point me to the repository where these contract get calls are being made?

Understanding your environment and how it operates could provide insights into why the cached information isn’t being utilized in your case.