Gas limit on eth_call?


I am trying to call a public function of a contract to display some data to the user. I am using web3.js to create a Contract object and call() a method. Everything works on my local node but Infura complains about gas. To be clear, this code is simply running a method call in the node’s local EVM, not sending a transaction to be included in the blockchain, so I’m not sure why a gas limit is relevant. I have tried passing various gas arguments but Infura seems to cap it at 19981536.

If I run estimateGas() on the method, it returns about 39000000. Infura won’t even let estimateGas() finish so I also did that on my local Geth node.

Everything was working with Infura a week ago, so my guess is either the method call recently went over Infura’s call gas limit (due to state changes on mainnet), or Infura recently changed the call gas limit.

So, can Infura comment on whether there is a gas limit for eth_call? Is this in the docs somewhere? Does Infura+ increase it?



If the method call is not executing transactions on the blockchain, then the gas limit parameter would not be required.

Could you share the contract address and the method you are calling from the contract?

Here is a code sample you can run with web3.js/node.js:

  1. Copy js file to local directory
  2. insert your Infura API key into code (line 3)
  3. run ‘npm install web3’ or ‘yarn add web3’ from directory
  4. run file with ‘node filename.js’
  5. Correct output is some large arrays.

That code sample works with the web3 provider as my local Geth node, but runs out of gas with Infura. Let me know if you need more info. Thanks!

Hi @talkingant . Earlier this week we added a gas cap of double the block gas limit to eth_call and eth_estimateGas to prevent Denial of Service attacks. I apologize that you ran into this without it being clear in the docs. The intention with setting the limit to double the block gas limit was that it shouldn’t effect existing users since no call should take more than the block gas limit.

1 Like


The reason this public function exists is to avoid hundreds of individual eth_calls. Essentially there is an array of addresses in the contract storage, and I need to iterate through this array and call a function on each address to get some info about the address. The public function was never intended to be run in a transaction. Instead, it allows one eth_call to the node and it runs that array iteration in the EVM, then returns an array of results. The alternative would be to do many eth_calls like:

  1. eth_call for array length
  2. Inside for loop, eth_call getArrayElement(index) then eth_call getInfo() on that address

If there are 100 elements in the array, then that is 201 eth_calls.

So I think there are many use cases where there is some unbounded array in contract storage, and to minimize HTTP/RPC requests the contract authors create a public view function that bundles the array iteration into one method call.

I understand the need to avoid DoS attacks. If eth_call is going to have a gas limit then we need a new design pattern for these public convenience functions that limit computation while still offering a way to reduce number of RPC requests to the node. I’m not sure what the solution is for the current design pattern. Perhaps you could default eth_call to 2x gaslimit, but allow the requester to specify a larger gas limit, and do more severe rate limiting for eth_calls and eth_estimateGas with custom gas limits.

For now, I humbly ask if you could raise the eth_call limit to 4x the gas limit, which should be enough for my method call at the moment.

Thanks for the detailed response! That was really helpful. I’ll talk to our team about raising the limit and post an update here shortly.

Hi @talkingant after discussing with our team, we’re planning on upping the gas cap limit to 10x the block gas limit but because of the change required we likely won’t be able to update this until the Istanbul fork next week. We pushed the documentation change for now to show the limit at 2x block gas limit and we will update the docs when we are able to up this to 10x next week. Are you able to workaround this issue for now? How disruptive is this to your users?

Thanks for the quick response, that sounds good! In the meantime I worked around with some caching.