Ethereum is more than a currency. At the centre of it lies a super virtual computer. Its power is distributed across tens of thousands of nodes which work cooperatively to create the platform. The Ethereum Virtual Machine is responsible for the execution of the functions of multiple tokens, DApps and DAOs its blockchain is comprised of.
Its engine on which Ethereum operates speaks a language called EVM bytecode. EVM bytecode is a series of raw 256 bit strings of information that can contain any conceivable algorithm or function providing it remains within the platforms self-imposed limitations, this is regulated through “gas”.
This part of the Ethereum infrastructure is preparing for a complete rewrite. There are plans to replace the EVM with a new virtual machine known as eWASM. eWASM is Ethereum’s implementation of WASM or WebAssemby code. It was created by the Word Wide Web consortium, who are a team of developers responsible for maintaining web standards.
eWASM will allow developers to produce code using a multitude of programming languages, not just Solidity, the Ethereum specific language. There are a range of proposed performance enhancements as well.
Ethereum will join several of its competitors such as EOS, Tron and Cardano in deploying project specific virtual machines to handle WASM code.
The ethereum switch will occur in parallel with a few other updates currently known as “Shasper”. These changes will include a scaling, sharding and mining rewrite known as “Casper”. Exact timelines are yet to be decided but rapid progress is being made and a testnet implementation of the rewrite at Devcon 4 in Prague in October.
These changes are intended to transition Ethereum from a clunky homebrew custom build job to a truly powerful, scalable, enterprise level solution. Whilst the EVM is an amazingly innovative technology its solution to attack resistance decentralized computation is not as clean as it could be.
Currently DApps programmed using Solidarity are automatically compiled into an EVM bytecode compatible form. EVM relies on large and wide instructions. Even the smallest computational instructions need to be converted into 256-bit strings, often making even the smallest computational tasks bulkier than they need to be. This can create issues when attempting to make products that are broadly usable, although they are technically correct. The EVM is optimized for technical purity and not for practical use. It is at its core internally consistent but the EVM has not been built with real world implementations in mind.
WASM code is designed with production in mind. The code it runs is more in tune with the hardware used, mimicking actual hardware instructions. As a result, less computational power is used translating different coding logic and potentially providing exciting performance enhancements.
eWASM will allow Ethereum developers to use the programming language they are most comfortable with, or the one that is most appropriate for a specific application. eWASM will also remove the need for a precompile. As the code is precompiled certain operations need to be built into the fabric of the system otherwise the gas cost of executing such operations would make many projects non-viable. Implementing new functionality on a network wide level is a risky and complex thing to do, it would probably result in a hard fork. With eWASM operations can be written as smart contracts removing the need for a hard fork.
Not everyone is happy with the concept of the eWASM upgrade. Greg Colvin is an Ethereum core developer. He has been actively involved in the maintenance of the EVM and is reluctant to see it deprecated.
Colvin had been working on a new and improved version of EVM named EVM 1.5. The Ethereum Foundation cut his funding without warning before he was able to complete his improvements.
Colvin’s opposition is not just a matter of personal pride. He has claimed that there are technical issues with the eWASM as well. It isn’t the panacea that it is being marketed as. He believes eWASMs multiple language support means an increasing reliance on compilers. This could create a single point of failure attack vector for a potential attacker.
He also remains sceptical of eWASMs smart contracts replacing the need for precompiles. Whose solution will win out in the long term remains to be seen. There is a recurring theme in software developments where the more inefficient tech often wins the adoption race.
This uncertainty creates a quandary for developers. Should they be building applications for eWASM or for EVM? Should you support both – or should you look somewhere else completely to support your product? This unfortunately is a natural part of contributing to an open-source project with no central leadership. The hive mind of Ethereum developers is both a strength and a weakness of the project.
There is no one single vision of what Ethereum is, there can be no one roadmap. Developments occur organically and in an evolutionary fashion. Ethereum will probably hard fork several times as people’s ideas differ. It may well be better for all if there is no one chain to rule them all.
eWASM has been built in a language that has been standardized for the web. Adding in browser support for an Ethereum light client would be an easy addition. These blockchains could continue to interoperate, possibly in unique and unconsidered ways.
Lane Rettig is an independent Ethereum core developer and a member of the eWASM team. He has been quoted as saying:
“Maybe you have quadratic sharding over here, and Plasma over here, and maybe they overlap in places, and maybe we have a Dfinity chain talking to an ethereum chain talking to bitcoin through Cosmos and Polkadot,” Rettig said, suggesting:
“We just don’t know, so don’t get so caught up in the official canonical roadmap, whatever that may be.”