Multicall.js is unnecessary

[wjmelements]

Just use regular json rpc.

[levity]

if you're talking about json-rpc batch requests, that's not guaranteed to be supported by all endpoints, and requires working at a lower level of abstraction.

[wjmelements]

I've never encountered a ethjsonrpc that doesn't support it. Do you have an example?

[wjmelements]

It's not valid jsonrpc if it doesn't support batches. Geth and Parity both support it.

[levity]

There are a lot of mobile dapp browsers and ETH node provider services. It's a valid choice for a development team to choose an RPC call they know is going to be supported across the board to manage their QA costs.

[wjmelements]

As I expected, you have no counter-example. You are imagining a non-existent problem to justify your sunken costs. Your library will be inferior to any library that can batch in parallel as a result.

[wjmelements]

It's not valid jsonrpc if it doesn't support batches. Geth and Parity both support it.

In fact all known rpc servers support it.

[michaelelliot]

@wjmelements Are you referring to multicall.sol or the multicall.js library?

There's much better support for batch requests now than there was when we created multicall.sol.

Another compatibility consideration is the dapp browser itself and being able to actually send a batch request to a node without an error being thrown because it didn't expect to receive an array of requests.

The multicall.js library provides polling and state updates to a dapp when values changes (as well as consistency guarantees and some other features). It's entirely possible to use batch requests with multicall.js instead of routing through the multicall.sol contract, albeit without universal compatibility.

Would love to see a more complete batch request compatibility table that includes dapp browsers and wallet providers.

[asselstine]

@wjmelements It's very interesting that JSON RPC 2.0 supports batch txs by default- that's news to me! We tend to work at the lowest common denominator across mobile dapp browser providers, desktop browser providers, Ganache, buidlerevm, etc. The API across all of those providers is pretty inconsistent. However, the multicall contract is portable across all of those networks!

Richard Moore has said that Ethers V5 will provide batch tx support, although I can't find it after a cursory search in the codebase. We'll have to wait to see what the updated documentation reveals.

However, what is also interesting is his take on JSON RPC batch txs. He says they are generally run in serial, so it doesn't improve the speed of the call significantly. Still, I imagine it would cut down on the number of requests.

We're looking at upgrading to Ethers V5, so we'll be running some experiments to see what works. In the meantime we've found this to be performant and reliable.

[wjmelements]

Thank you for your diligence.