Backward compatibility

[wanderer]

We have several options for backward compatibility EVM1

1. run both the VM's and use wasm's magic number to determine which VM to run the code in
2. write an EVM1 interpreter in EVM2
3. transpile EVM1 contracts to EVM2

1. would be the easiest to do but would have the additional concern of twice the surface area for consensus breaking bugs.

[wanderer]

Also we can use the bootstrap prototype to test 1)

[gcolvin]

I have been independently working with Christian on a plan for improving the current interpreter. There is huge room for improvement. Changes to gas counting, to instruction dispatch, to the optimizations Solidity makes to the EVM code, new EVM opcodes, and more. Once all these improvements are made there remains the problem that emulating a stack machine on ARM, Intel, or most any other real machine is slow. So the logical next step is a JIT to translate EVM code to code that can execute more quickly on a real machine. Machine code is best, (and we have it already) but LLVM is too heavy for a light client on small devices. But in my experience translating stack machine bytecode to code for better virtual machines can be both lightweight and effective. Especially when the target VM is designed for the purpose of being both an easy target and a good match to its intended architecture. (ARM vs. Intel etc.)

So EVM can remain the canonical representation of contracts. JIT output for faster real or virtual machines is an implementation detail. (WASM can be one of the JIT targets if so desired.) The improved EVM interpreter, (including its real and virtual JIT targets) becomes the performant VM on which e-WASM can be built, as suggested earlier by @vladzamfir .

[gcolvin]

I believe EVM should remain the canonical representation of contracts. It has been with us from the start. The basic architecture is introduced in the white paper, and the full machine is specified in the yellow paper. Every contract to date is specified in EVM bytecode. There are interpreters in Python, Go, and C++, at least. Developers actually know the EVM; we have Mix offering debugging at the EVM assembly level, and Solidity soon to have inline EVM assembly. There are more tools than I even know about: a large and growing ecosystem. And it's our VM, that we can evolve as we need. And more. It would seem to take a lot to be worth giving all this up.

[wanderer]

I believe EVM should remain the canonical representation of contracts.

Sounds biblical :P

There are interpreters in Python, Go, and C++, at least. Developers actually know the EVM; we have Mix offering debugging at the EVM assembly level, and Solidity soon to have inline EVM assembly.

Is there technically reason to use EVM1 over EVM2? These are only tooling reason. I think EVM2/wasm will in the short run and long run have much better tooling.

Developers actually know the EVM;

This is not a tooling reason. But I'm pretty sure I can find more devs that know C++ than EVM

[gcolvin]

Biblical? Yeah. Couldn't think of a better word. The main technical advantage of EVM1 is that we know what it means and how it behaves. Evolving EVM1 as the basis for EVM2 maintains that advantage almost automatically. Changing entirely to a new VM doesn't.

Yes, tooling and timing reasons are important. EVM2 should be a pretty solid prototype a year from now, and Web Assembly looks to be a future success. But EVM1 is now. I'm working to see continuous improvement of our C++ EVM interpreter starting now. Other people are busy on stuff that could become obsolete or need to be rewritten. So there is a transition to manage, and technical choices can make a difference.

After chatting with Martin I better understand what Merkelized ASTs can do. I want it, and holding on to EVM1 might get in the way. I also better understand how difficult some of the technical problems are to even define, let alone solve. For instance, we wondered whether an existing contract must use the same amount of gas on EVM2 as on EVM1? That would be what the yellow paper requires. Or does it suffice that they use the same or less? Either way, can we make it happen? Or is it OK that programs that didn't run out of gas on EVM1 might run out on EVM2? The design I sketched out would make that a non-issue, but with costs of its own. There are no doubt other solutions.

[wanderer]

moving discussion to pr #20