eWASM Ethereum 2.0: A detailed guide

eWASM is one of the many innovations that Ethereum is looking to implement to make its jump to Ethereum 2.0. Many believe that eWASM will help create an ecosystem that’s fast, scalable, and flexible, encouraging developers to build complex smart contracts on top of Ethereum 2.0’s protocol. This comes in addition to the many different aspects of ETH 2.0 which our previous articles on Staking, Sharding, Ethereum Layer-2, zk-SNARKs and much more explains. So, before we go any further, let’s familiarize ourselves with Ethereum 2.0.

Ethereum 2.0, what is it?

Ethereum 2.0 is a series of upgrades that will radically change the protocol, making it more scalable and efficient. So, Ethereum 2.0, what is it? Examples of these upgrades include – Proof-of-stake with Casper Protocol, Sharding, Raiden, Plasma, and Rollups. These changes will be implemented in different Ethereum phases to ensure proper deployment and execution. 

• Phase 0: Beacon chain to initiate a transition to proof-of-stake (POS).
• Phase 1: Initiate sharding.
• Phase 2: Transition from the Ethereum Virtual Machine (EVM) to eWASM Ethereum 2.0

NOTE: We have already covered Ethereum 2.0 and its many innovations in detail. If you want to dig deeper, then we encourage you to give those a read first.

Today, we are going to be focussing on the last phase of this change. If you are a little familiar with Ethereum 2.0, then you should know that the transition from EVM to eWASM is pretty immense. So, before we get into eWASM, let’s first understand what the EVM is.

What is the Ethereum Virtual Machine?

Every decentralized blockchain ecosystem requires a virtual machine to process and execute operations. Bitcoin’s virtual machine is pretty straightforward, as it only needs to deal with transactions. However, things get a little more complicated when you need to deal with Turing-complete smart contracts like Ethereum. So, this brings us to another important question.

Since a smart contract will need to be immutable and still can run through multiple nodes without compromise, what are the main features Ethereum’s virtual machine, sometimes known as EVM, must have?

Well…these features are:

• Determinism
• Terminable
• Isolated

Determinism

A program is deterministic if it gives the same output to the same set of inputs, no matter how many times it executes the code. A perfect example of a deterministic function is classical mathematical operations. Eg. Assuming that all the numbers are to the base 10, 1+4 will always be 5, no matter how many times you repeat this operation.

So, why is this important when it comes to smart contracts? 

Well, because these dApps tend to deal with millions of dollars at a time, the users need to know how the code reacts in each stage of its execution.

Terminable

You must keep in mind that Ethereum smart contracts are Turing-complete. If given enough time and resources, smart contracts should be able to solve any problem. However, it is impossible to tell if a contract will be able to finish all operations in a given time limit or not. This is why smart contracts should have a terminating mechanism. Ethereum smart contracts use “gas” to define a life span. The moment a contract’s gas limit gets over, it stops all operations.

Isolated

Finally, a smart contract should run in a completely isolated environment. If something happens to the smart contract (like a hack or a bug), it shouldn’t affect the rest of the underlying protocol.

There are two systems that a smart contract can use to facilitate these three features. These two systems are – Virtual machines and Docker containers. Since Docker’s contract designs are not deterministic, by default, Ethereum decided to go with virtual machines.

Ethereum Virtual Machine: How does it work?

So what exactly do we mean by “virtual machine?” 

Traditional operating systems like Windows and iOS only need to run on one system at a time. However, VMs are higher-level abstractions that have been created on top of native operating systems to replicate the functioning of a physical machine. 

Speaking of which…. How exactly does an EVM help you?

A VM allows you to run the same platform on several different hardware architectures and operating systems simultaneously. This is why VMs are an excellent fit for a decentralized network like Ethereum. Ethereum’s main aim is to be a global supercomputer that rents out computing resources to developers to build their own smart contracts and decentralized applications.  The EVM pretty much acts like this global computer, accessible by multiple nodes throughout the world.

Stack and State machine

EVM has two more features on top of being a virtual machine. Firstly, it’s a state machine that can read inputs and change its state accordingly. Plus, it’s a stack-based machine, in which the memory structure is organized and accessed as a stack.

If you are familiar with data structures, then you should know what stacks are. Stacks are linear data structures wherein operations are performed using LIFO or Last In First Out.

Consider the following example:

In the stack above, the first piece of data inserted into it was Orange, and the last data piece of data was Apple. So, if we were to take data out of the stack by LIFO logic, the first piece that we retrieve is Apple, and the last one is Orange.

Now, let’s look into stack operations – Push and Pop.

• Push: The act of adding data into the stack.
• Pop: The act of removing items from the stack using the LIFO method.

Stack operations on EVM

In a stack-based VM, the operations get executed like this:

• The data and operands first get popped out.
• The corresponding operation is performed.
• The result gets pushed back onto the stack.

Look at the following diagram:

• We pop out the first two numbers – 20 and 7.
• The two numbers are then added, giving us 27.
• Finally, the result is pushed back onto the stack.

Advantages of EVM’s stack-based system

• The stack structure ensures that the EVM doesn’t need to know the exact address of the operands. The stack structure will always inevitably point the VM to the next operand. This removes the substantial operational overhead and increases overall efficiency.
• The EVM has – the world state, machine state, and virtual ROM. The world state stores all the accounts in the network, the machine state includes data like program counter, gas available, stack, and memory. Finally, the virtual ROM reads the machine-level code called “EVM bytecode.” This is a unique language that only the EVM can understand.

EVM – Reading the bytecode

Programming languages can either be high-level or low-level. Low-level languages like bytecode are easily readable by machines, but it’s hard for humans to work with them. This is the reason why most programming languages are high-level. So, how exactly does a program flow work in smart contracts?

• The solidity/vyper contract gets compiled into bytecode. The compiler used here is called “solc.”
• The bytecode gets read and processed by the network.
• The bytecode is the binary representation of solidity opcodes. The compilers are a critical component of the whole exchange since the EVM will not understand any other language except the bytecode.
• Each opcode is given a human-readable name in the specification and gets represented by a numerical code. For example, the number 0X01 represents the ADD opcode.

Ethereum Virtual Machine: Functionalities

• The EVM is the decentralized processing unit of the entire Ethereum network. Each and every transaction, interaction, smart contract execution can only happen via EVM.
• It is responsible for all the different data structures, including instructions, operands, and data processed.
• The EVM fetches and executes the instruction and decodes operands through an instruction dispatcher.
• The EVM also keeps track of network components like World State, Storage State, and Block Information.
• Create a Runtime Environment for smart contracts on the Ethereum network. This environment includes information used to execute specific transactions like – Gas price (current gas price), Codesize (size of the transaction coinbase), Caller (transaction receiver address), and Origin (transaction sender address).

The problems with Ethereum Virtual Machine

For all its amazing functionalities, there are four major problems with EVM that limits the overall throughput of the network:

• As the EVM has to process so many different and diverse operations, the EVM isn’t as fast as it should be. EVM’s opcode specification hasn’t changed with time and isn’t optimized for different hardware platforms.
• Extending on the first point, since the EVM has to conduct so many various operations, it tends to become an operational bottleneck. As you can imagine, this dramatically affects overall network efficiency.
• The EVM hasn’t evolved much from its initial specification. This is why the tool and language support required for writing contracts are extremely limited.

It’s pointless to bring in all these fantastic innovations like sharding, rollups, Casper if the base working environment itself is hugely flawed. These problems are the exact reasons why Ethereum is looking to move on from EVM to eWASM. So, before we get into eWASM, let’s understand what WebAssembly is.

eWASM Ethereum 2.0: What is WebAssembly (WASM)?

WebAssembly has gained a lot of attention recently. Created and defined by the  World Wide Web Consortium (W3C), WebAssembly is a new type of code that can efficiently execute in modern browsers.

So, what makes it so unique?

Since WASM has a stack-based, low-level binary format that’s small by default, it can load and execute quickly. The moment your browser downloads a WASM code, it can quickly turn it into any machine’s assembly. 

WebAssembly advantages

• It is supported by multiple JavaScript engines and runtime environments that make it executable in most modern browsers.
• Languages like Go, Rust, and C/C++ can already compile directly into WASM.
• Quickly adapts to any machine-level architecture making it extremely high-performing.
• Comes with an instruction set that’s compatible with most modern hardware architectures.
• Runs close to native speed on most platforms.

eWASM Ethereum 2.0: An Introduction

As you may have figured out by now, eWASM or Ethereum WebAssembly is Ethereum 2.0’s version of WebAssembly. As per the team: 

eWASM = WASM – nondeterminism (floating point) + metering + EEI methods (used to interact with Ethereum).

Speaking about the eWASM team, they have laid out the following as their specific design goals:

• Create an EVM transcompiler and a metering injector as an eWASM contract.
• A clear and well-documented specification of the Ethereum interface and the eWASM contract semantics and finer details.
• Create an eWASM backend for the solc compiler.
• Provide instruction and a library for writing smart contracts in C and Rust.

By implementing eWASM, Ethereum will join projects like EOS, Tron, Cardano, etc., who have already adopted or are in the process of choosing WASM.

eWASM vs EVM

EVM’s primary purpose was to ensure correctness, even if it came at the expense of efficiency. Lane Rettig, an Ethereum developer, believes that the EVM was created theoretically, rather than practically, since it doesn’t seem ideal for real-world application. Every single node in the EVM has to run with complete accuracy. On the other hand, WASM emphasizes efficiency and speed as it has been built for real-world usage, which it achieves by easily translating actual coding logic. 

Now that we have a base understanding let’s get into the details.

eWASM vs EVM #1: Speed

Simply put, EVM is a jack-of-all-trades and a master-of-none. For example, let’s look at how it deals with code compilation. 

EVM often struggles with compiling a large volume of code. A browser’s native JS engine often struggles with finding the optimal path of execution for certain operations, which can have a drastic effect on the EVM’s overall throughput. Plus, EVM can only process 256-bit bytecodes, which is why bytecodes smaller than this size must be converted to a 256-bit format before it can be fed into the EVM. 

Due to the EVM’s design, Ethereum suffers from a severe speed and scalability, allowing it to process just 25 transactions per second. As such, it is very impractical for both real-world and real-time usage.

On the other hand, eWASM can transition directly into compiled code, enabling it to load faster and significantly increase the number of transactions that are processed by each block. This, in conjunction with sharding and layer-2 solutions, should increase Ethereum 2.0’s speed by a significant amount.

eWASM vs EVM #2: Precompiles

eWASM can altogether remove Ethereum’s dependence on precompiled contracts or “precompiles.” These precompiles are unique bits of EVM bytecodes, making efficient cryptographic computations without consuming a tremendous amount of gas. Most of the time, it is impossible to create a contract within acceptable gas limits without calling a precompile.

However, they are not without their problems. Introducing new precompiles often requires the network to do a system-wide hard-fork. As history has taught us, hard-forks can be contentious to the extent that it can split up the entire community.

eWASM, on the other hand, can be so gas-efficient that it can render the majority of the precompiles completely and utterly redundant.

So, what does this mean?

eWASM empowers developers to create smart contracts that are fast and efficient without worrying about potential hard-forks.

eWASM vs EVM #3: Flexibility

Finally, let’s look into one of the most significant advantages that eWASM has over standard EVM – code flexibility. Previously, Ethereum developers had to learn solidity to create smart contracts. This created a knowledge bottleneck as developers were expected to go through a specific learning curve. 

However, as we have already seen, eWASM is interoperable with several different languages and has a more extensive developer toolkit. Languages supported by eWASM include C, C++, and Rust.

eWASM enjoys native support from all the major JavaScript engines like:

• Microsoft’s Chakra engine (Microsoft Edge)
• Google’s V8 engine (Node.js and Chromium-based browsers)
• Mozilla’s Spidermonkey engine (Firefox and Thunderbird)

eWASM also supports the following non-browser implementation:

• ml-proto, the OCaml reference interpreter.
• wasm-jit-prototype, an LLVM backend-using standalone VM.
• wabt, a stack-based interpreter.

eWASM also opens you up to the following benefits that were earlier not possible with EVM:

• It will be simpler to get in-browser support for Ethereum light clients since eWASM is built according to the World Wide Web standards.
• eWASM has more compilers and a wide variety of developer tools.
• Since a wide variety of projects is already using eWASM, it has already attracted a healthy and diverse developer community.

eWASM Ethereum 2.0 Conclusion: Will this push Eth 2.0 to a whole new level?

There is a lot of excitement in the community around eWASM. Unfortunately, this often leads to a lot of unneeded hype. Greg Colvin, a seasoned Ethereum developer, is a little skeptical about eWASM smart contracts on two fronts:

• Colvin doesn’t believe that eWASM will not be able to eliminate precompiles.
• He also feels that eWASM’s over-reliance on compilers can create a single point of failure.

However, a vast majority of the Ethereum developer base believes that eWASM will have a seismic effect on the protocol’s overall performance and throughput. How will it actually turn out?

Well…we will have to wait and see.

However, if you want to familiarize yourself with Ethereum and smart contracts, you don’t need to wait. Check out our blockchain courses and familiarize yourself with smart contracts and coding before Ethereum 2.0 rolls out eWASM. We hope you gained immense value from this, can finally answer the question “Ethereum 2.0 what is it”, and make sure to check out the rest of the articles in our Ethereum 2.0 series!