core/vm/runtime: added simple execution runtime

[obscuren]

The runtime environment can be used for simple basic execution of
contract code without the requirement of setting up a full stack and
operates fully in memory.

@frozeman required some benchmarking of the EVM and execution of many calls. I recall @karalabe requesting a simple execution model for the execution of EVM byte code and hence I've created a PR for such cases.

[robotally]

Vote	Count	Reviewers
👍	1	@fjl
👎	0

Updated: Wed Nov 18 13:38:06 UTC 2015

[karalabe]

Yeah, but couldn't wait for one so I've implemented my own :)) Will look though this one though :)

[karalabe]

Nitpicking, but you might want to bump the year.

[fjl]

                                                                                  build/update-license.go will fix it when we run it.

[codecov-io]

Current coverage is 46.70%

Merging #1964 into develop will increase coverage by +0.10% as of 4ec5d50

Powered by Codecov. Updated on successful CI builds.

[karalabe]

This is what I've used when I played with the EVM: https://gist.github.com/karalabe/6c200d783586a6c6b29c Feel free to cherry pick anything you like.

[karalabe]

You didn't initialize the remainder of the big.Ints, which will crash the first time accessed. (e.g. Try running "D" ;) )

[obscuren]

You're right. I must have overlooked this. I'll add some tests to test these fields thru the EVM calling the specific opcodes.

[obscuren]

@karalabe PTAL

[karalabe]

I think it would be valuable to return the generated logs too, beside the result of the execution (i.e. like this https://gist.github.com/karalabe/6c200d783586a6c6b29c#file-evm-go-L15). This would be very useful in scenarios where the code generates actual logs and you would like to inspect them / check that they are indeed correct, etc.

[obscuren]

@karalabe i'm not sure about that. That's what the Debug flag is for; in case you need inspecting. If the need arises to change the behaviour I'll reconsider.

[fjl]

👍

[karalabe]

Debug is ok for manually inspecting the execution logs, but what I was really looking for is a way to programatically inspect the contract's generated events/logs. Specifically so that I can unit test that a compiled code indeed fires the events it's supposed to.

[obscuren]

@karalabe sure. I'll make it return the stateDB which contain the logs, that makes sense. But the event/logs aren't the structured logs. The StructLog are used to create debug output and are not be confused with the vm.Logs which are used for LOG*.

[karalabe]

Aaaahh, gotcha. Confused the two things apparently. Dunno what the best way
would be then to access the logs, but you get the rational why I'd like to
inspect them. Returning the state db or something similar would also come
in handy for unit testing the contract storage.

On Wed, Nov 18, 2015 at 3:30 PM, Jeffrey Wilcke notifications@github.com
wrote:

@karalabe https://github.com/karalabe sure. I'll make it return the
stateDB which contain the logs, that makes sense. But the event/logs
aren't the structured logs. The StructLog are used to create debug output
and are not be confused with the vm.Logs which are used for LOG*.

—
Reply to this email directly or view it on GitHub
#1964 (comment)
.

[obscuren]

@karalabe addressed it. PTAL :-)

[karalabe]

Maybe rename to GasPrice? To keep it consistent with the yellow paper and the rest of the code base?