Why Smart Contracts Need to Speak a Different Language
Smart contracts have some issues in regards to the languages used. Check out this developers thoughts on why smart contracts need to speak a different language.
Join the DZone community and get the full member experience.Join For Free
The smart contract ecosystem has some issues, and I think it’s time we addressed them. As part of my job, I have to use the Ethereum Virtual Machine (EVM) and put it onto a blockchain that isn’t Ethereum. That means I’ve spent way too many hours learning all about the EVM. And, guess what? I’m not a big fan of it.
First of all, the EVM is the engine in which transaction code gets executed. It’s part of the Ethereum Protocol and has a pivotal role in the consensus engine of the Ethereum system. So, why don’t I like it? Well, I don’t think the design is at all practical, and the implementation is less practical still. What particularly bugs me is it doesn’t work with today’s technology and paradigms. It’s just not relevant for what’s out there today.
I feel that, before proceeding, I need to quickly make a point about Ethereum — it’s widely thought to be a cryptocurrency, although this is somewhat false. Ethereum (unlike Bitcoin) is a second-generation blockchain and really more of a platform for executing smart contracts than a currency. Ether, used to power these, is a native token running on the protocol and is frequently used as a means of payment.
The problem with virtual machines, other than the EVM, is that they run on proprietary software, which seems to go against the whole point of the space. I’ll go on to speak about Ethereum and programming languages, but most others also have limited support for languages that developers can rely on.
Some have adopted a workaround so that established languages like C# can be used, in a sense, but instead of interacting directly with the VM, this is translated into the proprietary language before being compiled. It’s not a case of simply using this translation software for a range of languages. They’re tailor-made for each, meaning that supporting another (say, Go) would require a whole new translator to be developed.
Ethereum limits the programming language for smart contracts to Solidity. It’s a language that has been customized for the EVM, and it’s relatively easy to pick up. But, why can’t we bring more mainstream programming languages, like C++, Rust, Go, C, Lua, and Python, to the smart contract ecosystem? What we need now in smart contracts is stability and predictability whenever we’re developing. This will lead to faster and cheaper-to-use smart contracts, using fewer resources for nodes and, therefore, lower gas prices for those contracts.
That’s why I want 2018 to be the year smart contracts are written in Rust. Rust is really efficient — it’s lightweight and, above all, it’s focused on safety, bug prevention, and avoidance of common programmer mistakes. But, I’m not only all about Rust. We could also do this with C and C++ because they’re easy to support. Go is another great option.
Now, let’s get back to why else the EVM is out of step with the technology being used on a day-to-day basis.
On most modern processors, you have four choices for quick math: 8-bit integers, 16-bit integers, 32-bit integers, and 64-bit integers. Generally speaking, if you use one of these sizes, there are guarantees of how many cycles a math operation takes, and it’s fast, too. These are the size of integers that modern processors use “natively,” without any translation or other adaptations.
However, the EVM’s choice for integer size is 256. In my opinion, this makes life needlessly harder for everyone involved. Working with 256-bit integers is way more complex and slower than working with an integer length natively supported by the processor.
Looking at it from the EVM’s point of view, this design has been chosen because it’s easier to only support 256-bit integers (compared with adding additional opcodes for working with other integer sizes). The only non-256-bit operations are a series of push instructions for pulling data from 1-32 bytes from memory and a few instructions that work with 8-bit integers.
Another justification for the large integer size is “big values for cryptography computations.” But, I can’t figure out a single use case for 256-bit integers that doesn’t involve comparing if an address or hash is equal. Custom cryptography is too expensive to execute on the public blockchain. I searched on GitHub and couldn’t find a Solidity contract that does anything I’d call cryptography. Almost any type of cryptography will be slow and complex on modern computers, and this makes it non-economical to execute on the public Ethereum blockchain due to gas costs.
Yes, there are still private blockchains where gas costs don’t matter. But, if you own a blockchain, you wouldn’t want to do this as part of a slow EVM contract, you would use C++, Go, or the real programming languages to implement the cryptography in native code as a pre-compiled smart contract. So, the justification for supporting only 256-bit integers doesn’t stack up.
An X86 Virtual Machine
In my opinion, the world of smart contracts is crying out for an x86 virtual machine. The x86 architecture is what most computers use and what most programs run on today. By utilizing an x86 virtual machine, we can leverage all of the existing tooling and technology out there, but bring it into the smart contract space.
This would allow developers to use established programming languages with a significantly smaller learning curve than learning an entirely new programming language for smart contracts as developers currently have to.
Opinions expressed by DZone contributors are their own.