search

ethereumproject / ECIPs

The Ethereum Classic Improvement Proposal
55 stars 40 forks source link

EVM 2.0 Wasm #44

Open Dexaran opened 7 years ago

Dexaran commented 7 years ago

Title: EthereumClassic VM 2.0 Author: Dexaran, dexaran820@gmail.com Status: Draft Type: EVM Created: 11-04.2017 Resolution: https://github.com/ethereum/EIPs/issues/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:

Specification

Read issue #48

References

sjmackenzie commented 7 years ago

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 commented 7 years ago

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

sjmackenzie commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.