While doing #159 I've realised that all the opcodes using memory locations are very likely consensus-broken because they are straight converted using utils.bufferToInt to Javascript numbers.

If the input number is >= 53 bits it will not behave correctly - old ethereumjs-util truncated it silently, while the new one properly throws an exception.

In many of the cases, if such a large number is encountered, it should result on an OOG, but in our case it can fail very likely with INVALID_OPCODE.

Makes me wonder if the state tests have a good coverage (because we do pass them...) or they are left to the VM tests to check these bounds?