EVM 2.0 Wasm

[Dexaran]

Title: EthereumClassic VM 2.0
Author: Dexaran, [email protected]
Status: Draft
Type: EVM
Created: 11-04.2017
Resolution: ethereum/EIPs#48

Abstract

This ECIP proposes upgrading the VM by converting to use a subset of Webassembly (Wasm). Wasm is a new Assembly standard being built for the web. The main advantage of using wasm is performance (both speed and size). The main disadvantage would be the need to port our existing infrastructure to use a new ISA. Most of this ECIP is taken from Wasm's design docs which should be referenced for futher details.

Motivation

Ethereum is planning to upgrade its VM to Wasm. I don't see any reasonable arguments against doing it so I think we need to do the same.
I found it very important to keep a minimal difference between Ethereum and Ethereum Classic in technical aspects as possible because of it will:

• Make future implementation of protocol updates (like Swarm) easier.
• Make DApps developers lifes easier.
• Keep compatibility of development tools/frameworks of ETC and ETH.
• Prevent ETC chain from being stale.

Specification

Read issue #48

References

• wasm's design docs
• chrome's binary encoding
• A Tree-Based Alternative to Java Byte-Code - ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Kistler96.pdf
• Java Trees
• Adaptive Compression of Syntax Trees and Iterative Dynamic Code Optimization: Two Basic Technologies for Mobile-Object Systems -ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf
• VM Showdown: Stack vs Register

[sjmackenzie]

The new sputnikvm is being implemented in Rust. Please see this article https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and-emscripten/7627

[splix]

@Dexaran is there any proof that Ethereum is upgrading its VM to Wasm? I can't find it

[sjmackenzie]

This proposal breaks backward compatibility of contracts, they'd need to introduce a new compilation step to achieve backward compatibility, I'd say it sufficient to say that we make a darn good vm that executes contracts well, we absolutely stick to backwards compatibility as this is what dapp devs will come to appreciate especially if ETH wasm evm rolls out and they're constantly having to adjust it thus breaking the contract ecosystem upon every wasm format stabilization, as wasm itself is not fully defined yet. Here is some docs regarding their implementation https://github.com/ewasm/design.

The point of wasm is to get native apps running in the browser, hence they need to define a format suitable for transport. LLVM IR is not such a format as Lattner has deliberately kept it unstable. It's absolutely accurate that LLVM IR not a suitable portable format (I actually experimented with this several months ago). But then again does everything have to target the browser? LLVM IR targets different architectures quite well, the toolchain is solid with billions of dollars invested. If we want to get our evm to run in the browser we can target WASM via the LLVM toolchain, if they want to get the evm to execute bog standard wasm code then they'll be competing against the browsers.

I'll need to do more research but breaking backward compatibility is out of the question. Java got to its position by not breaking backward compatibility, hence it built up a massive community, again billions of dollars were poured into that virtual machine to speed it up without breaking backward compatibility. I hope sputnikvm goes in this direction.

[Dexaran]

is there any proof that Ethereum is upgrading its VM to Wasm?

No, I didn't have any proof they will implement it but I read a number of articles/discussions about it and browsed the code and documentation. I've already corrected my proposal and wrote Ethereum is planning to upgrade its VM to Wasm.

To make everything clear I'm not suggesting to implement Wasm as-is as soon as Ethereum will do it (if Ethereum will do it).
I think it's important not only to keep backwards compatibility with our already existing smart-contracts but to keep forwards compatibility with future Ethereum features and future Ethereum DApps (that may require their new VM if it will be implemented).
According to this reason I'm suggesting to wait for Ethereums implementation of ewasm, possible ewasm bugs fixing and then to implement it too.

I want it to be a clear position about are we planning to do it in future.

[Dexaran]

EVM upgrade is required to implement custom zk-SNARKs on Ethereum/ETC.

It is now impossible to enable zk-SNARK on Ethereum due to the performance of EVM. The verifier tasks are too complex to use now. A pairing function is actually very hard to compute and thus it would use more gas than is currently available in a single block.

The solution is to swap out the EVM completely and use something like eWASM.

You can read more about zk-SNARKs implementation here.