contractCall battle plan

[jangko]

contractCall battle plan

During debugging tool development, I noticed some peculiarities in VM internals but at that time I dare not to touch it. After some preliminary research and investigation on block 49439 using Premix debugging tool, touching the VM internals seems inevitable.

The contractCall fix will consist of several small PRs divided into 3 stages:

Stage 1:

• laying groundwork for VM opcodes automated test. Not only groundwork or POC, it is a full feature VM opcodes tester
• investigate the possibility of macro assembler(not macro of MASM but macro of Nim).
• investigate what should be included in json fixtures to test opcodes. Data embedded directly in source code
• put assembler -dissassembler into tandem to test opcodes , roundtrip, etc. no need to use dissasembler
• each class of opcodes: stack, mem, log, arith, etc must have representative in the test.

Stage 2:

• decipher Yellow Paper math symbols into something friendlier or rephrase it into working code(gas cost section).
• opcodes 'Call', 'StaticCall', 'DelegateCall', 'CallCode' must be fixed.
• they should have solid test.
• gas_costs.nim must be fixed and VM fork should be put into consideration.

Stage 3:

• contractCall procedure must be fixed, missing account operations must be added.
• block 49439, 49891, 49904, 50111, 50117 and more if possible, should pass validation.
• generate block validation test for them.
• there should be no regression at this point, additional general state test should pass.

Reminder for myself: Proceed with caution. Do not introduce any regression.
Consider any regression as something intolerable.

[stefantalpalaru]

decipher Yellow Page math symbols into something friendlier or rephrase it into working code(gas cost section).

First, check if it hasn't been done already in https://github.com/chronaeon/beigepaper

[jangko]

The beige paper is an amazing piece of work and it makes a lot of things simpler. But it also too shallow when it comes to the VM opcodes definition. Something like

0xf1  CALL  700  7  1  Message-call into an account. The operand order is: gas, to, value, in offset, in size, out offset, out size.

definitely insufficient.

[zah]

Regarding "Stage 1", it's true that the standard json suite is relatively incomplete, but I'm not sure we need to spend a lot of time creating our own separate testing framework with things like our own EVM assembler.

If you are confident that this can be implemented in a day or two, it may be a good investment, but otherwise I would look into reusing some of the existing programming languages as Vyper, solidity or LLL to produce bytecode sequences that can be entered manually into the existing json format.

[jangko]

sure, simpler is better. The LLL compiler looks promising, and it gives me an idea.
I will investigate them along with macro assembler and pick the simplest one.

[jangko]

we already have a solid CREATE and *CALL implementation after #449, closing