By Colin Schwarz | Chainsafe Project Manager.
Translator | Free and easy xi
Original link | www.8btc.com/article/473…
This article explores the Ethereum Virtual Machine (EVM) and Ethereum WebAssembly (eWasm), which will replace EVM as the state execution engine for the Ethereum 2.0 network. This transformation will bring a series of exciting new performance upgrades and other benefits to Ethereum. These include improvements in speed and efficiency, superior interoperability, and the reduction or elimination of precompilation.
1. What is EVM?
To understand eWasm and its impact on the Ethereum network, we must first become familiar with the Ethereum Virtual Machine (EVM) it will replace. EVM is a lightweight virtual machine designed to run smart contracts on the Ethereum network. As a VIRTUAL machine, EVM functions slightly differently from traditional operating systems such as Windows. In general, a virtual machine (VM) is a high-level abstraction built on a native operating system that simulates a physical machine. 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. Built to simulate operations that can be performed by physical cpus, EVM is also responsible for many of Ethereum’s key functions.
In addition to being a virtual machine, EVM is also a “stack machine” and a “state machine” (pardon the adjectives, I know). A state machine is simply a machine that can read inputs and transform them into new states based on those inputs. Stack-based virtual machines are virtual machines that organize memory structures into stacks and access them as stacks. This is in contrast to register-based virtual machines, where the memory structure is stored in the REGISTERS of the CPU. To perform operations on a stack-based virtual machine, data called Operand is “popped” off the stack, processed by receiving operations, and then “pushed” back onto the stack on a last-in, first-out (LIFO) basis. Adding using a stack-based machine works as follows:
POP 20
POP 7
ADD 20, 7, and the result
PUSH result
Markfaction.wordpress.com/2012/07/15/…
A major advantage of using a stack system is that 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 EVM improve efficiency and reduce storage requirements.
In addition to the stack, EVM can store data to memory (RAM) and disk storage. Sending data to disk storage requires the most Gas and sending data to the stack requires the least Gas. EVM decides where to send some data based on its intended use and expected Gas costs.
At the macro level, EVM consists of World State, machine State, and virtual ROM. The world state is the store of all accounts on the network, while the machine state includes program counters, available Gas, stacks, and memory. Virtual read-only memory (ROM) is immutable “EVM bytecode,” a special language that only EVM can understand. It is important to understand bytecodes and their relationship to high-level languages such as Solidity in order to fully grasp EVM’s capabilities.
Since the web’s inception, Ethereum developers have written code in Solidity programming language, which is a “high-level” programming language, meaning that while developers can understand Solidity, machines can’t. In order for the computer to understand the Solidity code, it must compile using 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 it is important that the compiler exists to allow a developer’s expression to be understood by EVM.
2. What does ethereum Virtual Machine (EVM) do?
EVM is responsible for facilitating most transactions and operations on the Ethereum network, including executing smart contracts. It is responsible for the various data structures containing instructions and operands, as well as the data processed by the instructions. EVM also includes an instruction scheduler or “virtual GPU” for retrieving and executing instructions and decoding operands. In other words, EVM is responsible for tracking network components such as world state, storage state, 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 perform specific transactions. This information includes:
Gas price: “the current Gas price specified by the transaction sponsor”. Code size: “Size of the transaction code base”. Caller: “Address of the account executing the transaction.” Origin: “Address of the original sender of the transaction”.
Finally, in addition to these responsibilities, EVM handles account information related to block numbers, Gas prices, addresses, and balances. Because EVM is responsible for many important functions on the Ethereum network, the speed at which it can process operations and transactions affects 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.
As a result, the increased workload on the Ethereum network in recent years has made EVM itself a bottleneck, often reducing network throughput and increasing transaction times. Inefficiency was one of the main reasons for ethereum’s transition 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 is being actively developed by engineers from Mozilla, Google, Microsoft, and Apple.
EWasm (WebAssembly for Ethereum) is a “limited Wasm subset” modified specifically for the Ethereum network, and 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 take advantage of common hardware features and execute at “near native speed.”
The software is also designed to be easy to read and debug through a human-readable text format that allows developers to view, write, and debug code by hand. Finally, Wasm is designed to be secure and highly compatible by enforcing host browser permission policies and by maintaining backward compatibility. The team that created eWasm also had several more specific project goals, one of which was to provide an EVM translator and a Metering Injector, preferably as an eWasm contract. Another goal is a clear specification of the semantics of ethereum interfaces and eWasm contracts.
Finally, the team aims to implement an eWasm backend for the Solidity compiler, with 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 interacting with Ethereum).
Ethereum will join projects such as Polkadot, Cardano, EOS, Tron, Spacemesh, and NEAR protocols that have adopted or are currently adopting Wasm.
4. eWasm vs EVM
From the beginning, EVM was designed to emphasize correctness over efficiency. This is reflected in the fact that all nodes on the network must run EVM exactly.
Wasm, while similar to EVM, was invented for the Web. In contrast to correctness, Wasm emphasizes efficiency and fast loading. Ethereum developer Lane Rettig says EVM wasn’t created with “a lot of design thought”, arguing that IT was designed from a theoretical rather than a practical point of view and therefore, while internally sound, doesn’t work best in the real world. Nick Johnson agrees that Wasm, by contrast, is written more closely to actual hardware instructions, which makes it more effective at translating actual coding logic. In fact, Wasm instructions can be mapped directly one-to-one to instructions used by the machine, which makes performance much better.
4.1 Significant improvement in speed and efficiency
One of the most important results of the transition from EVM to eWasm is a significant 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 of a speed boost 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, it will allow twice as many transactions to be added to each block. This does not mean that the actual block size will increase, but that the process of adding data to each block will become more efficient. With the introduction of sharding and Layer 2 solutions, eWasm will help increase the scalability of the Ethereum network.
Lane Rettig compares EVM to a Swiss Army knife: “… It does a lot of things, but it doesn’t work well.” Wasm, by contrast, is designed to be practical first and foremost, and specifically for Web applications like Ethereum. EVM does not always compile large amounts of code efficiently, and the browser’s JavaScript engine often requires a lot of guesswork to find an optimized “Hot Path” for operations that slow DOWN EVM and reduce throughput.
Wasm, by contrast, converts directly from its common representation to compiled code without any guesswork. This is one of the many features that allow eWasm to load and run faster than EVM. Another example has to do with the type of bytecode used by EVM, because EVM uses 256-bit bytecode, so calculations less than 256 bits must be converted to 256-bit format, and EVM processes them. Many developers feel that this capability is now redundant, and that this will be another feature that makes eWasm faster than EVM.
Rettig metaphorically summed it up in an interview with Coinwire: “Ethereum is transitioning from a clunky homemade tool we ride around our farms to a real racing car that we’ll be able to drive on the road…” Mozilla published an article that echoed the belief that frameworks like Ethereum would be able to use Wasm to provide significant performance benefits and new functionality, while still making it easy for Web developers to use functionality.
4.2 Reduce or eliminate precompilation
Another major benefit of eWasm is that it can reduce or even eliminate the need for precompilation. The so-called precompilation (precompilation contract) is a special bit of EVM bytecode. If a call is made to a precompiled contract, EVM executes pre-defined native code and returns results. Precompilation is a generic operation that is specific to certain protocols (such as signature schemes and hashes) and helps users save Gas costs that would be higher without these protocols.
Unlike regular Code, EVM only evaluates pre-compiled Code, not the entire Code at the contract address. Precompilation is required because the various complex cryptographic calculations on the Ethereum network would result in high Gas costs without them. In some cases, this Gas cost may even exceed the block limit, meaning that certain operations cannot be processed by EVM without the use of precompilation. A serious drawback of precompilation is that introducing new precompilation into the network usually requires a consensual hard fork, which is often controversial and therefore difficult to implement.
Nick Johnson believes that eWasm is computationally efficient enough to eliminate most of the current precompilation and replace it with an eWasm contract. These smart contracts can be easily rewritten and redeployed without using hard forks, which gives eWasm an advantage over EVM, meaning that developers can take advantage of eWasm’s increased efficiency to simplify networks, streamline development processes, and avoid hard forks in new collaboration modes.
But as with any new system, eWasm is not without its critics, with Ethereum developer Greg Colvin being skeptical of eWasm’s smart contract’s ability to eliminate precompilation. He also warned that eWasm’s reliance on compilers to support multiple languages could be a single point of failure. However, the vast majority of experts and developers I’ve spoken to don’t see these as major concerns and are excited about the significant performance improvements eWasm will bring to the Ethereum network.
4.3 Excellent interoperability
The third area where eWasm outperforms EVM in terms of performance 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 from a number of well-known JavaScript engines, including but not limited to: Microsoft’s Chakra engine (Microsoft Edge), Google’s V8 engine (Node.js and The Chromium-based browser) and Mozilla’s Spidermonkey engine (Firefox and Thunderbird).
EWasm will also be supported by multiple non-browser implementations such as ML-PROto (OCaml reference interpreter), WASM-Jit-Prototype (standalone virtual machine using LLVM back end), or Wabt (stack-based interpreter). Although Wasm has its own JavaScript independent native language, it is not intended as a substitute. Rather, it is intended to work with JavaScript, allowing developers to take advantage of both languages’ strengths and avoid their weaknesses.
In addition to being compatible with more languages and engines, eWasm is built to World Wide Web standards, which means it’s easy to support Ethereum light clients in browsers. EWasm will also benefit from a wider range of tools and compilers than EVM. Since Wasm is already used by a large number of projects outside ethereum, it has a larger and more active developer community than EVM, which leads to better tool choices.
Therefore, Wasm contains toolchains that emit opcodes from several different compilers. They can compile C code, Rust code, etc. Contributors from the Reddit subboard forum Ethdev believe that one of the main goals of switching to eWasm is to “leverage existing tools, rather than trying to convince people to build tools for EVM.” Thus, tools are another way ethereum can benefit from the transition to the more mature and widely used Wasm.
Overall, ethereum’s expected transition from EVM to eWasm will bring a number of exciting new performance upgrades and other benefits. These include improvements in speed and efficiency, superior interoperability, and the reduction or elimination of precompilation.
Special thanks to Lane Rettig for fact-checking this article and making some great suggestions!
Related articles:
1. “Solidity Bytecode and Opcode Basics.” medium.com/@blockchain…
2. “Stack-based vs Register Based Virtual Machine Architecture, And the Dalvik VM. “markfaction.wordpress.com/2012/07/15/…
3. “Ethereum Virtual Machine Explained.” www.mycryptopedia.com/ethereum-vi…
Ethereum EVM Illustrated: Exploring some Mental Models and Implementations. “Takenobu-hs.github. IO /downloads/e…
5. “Ethereum 2.0.” medium.com/rocket-pool…
6. “eWasm Design Overview and Specification.” github.com/ewasm/desig… .
7. “Web Assembly Concepts.” developer.mozilla.org/en-US/docs/…
8.Lane Rettig, core contributor to Eth 2.0
9. “eWasm Replaces the Heart of Ethereum.” www.coinwire.com/ewasm-repla…
10. “Trying to understand the EVM entry and eWASM.” www.reddit.com/r/ethdev/co…
“Ethereum Virtual Machine (EVM) To Be Replaced By EWASM Making The Ethereum Network Smarter And Stronger.” Xbt.net/blog/ethere…
“On Adding Precompiled Contracts without Hard Forks.” That. World /~classic/20…
“A Prehistory of the Ethereum Protocol.” Vitalik.ca/General /201…
About Patract
Patract provides solutions for parallel chain and DApp development in boca’s Wasm contract ecosystem. We help the community design and develop on-chain contract module and Runtime support, and provide DApp developers with a full stack of tools and services covering the development, testing, debugging, deployment, monitoring, data provisioning, and front-end development phases.
How to join Patract
1. For contract developers, visit the official website (Patract.io) to familiarize yourself with the test chain and tool suite. Element (app.element. IO /#/room/#Pat… Discord (Discord. Gg /wJ8TnTfjcq) Search ** “Patract Open Platform” ** Follow the Patract wechat account
2. For parallel chain projects that will integrate Wasm contract functions, or DApp projects developed using Wasm contract, please contact [email protected] for business cooperation
3. For users, welcome to join: Telegram (t.me/ Patract) Twitter (twitter.com/PatractLabs…
4. For job seekers, we are recruiting blockchain development engineer, front-end/full stack development engineer, developer operation and other positions, you can contact [email protected]