VM has a lot of consensus breaking bugs 🐞

[axic]

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?

[axic]

Simple test case 0 <54 bit number> MSTORE.

[axic]

Affected opcodes:

• ISZERO
• BYTE
• SHA3
• CALLDATALOAD
• CALLDATACOPY
• CODECOPY
• EXTCODECOPY
• BLOCKHASH
• MLOAD
• MSTORE
• MSTORE8
• JUMP
• JUMPI
• LOG
• CREATE
• CALL
• CALLCODE
• DELEGATECALL
• RETURN