There’s a lot of hype about smart contracts. And that’s understandable. Trustless agreements enforced by a global computer? It sounds like a concept plucked straight out of a sci-fi novel.

The term itself was first coined by Nick Szabo in the mid-90s, but it wasn’t until relatively recently that advances in decentralized ledger technology brought the abstraction to life.

To an extent, Bitcoin ushered in the first smart contracts – due to its Turing-incomplete nature and fairly restrictive Script language, however, its application remains limited to currency-related use cases. Ethereum made much larger strides with the creation of the EVM, which was set to open up a world of possibilities for developers to write their own programs, contracts, and decentralized applications.

The EVM is far from perfect, though. There are some issues that need to be addressed with the architecture of the virtual machine that forms an integral part of the Ethereum protocol. One that springs to mind straight off the bat is the language it uses Solidity, purpose-built for the platform and relatively simple to use.

The issue with Solidity is unfamiliarity. It’s a new language and has nowhere near the sort of track record and extensive testing that traditional programming languages have. On one hand, people are hailing such a system as the ideal storage platform for all of their most sensitive information, from medical to financial records. On the other, it’s clearly riddled with flaws that result in disaster (such as the DAO and Parity exploits) if not used properly.

Programming on the decentralized plane should really be done using languages we know to be secure. Moreover, developers shouldn’t be limited to just one. I’ve stated before that I’m a big believer in Rust’s forgiving and security-oriented framework, and firmly hold that it should become the go-to language for smart contract scripting. That said, the ideal compiler would support the classics – Java, C, C++ and Go, to name a few.

The EVM relies on a processor using an integer size of 256. For scale, the average home PC uses either a 32 or 64-bit processor. Supposedly, the large size offers better values for cryptographic computations, but as of yet, there remain to be any Solidity projects leveraging this feature – most likely due to the gas cost, which would be extortionate.

I’m of the opinion that there’s a gap to be filled for smart contract engines – why not simply use an x86 virtual machine? Its architecture is extensively used in the computers of today. There’s so many tried and tested tools for it, which would be trivial to port over to a VM on a distributed ledger.

To top it off, there’s the familiarity aspect. Developers know how to write effective code on an x86 system. At the moment, they’re having to dive into programming decentralized applications, without a deep understanding of what they’re programming them with. There’s no need to overcomplicate things that don’t require overcomplication. We’re perfectly capable of building on top of blockchains with the resources we’ve had for decades.