Ethereum’s conception back in 2013 came as a major extension of blockchain technology as a decentralized settlement layer for p2p money into a trustless layer for execution of programs, opening up an entirely new world of applications and programmable money.
Conceptualized as a “global computer”, Ethereum’s core idea is straightforward: to leverage the trust-minimizing nature of blockchain technology for consensus on the output of computer programs. That is, developers can deploy code, known as a smart contract, that is fully deterministic and whose output can be trusted by all parties interacting with it.
All sorts of nifty ideas were proposed since the beginning, including the ability to create fair auctions or lotteries using Ethereum smart contracts, creating prediction markets, decentralized trade exchanges, and more. Among the most notorious of these use cases were the creation of programmable tokens on Ethereum, which were used as a popular means for companies to raise millions of dollars in Initial Coin Offerings (ICOs).
At its core, Ethereum implements a turing complete, virtual machine known as the Ethereum Virtual Machine (EVM for short). Its power comes from defining a common, deterministic instruction set that programs can compile into and computers around the world can run. Every single operation and program that runs on this EVM has to be run by every full-node that is part of the Ethereum network, meaning this “world computer” needs to have a built-in mechanism to stop spam attacks. For this, the EVM implements the concept of gas, which can be thought of as the “fuel” for every basic operation that needs to run on this global computer, paid upfront.
Blockchain Computers Are Deterministic
Being turing complete means you can code and run any program conceivable on the Ethereum Virtual Machine granted you have enough gas to pay for all of its execution steps. Expensive operations, such as training machine learning algorithms, are completely unfeasible in the EVM due to its inherent constraints. Each instruction in the EVM, known as an OPCODE, has a specific, fixed cost. Every OPCODE is deterministic, as agreeing on output of every program on Ethereum is a requirement for reaching global consensus.
By having fixed opcode costs, nodes are able to determine exactly how much money a user will need to pay upfront in fees to execute a certain program. In this case, the concept of gas is not only used as a method of preventing spam attacks but also as a proxy for determinism. For example, a program that costs X gas to run will always cost X gas regardless of which node in the network is executing it. Gas actually has a unit price which is dependent on supply and demand throughout the platform, and is generally quite volatile depending on how loaded the Ethereum network is with transactions.
How is the EVM Designed? Why Is It Inefficient?
Big Architecture Size
Traditional computers contain instruction sets that function on inputs of 32 or 64-bit sizes. The EVM is different and special because it is a 256-bit computer, which was deliberately designed this way due to the ease of dealing with Ethereum’s hash algorithm, which explicitly generates a 256-bit output.
However, computers that actually run EVM programs have to break down its 256-bit words into their local architecture to execute smart contracts, making the entire system quite inefficient and impractical.
Also, good luck if you want to implement a complicated algorithm such as SHA256 on Ethereum using its basic OPCODES! To get around the gas-cost inefficiency of running complicated programs from its instruction set, Ethereum uses the notion of precompiles, which are programs that are baked into the EVM and have a fixed cost. A noteworthy precompile is the Ethereum hashing algorithm, as implementing it in the VM itself would be extremely expensive for any contract to call.
The problem with precompiles is that they keep adding bloat and complexity to a VM instead of fixing the core problem: the inefficiency and poor design of the current instruction set and specification.
What if we could instead define a new spec and instruction set where we don’t have to bake these complicated programs in but can instead be efficient enough to implemented with basic instructions?
What Does This Have to Do With Blockchain?
Instead of relying on the EVM, we now have an excellent, efficient instruction set we can compile all sorts of languages into and be confident it will be equally performant and executable across different types of platforms — ideal for decentralized applications! Moreover, the WASM instruction set can be easily made deterministic by removing floating point instructions, which would make it suitable as a replacement for the EVM.
The WebAssembly efforts are being spearheaded at Ethereum by the brilliant EWASM team, which has been ensuring Ethereum 2.0’s execution layer will be performant, straightforward, and fitting for a truly decentralized, computing platform.
GitHub is where people build software. More than 28 million people use GitHub to discover, fork, and contribute to over…
WASM is already being considered the standard across other projects, including Dfinity and EOS leveraging its power for their execution layers.
The future is quite bright for both the Web’s performance and Smart Contract platform execution layers. Not only will dApps become way more performant in production, but the integration of WASM will also make Smart Contract development more accessible for people already familiar with the robustness of popular languages such as Rust and Go, making it unnecessary to learn the ins and outs of solidity to write useful applications on Ethereum.
In fact, you can already deploy WASM contracts on the Ethereum Kovan Testnet with Parity-Ethereum’s tutorial below:
A step-by-step tutorial on how to write contracts in Wasm for Kovan - paritytech/pwasm-tutorial
Make sure to follow more of the latest developments in WASM and blockchain VM execution — as this is only the beginning.