Trinity + ewasm integration proposal === We propose three schemes for adding ewasm support to Trinity. We look forward to your feedback. ## Scheme 1: Integrate ewasm An ewasm fork lives in `evm/vm/forks`. ewasm `Computation` inherits from Byzantium `Computation`, but we remove things which are not needed for ewasm. Each Wasm opcode is a Py-EVM `Opcode`, with tracing support. Benefits: - Requires changing the least existing code in Py-EVM. Disadvantages: - Implementing a whole Wasm VM where each opcode is a Py-EVM `Opcode` would require substantial work. Swapping in a new Wasm VM will require repeating this work. - If prototypes want to execute both legacy EVM bytecode and ewasm bytecode in a single chain, then we must to support two `Computation` objects in a single fork. - At least partially breaks the existing "fork" abstraction (adding Wasm support is orthogonal to an EVM fork), may not be future proof, and may not be easily extensible when we want to add another VM. - PyWebAssembly no longer exists as a standalone library. ## Scheme 2: Isolate ewasm We define a "glue-code" API between Py-EVM and ewasm. ewasm `Computation` inherits from Byzantium `Computation`, but we remove things which are not needed for ewasm. Py-EVM calls `ewasm_execute()` to execute an ewasm contract. Py-EVM also provides an API with functions like `getBlockDifficulty()` and `setStorage()`. We use Py-EVM `Opcode` objects for functions callable from ewasm code such as `useGas`, `getBlockDifficulty`, and `storageStore`, allowing tracing of these functions, but tracing of Wasm opcodes must be provided separately by the Wasm VM. On the Wasm side, we put a native Python [EEI](https://github.com/ewasm/design/blob/master/eth_interface.md) (Ethereum Environment Interface) layer on top of Wasm VMs to handle Wasm calls to the glue-code API. This layer allows swapping out Wasm VMs. An early prototype of this scheme is Lane Rettig's [Juno](https://github.com/lrettig/juno), which already passes one ewasm test. Possibilities follow: - Py-EVM <--> glue-code API <--> EEI <--> Wasm VM - Py-EVM with `Computation` containing glue-code API <--> EEI <--> Wasm VM Benefits: - Balance between extensibility and modifying existing code. - Allows swapping in a new Wasm VM by modifying the EEI, not Py-EVM. Disadvantages: - Trinity would talk to EVM and ewasm in different ways. ## Scheme 3: Isolate all VM-related code Paweł Bylica claims that we can isolate both EVM and ewasm from the rest of an Ethereum Node by exposing only the [EVMC](https://github.com/ethereum/evmc) (Ethereum client-VM Connector), a set of C functions and C data structures which are sufficient to support current EVM and ewasm semantics. cpp-ethereum uses EVMC to execute ewasm contracts (using an EEI implementation called [Hera](https://github.com/ewasm/hera) which interfaces with many Wasm engines--currently only Binaryen, and soon WAVM, V8 engine, etc.). Paweł is working on a similar interface for Geth. The following scenarios are all currently supported (or will be soon): - cpp-ethereum <--EVMC--> Hera <--> Wasm VM - cpp-ethereum <--EVMC--> EVM - Geth <--FFI to EVMC--> Hera <--> Wasm VM We propose following Paweł's and Alex Beregszaszi's suggestion to isolate all VM-related code by using the EVMC API, but we will implement it in native Python, relaxing the requirements of EVMC's C types and ABI. Our interface will be called the "High-Level EVMC API" ("H-EVMC" -- "High-level" since it's implemented in Python not C -- yes, the names could use a little work). Py-EVM will interact with both ewasm and EVM through this H-EVMC API. The EVM and ewasm would each be modular, and more modules can be added to prototype different VMs. After this H-EVMC API is tested and working, we consider implementing a FFI to EVMC, similar to Geth's, to expose all of Hera's Wasm VMs. Tracing is done by the EEI and Wasm VM. Possibilities follow: - Py-EVM <--H-EVMC API in native Python--> EEI <--> Wasm VM - Py-EVM <--H-EVMC API in native Python--> EVM - Py-EVM <--FFI to EVMC--> Hera <--> Wasm VM - Py-EVM <--FFI to EVMC--> EVM Benefits: - Clean abstraction. - Extensible. - Can swap in any VM supported by EVMC. - EVMC also standardizes error codes, allowing better testing across clients. Disadvantages: - Requires exposing this standard API, and possibly re-implementing EVM to use this standard API. - Some things in Py-EVM may be coupled and difficult to separate, resulting in a major overhaul. ## Subscheme: Unify all VMs (could be included in all three above schemes) Everett Hildenbrandt is specifying the EEI as [KEEI](https://github.com/ewasm/design/blob/9e0d5c5936627260b4cda536210d6f7b188fbd0a/spec.md) with opcodes like `useGas`, `setAccountStorage`, and `getBlockDifficulty`. KEEI will support both EVM and ewasm and will even allow them to share opcodes whenever possible, unifying the VMs. This scheme may optionally use H-EVMC API between Py-EVM and the EEI. A visualization: - Py-EVM <--> EEI with KEEI opcodes <--> WASM VMs - Py-EVM <--> EEI with KEEI opcodes <--> EVM Benefits: - Unified elegance. Disadvantages: - Waiting for Everett to finish.