Introduction: As more and more applications are deployed on the Ethereum network, we have a stronger need to extend the boundaries of the impossible triangle (scalability, security, and efficiency).
Specifically, the factors that restrict the impossible triangle are mainly consensus protocols, transaction signing and execution engine.
For Ethereum, the current execution engine or the execution layer of the entire protocol architecture is the Ethereum Virtual Machine (EVM), which is a stack-based execution environment. By running bytecode instructions ) transforms the system from one state to another, driving the entire operation of Ethereum.
As more and more applications are deployed on the chain and the functions of contracts become more and more complex, it is particularly important to improve the execution efficiency of virtual machines.
Image source: Ethereum Architecture
Ethereum 2.0 just wants to use these features to replace the current EVM with WASM (eWASM) customized by Ethereum to improve the compatibility and execution efficiency of smart contracts .
Because eWASM has better performance and better scalability than EVM, and can support programming languages such as Solidity, C++, Rust, AssemblyScript, etc., it will be easier to develop contracts. eWASM is also compatible with current web standards, making it easier to run in normal browsers, allowing users to access dApps without extensions .
In addition, Ethereum is not the only one that uses WASM (VM) as its underlying execution engine, EOS, Dfinity, Polkadot, Tron, Cardano, Spacemesh, etc. have all adopted or are adopting WASM.
Next, we want to help you get to know the ether version of WASM through three questions – eWASM
1. What are the problems with the existing EVM, why seek WASM to replace EVM?
2. What is WASM (WebAssembly)?
3. How did Ethereum “customize” its own WASM to make it eWASM?
What’s wrong with the existing EVM
Why seek WASM to replace EVM?
First, let’s review the process of EVM executing smart contracts .
The source code (.sol or .vy) of the smart contract is compiled into bytecode (EVM bytecode) before it is placed on the blockchain. Specifically, the EVM bytecode is stored in the storage layer of the contract address. After being called by EOA or other contracts, it will be put into the virtual read-only memory (Virtual ROM) of the EVM, and then copied to the main memory using the CODECOPY instruction. (Main Memory). Finally, the EVM stack is executed step-by-step according to the instructions in main memory until the EVM stops or the gas is exhausted.
The above process can be thought of as running a copy of the Ethereum world state in the sandbox .
Image: EVM execution process
We know that EVM is a stack-based virtual machine , and its memory structure is organized and accessed through stacks.
Since each stack of the EVM must be 256-bit wide, even calculations smaller than 256 bits must be transcoded to a 256-bit format before the EVM can process them. As a result, multiple transcodings are required to execute instructions, and some simpler calculations become redundant, increasing the complexity of execution .
In addition, because EVM contains many complex advanced instructions, such as SHA3, Create Contract, etc., the virtual machine environment of EVM is far from the current 32-bit or 64-bit hardware specifications, and some optimization strategies during execution cannot be directly The instructions used to optimize the EVM result in the execution efficiency of the EVM instructions not being optimized to the maximum .
What is WASM (WebAssembly)?
The name of WebAssembly (Assembly on the Web) consists of two parts: Web and Assembly.
First, let’s take a look at what Assembly is.
Computer languages are divided into low-level languages and high-level languages. The programming we usually talk about generally refers to human-readable high-level language programming, and what computers can really understand is low-level languages, expressed in binary numbers, which are specially used to control hardware.
Image source: Internet
Before a computer program enters the CPU, it must first be loaded into the RAM, and then these programs and data enter the CPU .
The CPU is really responsible for calculation and logical judgment is the arithmetic logic unit (ALU), the instruction is split into Operand (operand) and Operation Code (operation code), the former specifies the address of the operation object (that is, the address of the register), the latter Tell the CPU what to do with Operand.
As shown in the figure below, 111010101 001010 is the addition operation (ADD) of the data registered by the CPU in the position 001 and 010 in the register.
Assembly language is the textual form of binary instructions , and the assembly process is to convert assembly language such as ADD into machine language such as 111010101.
Image source: Internet
With the addition of the web modifier, WebAssembly is geared towards the “machine language” of a conceptual machine, rather than an actual physical machine that does not map directly to specific machine code.
That is to say, WebAssembly is a kind of virtual instruction, through the execution engine (virtual machine), which is linked to the program itself and the processor in the physical sense of our computer.
Image: WASM compilation
It can be seen that WebAssembly is not a language, but a virtual instruction set , which can be used as the compilation target of each language, and then run to the browser and other platforms through the WASM virtual machine.
eWASM defines itself as a restricted subset of WASM customized by Ethereum for itself .
How Ethereum “customized” WASM
Make it eWASM?
From WASM to eWASM, we expand the “restricted” and “subset” mentioned above through the following formula:
– floating point numbers
Since the precision of floating point numbers on different hardware may be different, it will cause certain errors, and to complete the consensus in the decentralized network requires the execution of the code in Ethereum to be 100% deterministic, that is, the execution The results cannot vary by hardware.
Therefore, eWASM cannot support floating point numbers .
The Ethereum Contract Interface (ECI) is the interface between the blockchain and the virtual machine that executes the contract code .
Among them, the import can only import the symbols (methods) specified in the EEI through the API, which means that all imports specified by the eWASM module must come from the ethereum namespace, such as getAddress, getBalance, etc., which ensures that the execution of the Ethereum contract is always a sandbox box environment. In addition, each contract provides two export methods, one is main, for the virtual machine to execute and call. One is memory for EEI calls to save the results of execution.
Ethereum Environment Interface (EEI), the Ethereum environment interface .
Since WASM is a low-level language and does not support all opcodes required in the Ethereum environment, a middleware (Ethereum Environment Interface, EEI) is needed to help the underlying WASM interact with Ethereum, and provide eWASM contracts through APIs Necessary and commonly used methods to obtain on-chain information .
The following is the one-to-one correspondence between some methods in the EEI and the current EVM opcode:
Metering is used to measure the amount of computation required to execute eWASM instructions , which can correspond to the computation time required on some specific hardware.
In eWASM, there are three places where Gas needs to be paid: running opcodes, expanding memory, and calling methods in EEI .
Opcodes refers to the opcodes that come with WASM. Each WASM opcode is assigned an appropriate Intel IA-32 (x86 architecture) opcode (machine code), and each opcode corresponds to a fixed amount of computation. According to the current hardware computing power of the Ethereum node, it is concluded that each unit of calculation corresponds to 0.0045 gas. Then, we can calculate the amount of gas consumed by each opcode to execute it .
Gas cost =<cycle count>*<gas per cycle>
In the figure below, we intercept some Gas Costs corresponding to eWASM’s opcodes:
Image source: Internet media
Currently, gas price=1 for all opcodes;
Memory can be extended in pages, where one page corresponds to 65536 bytes of space. According to the current EVM memory expansion formula: words * 3 + words ^ 2 / 512, a word occupies 32 characters, and expanding a memory page will consume 14336 gas;
The gas price of eWASM calling the EEI interface is the same as executing the current EVM opcode.
The gas fee required to execute eWASM bytecode is calculated in the same way as EVM:
Gas Fee =<Gas cost>*<Gas price>
Ethereum 2.0 “heart replacement”
In order to cope with the increasingly complex business logic on the Ethereum chain, Ethereum 2.0 hopes to replace the original EVM with eWASM to improve the execution efficiency of the virtual machine .
Due to the mismatch between the current stack design of the Ethereum virtual machine and the native format of mainstream processors, the execution of instructions requires multiple transcoding, which increases the complexity. At the same time, some commonly used optimization strategies cannot be directly applied, resulting in the inability to maximize the execution efficiency of EVM.
As a virtual instruction set that is closer to local execution, WASM allows the execution layer of Ethereum to have better performance, lower storage costs, and more language support. In order to adapt to WASM, Ethereum 2.0 allows eWASM to successfully take over the baton of EVM in the execution layer of Ethereum through a series of transformations such as restrictions (removing floating-point numbers, limiting symbols) and adding interfaces (EEI, ECI) to achieve The purpose of improving the execution efficiency of virtual machines and lowering the development threshold.
Ethereum 2.0 is divided into three stages: PoS, sharding, and eWASM . At present, the merge of the consensus mechanism from POW to POS is still under intense testing, and the development of eWASM still needs to wait for the improvement of the first two stages.
As a result, eWASM is currently being updated infrequently, and more implementation details are still to be determined. Nevertheless, the performance of WASM in other public chains has proved its potential in the blockchain field , and the implementation of eWASM on Ethereum is worth looking forward to.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/ethereum-s-heart-replacement-surgery-article-to-understand-the-evm-successor/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.