Will this count as one RPC call or multiple RPC calls?

[chenningg]

Other than network round trip time optimizations, since there is no smart contract deployed, this is functionally similar to a batch request, isn't it? In other words, on the node's side, will it unpack the request into multiple individual RPC calls rather than a single RPC call? Thanks.

[ricmoo]

This is similar in many ways. But a lot of third-party providers will charge per request, unrolling batch requests. In those cases, this will reduce the cost for per-request backends (like INFURA).

Batching is the default in v6 though, so I would be curious if you find any difference between using the multicall provider and the default batching behaviour.

This is most effective on initial loads of the site, where you may load a token name, token symbol, token decimals and balances to populate the UI. Multicall and batching can fetch all this in a single request with a single latency cost.

[chenningg]

I don't notice a huge difference in network round trip time, but I do notice that my third-party provider (Ankr) would unwrap requests made by the multicall provider and count each call as a separate RPC request. In essence, this library provides "batching" rather than "multicall". Is my understanding correct?

[ricmoo]

No, this library offers true multicall functionality (but without the multicall needing to be deployed). It uses a contract deployment to aggregate many calls using the Solidty contract included in the source. So, the provider will only receive a single eth_call. Perhaps Ankr charges by compute unit? Otherwise I can’t imagine it could unroll this contract.

[ricmoo]

(here is the contract)

[chenningg]

Hmm that's strange. In the README, you mention that there is no contract deployment required. How does the RPC provider execute eth_call then? Sorry if I'm missing something, just trying to understand how it works!

[ricmoo]

There is no deployed contract. :)

It’s a type of magic I’m trying to popularize.

When you make a transaction with no to address it is treated as an init transaction (this is how contracts get deployed). Normally an init transaction used the deployment bytecode, which is bytecode specially designed to just return the bytecode of the contract you wish to be deployed. So, if you are familiar with Solidity, this means the solidity program you deploy is actually just a special program that does the constructor stuff and then returns the actually contract bytecode. The returned bytecode is then installed on-chain and you are deployed.

But the init transaction doesn’t have to return a contract bytecode, it’s just what is generally useful to do. So, this instead fakes a deployment transaction (using a null to address) but the assembly return in the constructor hijacks the whole solidity deployment process and instead returns the results of the multicall.

Since we use eth_call on this deployment transaction, we get the result. With nothing deployed to chain, but with all the multicall operations executed.

I need to make a blog about this, I guess. :)

[chenningg]

Thanks for the explanation, learnt something new today. (: Yes, a blog post would be great! I suppose the "deployment" is then executed in a single RPC call within the Node as a staticcall in memory, but the results come from on chain?

Other multicall libraries (multicall3) require a signer to use as they support both read and writes, so would it make sense to use this for reads and then the other libraries for multicall writes?

[ricmoo]

Right. This library is only designed for reads. A similar technique can be used for write, in which case it would be more efficient to return(0,0) from the constructor, so no on-chain byte code exists, but so all the child operations occurred. But that wasn't my focus yet; mainly I want it to be efficient for that initial UI load. :)

Exactly. The "deployment" is executed as a single RPC call, but since it is an eth_call there is no effect to the blockchain, and you just aggregated a bunch of reads. :)

[chenningg]

Ok, thanks for the clarification! Closing the issue. 👍🏻

[chenningg]

As a side note for the increased number of RPC calls made via Ethers, it is a result of not using a staticJsonProvider (see this issue), resulting in increased chainId calls as the provider tries to detect the network chain. It is NOT an issue caused by this library. Cheers!

[ricmoo]

Oh, you just need to use new JsonRpcProvider(url, network, { staticNetwork: true }) to get the StaticJsonRpcProvider functionality. It's built-in now, so any sub-class can use it. :)

[chenningg]

Yep, I have since done that and the calls have went down by a lot. Thanks again!