This post is to formally acknowledge the de-facto existence of the EVM evolution Working Group, led by @expede. The Working Group will be performing necessary steps (research, proof of concept implementation, generation of conformance tests, etc.) to enable further improvement in the EVM. Once the group is formed and funded (at least short term), we should expect to hear more of what their current plan is, given other simultaneous developments in Ethereum 1x (State Rent, semi-stateless clients, eWASM), and given their time/money constraints.
Thanks @AlexeyAkhunov. I’m waking up this group because, as @vbuterin put it, the merge is a sort of last chance to get the EVM tidied up for the future. At this point we have a fair number of related proposals going, including at least the following. I think they all deserve discussion and refinement into a coherent whole, and propose this group as a good place to pull these discussions together.
Yes, “coopetition” is a good word for it, as what you lay out is an implementation strategy for an EVM that could be surfaced for general use later, independently of other work. I’ll await a better understanding of your ideas before digging in very much, but it does sound a lot like eWasm.
I think there has been enough work on the proposals I listed over the years that we can probably come to agree (or agree that we can’t agree) on a reasonable subset of features for an initial upgrade. (Including features that might make TEVM’s life easier.)
As a first case study for TEVM, I am planning to add EIP-615 (in its entirety) to TEVM and try to use our abstract interpretation analyser to transpile EVM byte codes to it. Even if for already deployed contract and even if semi-manually to start with.
That would be gratifying, but still not where I’d start - EVM-615 is restricted in ways that make it a difficult target for the EVM. I think I’d start with looking at eWasm and EVMC, which attempt to separate out purely computational concerns from the rest, which is part of what you seem to want. But we should talk about it next week.
And I wonder what you mean by unrolling storage ops.
Transpilation of EVM into Web Assembly (for performance reasons) was the idea behind starting eWASM (ethereum Web Assembly) project. Lessons need to be learnt from this. For example, are these statements true?:
One EVM instruction gets translated into many Web Assembly instructions, thus creating additional overhead.
Executing many Web Assembly instructions takes longer than executing a corresponding single EVM instruction. Having higher-level instruction may be inconvenient (as referred later), but it does have a benefit of amortising the cost of the interpreter loop.
Web Assembly code is harder to meter efficiently than EVM bytecode, again due to the finer granularity of operations. Because of this finer granularity, the relative overhead of metering for Web Assembly code can be much higher than for EVM bytecode.
Problems above are not unsolveable
All true, but not show-stoppers. The big EVM operations are mostly calls to native crypto and big-int libraries, which can have their gas counted as a unit. So the EVM isn’t necessarily better that way. The NEAR folks are doing well with Wasm.
I don’t understand, but unrolling storage ops sounds like a good idea. How would it compare to just having EIP-1153?
I’m still unconvinced that EIP-615 is a very good target for EVM code – it’s being so much more constrained than the EVM would mean that optimized EVM code would need to be de-optimized. There is probably a better design for the purpose – less dynamic than EIP-2315, and less restricted than EIP-615.
And I remain fairly unconvinced that transpiling arithmetic operations is a good strategy anyway. It’s not uncommon for interpreters to translate their input into a different form for better performance, some not looking much like byte-code, or even being easy to serialize.
What makes sense to me as a starting point is separating out the purely computational parts of the EVM – the VM proper – then looking at what remains – like state access and message calls and where they fit. Wasm and eWasm have done a fair amount of work on this.
As we established, I think, presenting a new resource (transitive storage, subroutine) without also presenting lots of usecases for it (not theoretical, but practical), seems to greatly reduce the changes of the new resource being adopted in EVM in the “head on” way. That is why I would like to introduce these resources in a “roundabout” way to go deeper and start using them before “Ethereum governance” approves of them and “community” starts caring about these things From my point of view, this is the only way. As I mentioned before, “trading EIPs for years of my life is not a good trade”. I want to make stuff that works, and show people how it works.
That is where the difference between eWASM and TEVM is. As far as I understand, eWASM idea was to transpile 256-bit operations into 64-bit operations, and with TEVM we won’t, and we will also go the other way, introducing 384-bit operations, and perhaps even longer words.
Correct. That is why part of this effort is to study the “history of eWASM”
and try to use our abstract interpretation analyser to transpile EVM byte codes to it. Even if for already deployed contract and even if semi-manually to start with.
From my point of view, this is the only way. As I mentioned before, “trading EIPs for years of my life is not a good trade”. I want to make stuff that works, and show people how it works.