Why is contract.deployed() called for eth_call functions?

[Mrtenz]

I'm trying to optimize my code as much as possible, but I noticed that when I call a view function on a contract, an extra HTTP request is made with eth_getCode. After some digging through the code, I found the cause here:

ethers.js/src.ts/contract.ts

Lines 184 to 186 in 34397fa

	tx.to = contract._deployed(blockTag).then(() => {
	return contract.addressPromise;
	});

Why is this function called here? Isn't it possible to handle any errors later on if the contract does not exist, to prevent an extra HTTP call?

[ricmoo]

In v5 this call is no longer made, but the reason it is there was to deal with a tremendous number of issues with people trying to call functions and send transactions to the wrong address or of a contract that was not deployed (usually due to a bug in Truffle not updating the JSON artifacts or Ganache “losing” contracts, and often just for people redeploying a contract and not updating their config, or switching networks, etc.). This was able to quickly identify these cases and cut down a lot of the tickets, emails, and gitter chats I was having.

That call should only ever be made once though, since it is a promise it implicitly caches the response. Are you finding it is impacting your performance?

It would be nice if there was some equivalent to the deployed that the contract factory adds to a contract, but for now I’m not sure we have that option in the general case, since the information necessary is not easy to query.

[Mrtenz]

Thanks for the explanation. I could see that make sense for transactions, but for calls to a contract, any errors (e.g. contract doesn't exist) can be handled in a single request, right? It's not necessarily impacting the performance, but the call itself takes about 700 ms, that's longer than the actual call I'm trying to make.

How suitable is v5 for usage right now? Is it stable enough to use it?

[ricmoo]

Well, it's perfectly "safe" (albeit useless) to perform an eth_call on an address with no code, nothing bad will happen, except you will only get 0x back. I don't want to rely on the failure to parse the result-type as a failure that the contract doesn't exist. Otherwise, for example, a call to a bad address with the signature "function foo() view returns (string)" is the error is "unable to decode string at position 0"; which is confusing. :)

Don't use v5 in production yet, but we've used it for two hackathons now, and other than a few minor things (which have been fixed) it seems to be becoming stable. :)

I'd love a few more eyes trying it out though. :)

[ricmoo]

Closing this now, but feel free to continue the discussion (I monitor closed issues) or re-open if you want more eyes on it.

Thanks! :)