From e77d8e3de42784f40a803a23f58ef06881142d9f Mon Sep 17 00:00:00 2001 From: cdetrio Date: Fri, 17 May 2019 15:01:58 -0400 Subject: [PATCH 1/2] use Wasm, not WASM --- README.md | 6 +++--- backwards_compatibility.md | 4 ++-- comparison.md | 4 ++-- contract_interface.md | 2 +- determining_wasm_gas_costs.md | 8 ++++---- faq.md | 12 ++++++------ metering.md | 2 +- rationale.md | 4 ++-- 8 files changed, 21 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index fde5ddc8..58f50fda 100644 --- a/README.md +++ b/README.md @@ -13,9 +13,9 @@ This repository contains documents describing the design and high-level overview Please review the [WebAssembly](http://webassembly.org/) [design](http://webassembly.org/docs/high-level-goals/) and [instruction set](https://webassembly.github.io/spec/core/appendix/index-instructions.html#index-instr) first. (You can also make a pull request or raise an issue at the [Wasm Github repo](https://github.com/WebAssembly/design).) A few key points: -* WebAssembly defines an instruction set, intermediate source format (WAST) and a binary encoded format (WASM). +* WebAssembly defines an instruction set, intermediate source format (wast) and a binary encoded format (wasm). * WebAssembly has a few higher level features, such as the ability to import and execute outside methods defined via an interface. -* [LLVM](https://llvm.org/) includes a WebAssembly backend to generate WASM output. +* [LLVM](https://llvm.org/) includes a WebAssembly backend to generate Wasm output. * Major browser JavaScript engines will notably have native support for WebAssembly, including but not limited to: Google's [V8](https://github.com/v8/v8) engine (Node.js and Chromium-based browsers), @@ -32,7 +32,7 @@ A few key points: ## What is Ethereum flavored WebAssembly (ewasm)? -ewasm is a restricted subset of WASM to be used for contracts in Ethereum. +ewasm is a restricted subset of Wasm to be used for contracts in Ethereum. ewasm: * specifies the [VM semantics](./vm_semantics.md) diff --git a/backwards_compatibility.md b/backwards_compatibility.md index 3929c72a..9f23907c 100644 --- a/backwards_compatibility.md +++ b/backwards_compatibility.md @@ -14,9 +14,9 @@ cost. The fee schedule for ewasm is yet to be specified. ## Identification of code We assume there is some sort of code handler function that all clients have implemented. The code handler identifies the instruction set type by whether it -starts with WASM's magic number or not. +starts with Wasm's magic number or not. -The WASM magic number is the following byte sequence: `0x00, 0x61, 0x73, 0x6d`. +The Wasm magic number is the following byte sequence: `0x00, 0x61, 0x73, 0x6d`. ## Solidity Support of compiling to ewasm can be accomplished by adding a new backend to diff --git a/comparison.md b/comparison.md index 2b70be76..e6dae803 100644 --- a/comparison.md +++ b/comparison.md @@ -1,4 +1,4 @@ -# WASM +# Wasm ### Good * limited well defined non-determinism * performant (near native speed) @@ -21,7 +21,7 @@ * not stable * large surface (ISA) that VM implementors would have to deal with -Response from Derek Schuff (one of the engineers for PNaCl) from Google on WASM vs LLVM +Response from Derek Schuff (one of the engineers for PNaCl) from Google on Wasm vs LLVM >I'm guessing you are unfamiliar with PNaCl. This is more or less the approach taken by PNaCl; i.e. use LLVM as the starting point for a wire format. It turns out that LLVM IR/bitcode by itself is neither portable nor stable enough to be used for this purpose, and it is designed for compiler optimizations, it has a huge surface area, much more than is needed for this purpose. PNaCl solves these problems by defining a portable target triple (an architecture called "le32" used instead of e.g. i386 or arm), a subset of LLVM IR, and a stable frozen wire format based on LLVM's bitcode. So this approach (while not as simple as "use LLVM-IR directly") does work. However LLVM's IR and bitcode formats were designed (respectively) for use as a compiler IR and for temporary file serialization for link-time optimization. They were not designed for the goals we have, in particular a small compressed distribution format and fast decoding. We think we can do much better for wasm, with the experience we've gained from PNaCl diff --git a/contract_interface.md b/contract_interface.md index b4cf9473..9769fe30 100644 --- a/contract_interface.md +++ b/contract_interface.md @@ -4,7 +4,7 @@ The Ewasm Contract Interface (ECI) specifies the structure of a contract module. ### Wire format -Every contract must be stored in the [WebAssembly Binary Encoding](https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md) format (in short, WASM bytecode). +Every contract must be stored in the [WebAssembly Binary Encoding](https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md) format (in short, Wasm bytecode). ### Imports diff --git a/determining_wasm_gas_costs.md b/determining_wasm_gas_costs.md index 71317bfa..f606f363 100644 --- a/determining_wasm_gas_costs.md +++ b/determining_wasm_gas_costs.md @@ -3,7 +3,7 @@ The goal of this document is to describe the process of determining gas costs for ewasm instructions. -Each WASM opcode is assigned an appropriate Intel IA-32 (x86) opcode (or a +Each Wasm opcode is assigned an appropriate Intel IA-32 (x86) opcode (or a series of opcodes). These opcodes have a fixed cycle count (called *latency* by Intel). We are selecting one specific CPU model from the Haswell architecture (family: `06`, model `3C`). This equals to CPUs produced in 2014. @@ -35,13 +35,13 @@ by the *metering injection contract*. ## Gas vs. *Particles* The current gas handling fields do not offer the precision needed assuming that -running WASM opcodes takes significantly less processing power compared to EVM1 +running Wasm opcodes takes significantly less processing power compared to EVM1 opcodes. -*Rationale*: EVM1 opcodes operate on 256-bits of data, while WASM opcodes are limited +*Rationale*: EVM1 opcodes operate on 256-bits of data, while Wasm opcodes are limited to at most 64-bits, which results in executing four instructions in the best case to match EVM1. Most arithmetic instructions in EVM1 cost 3 gas, which would -amount to 0.75 gas for most 64-bit WASM instructions. +amount to 0.75 gas for most 64-bit Wasm instructions. Internally, ewasm gas measurements should be recorded in a 64 bit variable with 4 decimal digits precision. We call this *particles*. It is a minor diff --git a/faq.md b/faq.md index 120ae9e6..bc2f5c94 100644 --- a/faq.md +++ b/faq.md @@ -1,11 +1,11 @@ # FAQ -WASM's FAQ can be found [here](https://github.com/WebAssembly/design/blob/master/FAQ.md) +Wasm's FAQ can be found [here](https://github.com/WebAssembly/design/blob/master/FAQ.md) ## Is ewasm primarily the replacement for EVM? -Currently it is being researched as a replacement instruction set for EVM1. Other instruction sets have been considered but so far WASM seems the most suitable. +Currently it is being researched as a replacement instruction set for EVM1. Other instruction sets have been considered but so far Wasm seems the most suitable. -## What are alternatives to WASM? +## What are alternatives to Wasm? Some that have been considered are [here](./comparison.md) ## What are the benefits? @@ -23,10 +23,10 @@ Not off the bat, a transcompiler will have to be created to compile existing EVM ## How does ewasm handle non-determinism when a variety of programming languages are allowed to be used? Part of the project goal is to eliminate nasal-demons. It's in the MVP. There are still a couple of edge case like sign values on NaNs but they can be canonicalized by AST transforms. -## Will ewasm be compatible with WASM? -Yes, the Ethereum System Interface can also be written in WASM. +## Will ewasm be compatible with Wasm? +Yes, the Ethereum System Interface can also be written in Wasm. -## Can ewasm be built even if WASM is not currently complete or will we need to wait for its completion/MVP? +## Can ewasm be built even if Wasm is not currently complete or will we need to wait for its completion/MVP? Yes, but we would lose the "Shared tooling" benefit. So It might not make sense. ## Does ewasm use synchronous or asynchronous methods? diff --git a/metering.md b/metering.md index 79f1f22a..7b8d0680 100644 --- a/metering.md +++ b/metering.md @@ -2,7 +2,7 @@ Given a set of operations and a corresponding set of costs for each operation we can deterministically run computation for any number of cost units by summing up the costs on the execution of each operation. We call the cost units here "gas" and it stands as a estimation for computational time. -## Metering in WASM +## Metering in Wasm The following has been implemented [here](https://github.com/ewasm/wasm-metering) diff --git a/rationale.md b/rationale.md index 864f084b..2a637cff 100644 --- a/rationale.md +++ b/rationale.md @@ -3,8 +3,8 @@ * Fast & Efficient: To truly distinguish Ethereum as the World Computer we need to have a very performant VM. The current architecture of the VM is one of the greatest blockers to raw performance. WebAssembly aims to execute at near native speed by taking advantage of common hardware capabilities available on a wide range of platforms. This will open the door to a wide array of uses that require performance/throughput. * Security: With the add performance gains from ewasm we will be able to implement parts of Ethereum such as the precompiled contract in the VM itself which will minimize our trusted computing base. * Standardized Instruction Set: WebAssembly is currently being designed as an open standard by a W3C Community Group and is actively being developed by engineers from Mozilla, Google, Microsoft, and Apple. -* Toolchain Compatibility: A LLVM front-end for WASM is part of the MVP. This will allow developers to write contracts and reuse applications written in common languages such as C/C++, go and rust. -* Portability: WASM is targeted to be deployed in all the major web browsers which will result in it being one of the most widely deployed VM architecture. Contracts compiled to ewasm will share compatibility with any standard WASM environment. Which will make running a program either directly on Ethereum, on a cloud hosting environment, or on one's local machine - a frictionless process. +* Toolchain Compatibility: A LLVM front-end for Wasm is part of the MVP. This will allow developers to write contracts and reuse applications written in common languages such as C/C++, go and rust. +* Portability: Wasm is targeted to be deployed in all the major web browsers which will result in it being one of the most widely deployed VM architecture. Contracts compiled to ewasm will share compatibility with any standard Wasm environment. Which will make running a program either directly on Ethereum, on a cloud hosting environment, or on one's local machine - a frictionless process. * Optional And Flexible Metering: Metering the VM adds overhead but is essential for running untrusted code. If code is trusted then metering maybe optional. ewasm defines metering as an optional layer to accommodate for these use cases. * Furthermore some of [Wasm's top design goals](https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md) are largely applicable to Ethereum, including: From 70406b120f155b4161b4422150b6b76b41e50f11 Mon Sep 17 00:00:00 2001 From: cdetrio Date: Fri, 17 May 2019 16:44:35 -0400 Subject: [PATCH 2/2] fix spelling --- metering.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/metering.md b/metering.md index 7b8d0680..5d5a037e 100644 --- a/metering.md +++ b/metering.md @@ -25,7 +25,7 @@ i64.const call $meter ``` -And a metering function `$meter`. The meter function has a signature of `(type (func (param i64)))`. Internally this function should keep a running sum and if that sum grows larger than a given threshold, end the program's execution. The metering function can be imbedded in the binary itself or can use wasm's import to define it externally. +And a metering function `$meter`. The meter function has a signature of `(type (func (param i64)))`. Internally this function should keep a running sum and if that sum grows larger than a given threshold, end the program's execution. The metering function can be embedded in the binary itself or can use wasm's import to define it externally. Then given an array of opcodes we iterate the array and divided into segments that start with one of the `branching_ops`