VM: Documentation (or advice) about getOpHandler

[cgewecke]

Hello, looks like fantastic work is going here :)

I help maintain solidity-coverage and I'm interested in using the V4 Interpreter to manage our instrumentation & gas metering needs.

Questions

• Is there an example somewhere of registering an op handler with the vm?
• Is it possible to do this after a vm has been instantiated, like vm.setOpHandler(...)?
• Is it possible to overload the handling of individual opcodes in opFns, preserving most of the current interpreter's behavior?

Apologies in advance if these questions are confused about how the interpreter works, any advice at all would be very helpful. Thanks for all you're doing.

[s1na]

Hello, that's great to hear!

As you've noticed we've changed much of the internals of the VM (including the new Interpreter class and getOpHandler, etc.). But because we still consider the API experimental we haven't yet exposed them publicly. At least this is the case for the v4-beta release, and might change for the stable release if we get enough feedback (like yours) that this API makes sense.

The functionality you need mostly revolves around a flexible way for setting opcode handlers?

[cgewecke]

The functionality you need mostly revolves around a flexible way for setting opcode handlers?

@s1na Yes. At the moment we run a fork of the vm which modifies the LOG opcode because we insert event statements into solidity to do line/branch detection. And we're thinking about a new design that will use an in-process ethereum provider and listen to its vm step.

Mainly we need to prevent our instrumentation of the code from distorting the 'true' gas costs of running a test because it's quite common for solidity developers to rely on internal gas metering to enforce certain conditions (like to stop tx queue jumping on exchanges).

In sum:

• we will get the vm via ganache-core and it will already be instantiated by them. They could expose a custom interpreter option - should they?
• we'd like to use most of the current opFns logic without forking the vm e.g be able modify parts of it arbitrarily.

[holgerd77]

@s1na So do you think we are ready for some final path towards a stable v4 release? We could target something like Wednesday in two weeks? //cc @alcuadrado

[holgerd77]

Superseeded by #1705, will close.