Improve aleth-vm tool interface

[chfast]

From @holiman:

It's here: ethereum/tests#249 (comment) . But I'll add my tldr; (which also became quite long):

Input

The evm should take the following inputs:

• --code <code> - code to be executed.
• --codeFile <file> - file containing code to be executed. Sometimes really large chunks of input cannot be passed through bash.
• --gas <int>
• --price <int>
• --sender <address> - address of ORIGIN
• --receiver <address - address of ADDRESS
• --input <code> : CALLDATA
• --value <int>
• --json - boolean flag, output json output for each opcode or not (it's useful to disable json when benchmarking)
• --nomemory - disable showing the full memory output for each op
• --create - if specified, it's executed as initcode
• --prestate - a chain specification, the same one that the client normally would use.

Basically, the evm should be able to run things very simply, like so:

#evm --code 6040 --json run
{"pc":0,"op":96,"gas":"0x2540be400","gasCost":"0x3","memory":"0x","memSize":0,"stack":[],"depth":1,"error":null,"opName":"PUSH1"}
{"pc":2,"op":0,"gas":"0x2540be3fd","gasCost":"0x0","memory":"0x","memSize":0,"stack":["0x40"],"depth":1,"error":null,"opName":"STOP"}
{"output":"","gasUsed":"0x3","time":141485}

But it should also be able to reconstruct an actual on-chain transaction, with complex options including prestate, where no code is passed, since it's already been showed into the prestate:

./evm --prestate /home/martin/workspace/evmlab/output//0xd6d519-genesis-geth_wq38zsy5.json --gas 150000 --sender 0x69ea6b31ef305d6b99bb2d4c9d99456fa108b02a --receiver 0xb97048628db6b661d4c2aa833e95dbe1a905b280 --input a9059cbb0000000000000000000000008eef795fd9150f118bddeca556a5a2a2438ab865000000000000000000000000000000000000000000000081ebd8ffd6b2a58000 --json run

Output

The evm should output a json object for each operation. Example:

{"pc":0,"op":96,"gas":"0x2540be400","gasCost":"0x3","memory":"0x","memSize":0,"stack":[],"depth":1,"error":null,"opName":"PUSH1"}

Required: pc, op, gas, stack, depth
Optional: opName, gasCost, error

The stack, memory and memSize are the values before execution of the op.

At the end of execution, some summarical info is good, e.g.

{"output":"","gasUsed":"0x3","time":141485}

When errors occur, geth and parity handles them differently.

Minor changes to how things work is ok, we can handle discrepancies in format and minor quirks.

[turing228]

I'll do it!

[AnthonyBroadCrawford]

@chfast Mind if I run with this issue?

[chfast]

@AnthonyBroadCrawford if you still interested, yes.

[AnthonyBroadCrawford]

@chfast Actually, I am. I've been super busy lately but I have a nice month where I have the capacity to complete this. I'll provide another update by the end of the week. Thank you so much for the nudge.

[josephnicholas]

@chfast quite confused, should this be an aleth change or the ethereum/test change? Or both Add interface and add test?

[chfast]

This is about aleth-vm tool here. And it's compared to evm tool from go-ethereum.

[josephnicholas]

@chfast okay, I would love to work on this, but where could I ask some questions, if I'm stuck on something. The description above is basically the feature to add in aleth-vm am I correct?

[gumb0]

@josephnicholas Feel free to reach us at https://gitter.im/ethereum/aleth (better tag either me or @chfast, otherwise we might miss it)

These features I think are already present in some form in aleth-vm (maybe except --codeFile), the task is mostly about reworking the CLI interface and output format.

[josephnicholas]

@gumb0 I started on this yesterday, I tried to compare aleth-vm options with evm(from geth). There were some options that were in evm and not in aleth-vm.

So, to ask once again on the coverage of this task, should I just implement --codeFile or some others? Like receiver, nomemory?

Maybe I can assume codeFile is the priority? then, another thing is,(since I am quite new to Ethereum), is it a direct migration from geth EVM code?

[holiman]

Update from my side:
What would be really useful, more than specifying code and codefie, would be to have statetest. Geth evm and parity evmbin both have this. A generalized state test incorporates

• prestate (code, balance, nonce etc)
• chain configuration (fork blocks)
• environment info (block number, timestamp etc)

This is what we use to do fuzzing, and is easier to use as a canonical representation of a prestate than trying to provide each client with a custom genesis, code etc.

[holiman]

the option nomemory is useful, since memory can be a megabyte, and outputting a megabyte at every op becomes very unwieldy. I'd even go so far as to say that the default might be without memory (having memorySize is important, though).

One important aspect is that the execution should not hold on to the data during the entire execution, and spit it out as a json array. Instead, it should output jsonl, one line per op.