At the heart of ethereum lies a virtual computer.

Stored across tens of thousands of nodes that make up the platform, the ethereum virtual machine, or EVM, is responsible for executing the countless tokens, dapps, DAOs and digital kittens of which the blockchain is comprised of.

It’s an engine on top of which the entirety of ethereum operates, and it speaks in a language named “EVM bytecode” — raw, 256-bit strings of information that can deliver any conceivable equation (providing it falls within the platform’s self-imposed limit, gas).

Sounds powerful and important huh? Something not to be messed with too much?

Yet, that integral part of ethereum’s infrastructure is gearing up for a complete rewrite.

“I would make the case there wasn’t an enormous amount of design thinking put into it at the beginning,” Lane Rettig, an ethereum developer, told CoinDesk about the EVM. “It was kind of like a tool – a swiss army knife is the way I would describe it – it does a bunch of things but not incredibly well.”

As such, the current EVM will be replaced by a new virtual machine called eWASM.

EWASM is just ethereum’s version of the WASM (which stands for WebAssembly) code, created by the World Wide Web Consortium (W3C), the team of developers responsible for maintaining and standardizing the web.

“There are many highly paid, very experienced engineers, and many thousands of professional engineer hours that went into the conception of [the WASM] construction set – compared to EVM,” Rettig, who contributes to eWASM development, said.

Indeed, eWASM will allow developers to code in multiple programming languages — not just the ethereum-specific language, Solidity — and is said to come with a host of performance enhancements as well.

And leading credence to the decision, ethereum will join several competitors, including EOS, Tron and Cardano, who have each deployed (or plan to deploy) project-specific virtual machines to handle decentralized computation using the WASM code.

For ethereum, the switch is set to execute alongside a couple other updates now nicknamed “Shasper,” which includes scaling solution sharding and mining rewrite Casper, in the next few years. And while an exact timeline for the switch isn’t fixed, eWASM development is making rapid progress, and is gearing up to the launch of its testnet at Devcon 4, the ethereum developer conference, in Prague in October.

Speaking to the decision to replace the existing machine, Rettig summarized:

“Ethereum is at the point where it’s transitioning from a clunky homebrew custom build job that we’ve been riding around our farm to a real racecar that we can take out on the highway and open up.”

A ‘warty’ way

Underlying the switch is the realization that while the EVM is an innovative technology — for the first time, providing a solution to attack-resistance decentralized computation — it’s not as clean as it could be.

Case in point, most dapps developers program in ethereum’s Solidity, a high-level programming language which automatically compiles into an EVM bytecode compatible form.

Because the EVM relies on “very large, wide instructions,” Rettig said, even the smallest kinds of computations, such as basic arithmetic, would need to be converted into 256-bit strings – a complex process for simple math – for the EVM to process them.

This is just one of several operations built into the system code that Rettig contends shouldn’t be there. Another includes the popular hash function SHA-3.

Because of this, Rettig describes the EVM as “warty.”

And Nick Johnson, an ethereum core developer, agreed, telling CoinDesk that when he joined ethereum, it was immediately obvious to him that the EVM was built by developers with a deep understanding of computer science, but without much experience building broadly useable products.

As a tool, Johnson emphasized, the EVM has been “optimized for theoretical purity, rather than practical use.”

“It has these enormous registers, but they’re all the same, and it’s very internally consistent and so on,” he said, “but it’s not built with real-world implementation in mind.”

‘Closer to the metal’

The WASM code, on the other hand, was built with production in mind.

For one, Rettig said, it’s built “closer to the metal,” meaning that the code it runs is close to actual hardware instructions, so there’s less effort spent on translating different coding logics.

“The instructions very closely mimic actual hardware instructions,” Rettig continued. “These instructions can map one-to-one directly to the instructions the actual devices run, so you can, in theory, get pretty exciting performance improvements.”

For instance, developers building on ethereum will be able to code using multiple languages – whatever they’re most comfortable with – including those with additional security benefits.

Another key advantage — which Rettig said some developers are citing as the “key motivation behind eWASM” — is that it potentially does away with what is called a “precompile.”

Because the EVM is comprised of unwieldy code, certain operations need to be built inside the system — otherwise, the operations would exceed the gas costs associated with them. Called precompiles, to make such operations available on a network, a system-wide upgrade, or hard fork, is required; and such upgrades have proved risky and complicated to orchestrate.

With eWASM, though, developers maintain that operations can simply be written as smart contracts and deployed, skipping the hard fork scenario.

“With eWASM, it’s efficient enough at doing compute stuff that most of those precompiles could be done away with and replaced with just eWASM contracts,” Johnson said.

Broken heart

Still, like any substantial change in a decentralized ecosystem, the push to deprecate the EVM is not without its critics.

For one, ethereum core developer Greg Colvin, who’s been devoted to the EVM’s upkeep for years, is reluctant to let the old code go.

Colvin had been designing a newly improved version of the EVM code himself, named EVM 1.5, which was originally intended to be the future of the ethereum virtual machine. However, without warning, his funding was cut by the non-profit Ethereum Foundation.

“I was pissed,” Colvin, who helped form the Council of Ethereum Magicians, a discussion group devoted to furthering the technical proficiency of ethereum, after the experience, told CoinDesk. “I was like wait a minute, you won’t pay me $8.40 an hour when you’ve already decreased my hours to 20 from 35, so why am I doing this. And then for the rest of the year I could no longer afford to volunteer time.”

Yet, Colvin’s reason for opposing aWASM isn’t only pride.

According to him, there are technical issues with eWASM as well. For example, because eWASM allows multiple language support, the code relies heavily on what is known as “compilers” — something that Colvin maintains could be a single point of failure for attackers.

He’s also unconvinced that eWASM smart contracts could replace the need for precompiles.

Plus, Colvin has further design-orientated critiques that even Rettig agrees with. According to both the developers, for some reason more inefficient tech usually wins out. Take Javascript for example, which is one of the most widely used programming languages, but is known for being particularly ugly.

“There seems to be a pattern in technology and computer science where the best-designed things, not only do they not necessarily win, but they seem to not do very well,” Rettig argued.

Not to mention, according to Colvin, for all the development work behind WASM, the code is still relatively untested in the wild.

Colvin told CoinDesk:

“I didn’t understand why we wanted to be early adopters of an experiment, when we were already early adopters of our own experiment.”

Unpredictability

Conflicts aside, eWASM is gaining steam among many ethereum developers.

Indeed, the plan planning is to deploy it as a testnet prior to the ethereum developer conference, Devcon4, in November.

Yet, that doesn’t mean the new virtual machine will get deployed any time soon.

Because eWASM will first be brought out on a shard, or a sidechain, before replacing the EVM itself, the rollout of eWASM is closely bound to the Shasper upgrade. And in terms of timing, that means developers will need to attend to the research that underpins those changes, before moving on to eWASM.

Unfortunately, the progress of such research can be unpredictable.

Indeed, the ambiguity involved with code upgrades of this sort has been a source of confusion for a wide group of ethereum developers building on the platform.

“If you’re in the process of building a new client there’s a lot of confusion: Should I be building eWASM? Should I be building EVM? Should I be building both? Should I be building something else,” Rettig told CoinDesk.

The lack of clarity was one of the key frustrations for Colvin, because when it comes to the current EVM, there are some performance issues that would be easy to improve on, yet those have been side-barred by the sudden shift in the roadmap.

“It’s been a frustration of mine for a while, eWASM was clearly over the horizon, but without too much resources EVM 1.5 was on the near horizon. And now, it’s still doable, but it got pushed, a whole year got wasted,” Colvin told CoinDesk.

The more, the merrier?

Still, both Rettig and Colvin admit that this uncertainty is just a part of contributing to an open-source project without any central leadership.

“The community aspect is so important. If this was a company I’d be long gone,” Colvin told CoinDesk.

Plus, Rettig was quick to argue that when it comes to ethereum improvements, there’s no wasted work.

Indeed, he continued, because of the nature of the sharding upgrade — which splits ethereum up into smaller, more manageable chunks — multiple virtual machines could eventually be supported on ethereum.

On an updated ethereum, Rettig said, “There is no single ethereum, there is no single roadmap, there is no single authority, it’s a community, it’s a family of technologies, and I do not believe that the future is just one chain to rule them all.”

In line with that, eWASM will unlock new levels of interoperability as well. For one, it’s built in a language that has been standardized for the World Wide Web, so adding in-browser support for an ethereum light client would be trivial.

And it could pave the way for undiscovered interoperability between different blockchains as well.

“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.”