I’m not sure I would classify EOFv1 as a separate VM. eWASM? Absolutely, and that may be setting the stage for many long-time-engineers perspective on the possible scope of the changes.
I veiw EOFv1 as a variant of the original frontier VM (aka legacy vm). The main VM semantics are identical (stack, gas, message frames). As far as I’ve read clients still use the same core evaluation loop, just with new OpCodes (the same means we’ve added opcodes for nearly a decade now).
What we are changing is the storage format and the code validation rules. Parts of the whole, but still tightly intertwined with the original VM definition. Code functions is the biggest structural change and IMHO has the largest potential to change how we view the EVM.
If we did fully deprecate the frontier EVM we would lose JumpDest validation and maybe some structure designed to support both legacy and EOF forms of storage. It’s not a fundamentally different codebase.
1 Like
Depends on the scope of the transpilaiton. Taking SWAPX/DUPX and transpiling it into a single SWAP/DUP + immediate on deploy is a fairly simple mapping. But I don’t think that is what is being envisioned. Perhaps something more on the level of switching to a register machine (which stack validation makes achievable) or moving SSTORE/SLOAD to precompiles (like Optimism attempted with the OVM) is more practical. Full zk transpiliation would be the extreme edge of this spectrum.
That being said I see more likelyhood of transpiling being relevant on L2+ than at the core. Individual clients may use transpilitation as in implementation detail but I think a base layer mandate to require it would never get to the second phase of making the original code invalid without transpilation.
1 Like
EXTCODECOPY is used in vyper for factory functions (create_copy_of and create_from_blueprint). EXTCODEHASH could be useful for calculating the create2 hash for the above functions (instead of copying into memory and hashing the memory buffer).