Ethereum 2.0 new virtual machine Ewasm guide: three advantages to fully hang EVM

This article explores the Ethereum Virtual Machine (EVM) and Ethereum WebAssembly (Ewasm), Ewasm will replace EVM as the state execution engine of the Ethereum 2.0 network, which will bring a series of exciting new performances to Ethereum. Upgrades and other benefits, including speed and efficiency improvements, superior interoperability, and reduced or eliminated precompilation.

The original author is Colin Schwarz, Chainsafe project manager.

1. What is the Ethereum Virtual Machine (EVM)?

In order to understand Ewasm and its impact on the Ethereum network, we must first familiarize ourselves with the Ethereum virtual machine (EVM) that it will replace. EVM is a lightweight virtual machine designed to run smart contracts on the Ethereum network. As a virtual machine, the EVM functions slightly differently from traditional operating systems such as Windows. In general, a virtual machine (VM) is a high-level abstraction that emulates a physical machine built on a native operating system. They allow the same platform to run on many different hardware architectures and operating systems, making virtual machines (VMs) ideal for distributed networks like Ethereum. The EVM is built to simulate the operations that can be performed by the physical CPU, and it is also responsible for many of the key features of Ethereum.

• BTC short-term test for $9,800 resistance, the disk is not stable, should not chase
• Depth | The dry season is approaching, the analysis of Bitcoin mining industry chain
• The investment "block dog" just collapsed in two days and collapsed 400 people and lost more than 3 million yuan.

In addition to being a virtual machine, EVM is also a "stack machine" and a "state machine" (I know that it has many adjectives, please forgive me). A state machine is simply a machine that can read input and convert to a new state based on those inputs. Stack-based virtual machines are virtual machines that organize memory structures into a stack and access them as a stack. This is in contrast to register-based virtual machines whose memory structure is stored in the registers of the CPU. In order to perform operations on a stack-based virtual machine, data called "operand" is "popped" from the stack, processed by the accept operation, and then "pushed" back to the stack according to the principle of last in, first out (LIFO). . The way to add using a stack-based machine is as follows:

1. POP 20
2. POP 7
3. ADD 20, 7, result
4. PUSH result

Https://markfaction.wordpress.com/2012/07/15/stack-based-vs-register-based-virtual-machine-architecture-and-the-dalvik-vm

One of the main advantages of using a stack system is that the EVM does not need to explicitly know the address of the operand it is processing, because the call stack pointer (SP) always provides the next operand, which helps the EVM improve efficiency and reduce Storage requirements.

In addition to the stack, EVM can store data to both memory (RAM) and disk storage. Sending data to disk storage requires the most gas, while sending to the stack requires the least amount of gas. The EVM decides where to send certain data based on its intended use and expected gas cost. At the macro level, the EVM consists of a world state, a machine state, and a virtual ROM. The world state is the storage of all accounts on the network, while the machine state includes the program counter, available gas, stack, and memory. Virtual Read Only Memory (ROM) is an immutable "EVM bytecode", a special language that only EVM can understand. It is important to understand bytecode and its relationship to high-level languages ​​such as solidity in order to fully grasp the capabilities of EVM. Since the creation of the Internet, Ethereum developers have written code in the Solidity programming language. Solidity is a "high-level" programming language, which means that although developers can understand Solidity, the machine does not understand. In order for the computer to understand the Solidity code, it must be compiled with a solidity compiler called solc. The compiler converts solidity to bytecode, which is a binary representation of the solidity opcode. EVM treats all values ​​as binary and cannot understand any other values, so the existence of the compiler is very important, allowing the developer's expression to be understood by the EVM.

2. What does the Ethereum Virtual Machine (EVM) do?

The EVM is responsible for facilitating most transactions and operations on the Ethereum network, including the execution of smart contracts. It is responsible for the various data structures that contain instructions and operands, as well as the data that is processed by the instructions. The EVM also includes an instruction dispatcher or "virtual GPU" for fetching and executing instructions and decoding operands. In other words, the EVM is responsible for tracking network components such as world status, storage status, and block information. EVM also creates a Runtime environment for smart contracts on the Ethereum network. The information in the Runtime environment is used to execute specific transactions. This information includes:

1. Gas price: "The current Gas price specified by the transaction sponsor";
2. Code size: "The size of the transaction code base";
3. Caller: "Account address of the transaction being executed";
4. Origin: "Address of the original sender of the transaction";

Finally, in addition to these responsibilities, the EVM also handles account information related to block number, Gas price, address, and balance. Because EVM is responsible for many important functions on the Ethereum network, its ability to handle operations and transactions can affect the overall speed and performance of the entire network. Similarly, the efficiency with which EVM can execute code directly affects the efficiency of the network. Therefore, in recent years, the increase in Ethereum network load has made EVM itself a bottleneck, often reducing network throughput and increasing transaction time. The problem of inefficiency is one of the main reasons why Ethereum has transitioned from EVM to Ewasm .

3. What is Ewasm?

An important core of the Ethereum 2.0 update is the transition from EVM to Ewasm.

WASM stands for Webassembly, an open standard set of instructions developed by the W3C community group. WASM is built for the Web, and engineers including Mozilla, Google, Microsoft, and Apple are actively developing it, and Ewasm (Ethernet WebAssembly) is a "restricted WASM subset" that was specifically modified for the Ethereum network. WASM is designed with a specific set of goals in mind. Basically, WASM is designed to be fast, efficient and portable . This means it can be performed "close to native speed" with common hardware features. The software is also designed to be easy to read and debug, in a text format that can be read by humans, allowing developers to manually view, write, and debug code. Finally, by forcing the host browser's permissions policy, WASM is designed to be secure and highly compatible by maintaining backward compatibility. The team that created Ewasm has also developed several more specific project goals. One of the main goals is to provide an EVM translator and a metering injector, preferably as an Ewasm contract. Another goal is the clear specification of the Ethereum interface and Ewasm contract semantics. Finally, the team's goal is to implement an Ewasm backend for the solidity compiler and to provide instructions and libraries for writing contracts in C and Rust. The difference between Ewasm and wasm can be considered in the following ways:

Ewasm = Wasm – Uncertainty (floating point) + metering + EEI method (for interaction with Ethereum).

Ethereum will join queues for projects such as Polkadot, Cardano, EOS, Tron, Spacemesh and NEAR, which have or are using Wasm.

Ewasm vs EVM

From the beginning, EVM was designed to emphasize correctness rather than efficiency. This reflects the fact that all nodes on the network must run EVM completely accurately. Although Wasm is similar to EVM, it was invented for the web. Unlike correctness, Wasm emphasizes efficiency and fast loading . Ethereum developer Lane Rettig said that the creation of EVM does not have "a lot of design ideas". He thinks that EVM is designed from a theoretical rather than a practical perspective. Therefore, although it is sound inside, it cannot be used most in the real world. Good role. Nick Johnson agrees with this view. By contrast, Wasm is written closer to the actual hardware instructions, which makes it more efficient when translating actual coding logic. In fact, the Wasm instruction can directly map one-to-one to the instructions used by the machine, which will greatly improve performance.

4, 1 speed and efficiency increase

One of the most important outcomes of the transition from EVM to Ewasm is the dramatic increase in speed and efficiency. Ewasm will increase transaction throughput by significantly increasing the number of transactions per second that can be processed and added to each block. It is unclear how much speed Ewasm will bring to Ethereum, but there will be a direct correlation between execution and transaction throughput: if Ewasm is twice as fast as EVM, then it will allow for each block. Add more than twice the deal. This does not mean that the actual block size will increase, but the process of adding data to each block will become more efficient. With the introduction of sharding and layer 2 solutions, Ewasm will help improve the scalability of the Ethereum network.

Lane Rettig compares the EVM to a Swiss army knife: "…it does a lot of things, but it doesn't work well." By contrast, Wasm's design is a practical task and is specific to things like Ethereum. Web application. EVM can't always compile a lot of code efficiently. The browser's javascript engine usually needs to make a lot of guesses to find optimized "hot paths" for certain operations, which can reduce the speed of EVM and reduce the throughput. . In contrast, Wasm can be converted directly from its public representation to compiled code without any guesswork. This is one of many features that allow Ewasm to load and run faster than EVM. Another example is related to the bytecode type used by EVM. Because EVM uses 256-bit bytecode, calculations smaller than 256 bits must be converted to 256-bit format before EVM can process them. Many developers believe that this feature is now redundant, and this will be another feature that makes Ewasm faster than EVM. In an interview with Coinwire, Rettig concluded metaphorically:

“Ethereum is transitioning from a cumbersome homemade tool we ride around the farm to a real car, we will be able to drive on the road…”

An article published by Mozilla agrees with the view that a framework like Ethereum will be able to use Wasm to provide tremendous performance advantages and new features while still enabling Web developers to easily use features.

4, 2 reduce or even eliminate precompilation

Another major benefit of Ewasm is that it reduces or even eliminates the need for precompilation. The so-called precompilation (precompiled contract) is a special bit of the EVM bytecode. If a call is made to a precompiled contract, the EVM will execute the predefined native code and return the result. Precompilation is a generic operation specific to certain protocols (such as signature schemes and hashes) and helps users save on cost of gas. Without these protocols, the cost will be higher. Unlike regular code, EVM only needs to evaluate precompilation, not the entire code at the contract address. Precompilation is required because of the complex cryptographic calculations on the Ethereum network that would result in unpaid high gas costs without them. In some cases, this gas cost may even exceed the block limit, which means that certain operations cannot be processed through the EVM without precompilation. A serious disadvantage of precompilation is that the introduction of new precompilations in the network usually requires a hard fork of consensus, which is often controversial and therefore difficult to implement. Nick Johnson believes that Ewasm is computationally efficient enough to eliminate most current precompilations and replace them with Ewasm contracts. These smart contracts can be simply rewritten and redeployed without the need for hard forks, which makes Ewasm an advantage over EVM. This means that developers can take advantage of Ewasm's increased efficiency to simplify the network, simplify the development process, and avoid hard forks in the new collaboration model.

But like any new system, Ewasm is not without critics. Ethereum developer Greg Colvin is skeptical about the ability of Ewasm smart contracts to eliminate precompilation. He also warned that Ewasm relies on compilers to support multiple languages ​​and could be a single point of failure. However, the vast majority of experts and developers I have contacted do not consider these to be major concerns, and they are excited about the significant performance improvements that Ewasm will bring to the Ethereum network.

4, 3 excellent interoperability

Ewasm's third area of ​​performance over EVM is interoperability, Ewasm will support more languages ​​and will benefit from a broader toolset than EVM. Some prominent examples of additional languages ​​supported by Ewasm include C, C++, and Rust. Ewasm will also receive native support for many well-known JavaScript engines, including but not limited to: Microsoft's Chakra engine (Microsoft Edge), Google's V8 engine (node.js and Chromium-based browsers), and Mozilla's Spidermonkey engine (Firefox and Thunderbird). Ewasm will also get support for multiple non-browser implementations, such as ml-proto (OCaml reference interpreter), wasm-jit-prototype (independent virtual machine using LLVM backend) or wabt (stack-based interpreter). Although Wasm has its own native language that is independent of JavaScript, it is not intended to be an alternative. Instead, its purpose is to work with JavaScript, allowing developers to take advantage of both languages ​​and avoid their weaknesses. In addition to being compatible with more languages ​​and engines, Ewasm is built according to World Wide Web standards, which means it is easy to support Ethereum Light Client in the browser. Ewasm will also benefit from a wider range of tools and compilers than EVM. Since Wasm has been used by a large number of projects outside of Ethereum, it has a larger and more active developer community than EVM, which leads to better tool choices. Therefore, Wasm includes a variety of toolchains that can be used to issue opcodes from several different compilers. They can compile C code and Rust code. Contributors from the ethdev Red Dice Forum believe that one of the main goals of converting to Ewasm is to "use existing tools instead of trying to convince people to build tools for EVM." Therefore, the tool Ethereum is more mature and Another way to benefit from the widespread use of Wasm's transition.

Overall, the expected conversion of Ethereum from EVM to Ewasm will bring a series of exciting new performance upgrades and other advantages. This includes speed and efficiency improvements, superior interoperability, and reduced or eliminated precompilation.

Special thanks to Lane Rettig for his factual review of this article and some good suggestions!

related articles:

1. "Solidity Bytecode and Opcode Basics." https://medium.com/@blockchain101/solidity-bytecode-and-opcode-basics-672e9b1a88c2

2. "Stack based vs Register based Virtual Machine Architecture, and the Dalvik VM." https://markfaction.wordpress.com/2012/07/15/stack-based-vs-register-based-virtual-machine-architecture- And-the-dalvik-vm

3. "Ethereum Virtual Machine Explained." https://www.mycryptopedia.com/ethereum-virtual-machine-explained/

4. "Ethereum EVM Illustrated: exploring some mental models and implementations." https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

5. "Ethereum 2.0." https://medium.com/rocket-pool/ethereum-2-0-76d0c8a76605

6. "ewasm Design Overview and Specification." https://github.com/ewasm/design.

7. "Web Assembly Concepts." https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts

8. Lane Rettig, core contributor to Eth 2.0.

9. "eWASM Replaces the Heart of Ethereum." https://www.coinwire.com/ewasm-replaces-the-heart-of-ethereum

10. "Trying to understand the EVM and eWASM." https://www.reddit.com/r/ethdev/comments/87rrt6/trying_to_understand_the_evm_and_ewasm/

11. "Ethereum Virtual Machine (EVM) To Be Replaced By EWASM Making The Ethereum Network Smarter And Stronger." https://xbt.net/blog/ethereum-blog/ethereum-virtual-machine-evm-to-be-replaced -by-ewasm-making-the-ethereum-network-smarter-and-stronger/

12. “On Adding Precompiled Contracts without Hard Forks.” https://that.world/~classic/2017/09/14/nonfork-precompiled/

13. "A Prehistory of the Ethereum Protocol." https://vitalik.ca/general/2017/09/14/prehistory.html

We will continue to update Blocking; if you have any questions or suggestions, please contact us!