Optimize RPC API Calls to Reduce Glif Bill

[NikolasHaimerl]

Description

We need to optimize the smart contract state query to make the RPC API requests cache-able by Glif. Currently, our implementation is causing excessive RPC calls which is significantly increasing our Glif bill.

Background

This issue was identified in PR #117 where we're adding ethers.js as a dependency to address miners not having their scores recorded. While implementing this solution, we discovered that our current approach to state queries is not optimal for cacheability.

Proposed Solution

1. Use the existing rpc helper in lib/miner-info.js to make RPC API calls directly
2. Rework smart contract state queries to ask for state as of a given tipset
3. Implement a lightweight solution to parse binary responses to JavaScript objects

Implementation Notes

• We already use the rpc helper for MinerInfo state queries
• This approach may be easier than using Ethers.js or viem for this specific use case
• The optimization should be implemented soon after the initial version deployment (within days)

Related PR

• feat: peer id smart contract support #117 (Adding ethers.js dependency)
  Originally posted by @bajtos in feat: peer id smart contract support #117 (comment)

[bajtos]

Proposed Solution

1. Use the existing rpc helper in lib/miner-info.js to make RPC API calls directly
2. Rework smart contract state queries to ask for state as of a given tipset
3. Implement a lightweight solution to parse binary responses to JavaScript objects

This is not the only solution possible.

Another option is to use a different Ethers API that will allow us to invoke the smart contract state query as of the given block number (instead of assuming the latest block number).

[bajtos]

We don't need to change our code as long as the Ethers.js API used by our lookup ends up invoking eth_call method via the RPC API.

What we need to do as part of this issue:

1. Verify what ETH RCP API method is invoked by lib/miner-info.js. If it's eth_call then we are done.
2. If it's not, then reach out to Glif/Protofire and discuss what's the CU cost of calling that method and how can we make it cheaper.

You should be able to observe raw HTTP request/response bodies sent/received by Ethers.js by enabling debug logging, see e.g. here:

https://github.com/CheckerNetwork/spark-api/blob/d3b87c2ae1e7bff084ab9cb36e4c5f3204f0369a/api/lib/ie-contract.js#L11-L12

Info from Glif:

Caching. If I identify the problem correctly - there is no problem at all for now. getPeerData is a method in ethers lib that uses eth_call under the hood (correct me if I'm wrong). For now eth_call historically has only 1 CU per request and this can't go down no matter if cache is used as the request is being made and this is basically the lowest possible price for it. eth_call really differs from call to call, and we understand that, but our proxy is not on a level yet that would allow us to charge user more for making more sophisticated calls (and unlikely will ever be given that it really depends on a smart contract), so for now I'd say you are already using the chepeast call possible. Just ensure you are not using eth_getLogs instead, because this one is very-very costly. If you will need to use this one still - let us know, we can work together on some caching solution then.