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