I have an ERC-20 token contract on which I want to perform some testing on a local chain. I got my chain setup, contract deployment and testing scripts ready on my Windows machine. However, since I wanted to test with multiple miners which is not possible on my laptop, I decided to create the same setup on a docker image and run it on a more powerful server that I have access to. For some reason, with the same contract code, transfer transactions which used to take 34 000 gas on my windows setup, now take 6 700 000 gas per transfer on my docker. This kind of screws my tests which include sending many transactions, as now only 1 transaction is added per block (I have set the block limit to 10 000 000). I am very confused as of how can the same transaction take more than 100 times the gas it used to take?

  • The same transaction can require varying amount of gas due to various reasons. But if you initiate two instances of the same blockchain and perform the same transactions in the same order then the gas amounts should be the same. Some more info here for example: ethereum.stackexchange.com/questions/44643/… Mar 9, 2020 at 16:30
  • @LauriPeltonen I read the info in the link you sent but I still don't understand how the difference can be so huge ( from 34 000 to 6.7 million) ? In the former case, the array with the token balances that I am modifying should be even smaller since I have transfered coins to less accounts. Could there be something wrong with my contract that got deployed somehow? Because now I tried to call the balanceOf method on the contract and I get Returned values aren't valid, did it run Out of Gas? I am honestly pretty lost as of what's happening Mar 9, 2020 at 16:53

1 Answer 1


While there are a few sources of normal variance:

  1. Different EVM versions have different OPCODE pricing
  2. Conditional branching in contracts, including ERC20, can lead to a range of possible transaction costs

There is no good reason for a valid transaction to shoot up many orders of magnitude. Unless it is a very strange token contract, there would be no iteration that would explain such a burn if everything is working.

It is possible the transaction is failing by consuming all gas. That gas consumption is in the range of a reasonable block gasLimit.

I would concentrate on your testing methodology. Start by confirming the costly transaction actually succeeded. Does the sending account have tokens to send on the test blockchain? Did the receiver get them?

You should also check and confirm the EVM version you are running in the containers. Make sure it is compatible and not too old for your bytecode because differences can cause that sort of behaviour.

Hope it helps.

  • I believe the is an issue with the contract because even the contract's totalSupply method returns an error Error: Returned values aren't valid, did it run Out of Gas? and I get same error when I try to read the balances. Also I believe you are correct that the transaction is taking the maximum gas amount since I have seen that number at my tests when a block is fullly filled. How can I check my EVM version because I guess that would be the issue since the code is literally the same and is the standard ERC-20 code. Mar 9, 2020 at 17:43
  • I get this when i run truffle version Truffle v5.1.16 (core: 5.1.16) Solidity v0.5.16 (solc-js) Node v8.10.0 Web3.js v1.2.1 I had solidity 0.5.0 as my version in my contract files so I changed it now to match this one but I still get the same error :( Mar 9, 2020 at 18:26
  • Check the geth version on both chains. It's important that the bytecode compiled with Solidity is compatible with the EVM on the chain you're using. Mar 9, 2020 at 18:55
  • I just checked them they are indeed different. On windows: geth version 1.9.9 On linux: 1.9.11 Does this mean that I should downgrade my version? Mar 9, 2020 at 19:38
  • 1
    ethereum.stackexchange.com/questions/73410/… Yes I forgot to post it my bad. Essentially, I was missing the initialization for all the forks in the config part of the genesis file ( I only had EIP150, EIP155, EIP158 and the Byzantium blocks initialized). I also didn't have some of the other fields like block number and coinbase but I am pretty certain it was the fork blocks info that caused the problem.I do not fully understand how that caused the problem but it works now. Mar 10, 2020 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.