# ETH 2.0 eWASM Sydney ## Goals * Assess eWASM as the choice for layer 1 VM * Enumerate open problems * Figure out a reasonable path to get near spec/production ready ## Questions/Topics * Code size * Bigger/smaller than WASM? * Standards around code compression? * How expensive is compression and decompression? * Is there any header/footer that can be abstracted away? * JITs vs AOCs * Current status * Tradeoffs * Assess the following purported benefits * Ease of formal verification * Interop with other chains * Enhanced tooling and language support * Precompiles (wasm computational limitations) * Confirm will still need crypto precompiles * Any other precompiles? * Metering and gas * Metering strategies (pros and cons) * How do you roll out updates/optimizations to wasm engines over time? How do we deal with gas price changes over time? * How do we amortize the cost of loading small contracts? * What is the variance in relative opcode execution times across different hardwares? (and interpreters vs compilers) * Consensus across interpreters * How often are there bugs across interpreters wrt executation of the deterministic subset eWASM? * Is it possible for code snippets to cause crashes in one WASM engine but not another? How to deal with such crashes? * Assorted questions * What are the learnings in ethereum1.0 that we should not repeat in 2.0? * Confirm 128bit arithmetic has optimized supported on modern machines. What range of hardware are we specifically targeting? * PB: 128-bit arithmetic is not bad on CPUs because CPUs have some "higher" resulution instructions like 64x64 -> 128 multiplication, SHLD - Double Precision Shift Left, ADC - add with carry. None of the are new. Also, 128-bit code is easily inlined and branch-free. * PB: Compiliers can also match patterns of these instructions: * https://godbolt.org/z/3nSVaP * https://godbolt.org/z/GYL1L0 * What does the FFI look like? * cd: see FFI example here: https://github.com/ethereum/eth2.0-specs/issues/702#issuecomment-475983439 * How is code serialized? Doing any fancy AST merklization? * Is WASM spec a living doc or has been frozen? * What is still to be done between now and 2020/1? * What is it going to take to freeze it? * Developer experience * eth1 -> eth2 compiler? solidity -> wasm compiler? 256bit to 64bit solidity transpiler? * What languages to target tooling initially # Minutes ## Background - firefox WASI - problem: - many assumption about network, and underlying OS. It's not meant for blockchain. - EEI Ethereum environment interface - kv system for blchain storage - Could introduce a blockchain agnostic interface Jake: suggest a custom interface for eth2.0 ## Assess eWASM as the choice for layer 1 VM red flag: - EWASM code size larger then EVM ## ease of formal verification * EVM is highly branching, wasm is more well-defined * EVM has to check stack, will gas run out.. * EVM 6-12 steps per opcode * EVM requires a proof for every branch * wasm has much less branching structure * wasm two steps per opcode * Isabelle proof of type soundness of wasm * K has models of IELE, of llvm, x86.. wasm is nicest * EVM 1.5 will have structured control flow (like wasm), which will affect static analysis tools and make those faster. * RISC-5 and llvm are also good targets