Smart Contracts on Steroids: Solving the Problems Facing Ethereum’s Solidity

flickr

The Ethereum network currently consists of more than 1,700 decentralized applications (DApps), a number that is expected to grow in the coming years. And while all of these DApps rely on smart contracts to accomplish a number of important tasks, it has become clear that smart contracts are prone to errors, bugs and other catastrophic mistakes — to the tune of more than a billion dollars stolen in smart contract hacks to-date.

In order to write a smart contract, programmers must learn an entirely new programming language called “Solidity.” While smart contracts facilitate complex operations in ethereum, making simple mistakes while writing smart contracts in Solidity can cause dire consequences, including security breaches and / or very high transactional costs.

One of the most well-known examples of a poorly-coded smart contract came from the Decentralized Autonomous Organization (DAO). A more recent bug also was discovered in the smart contract used by Parity, which was exploited and resulted in the loss of half a million Ether (ETH), worth more than $169 million.

Is Solidity to Blame?

As issues with smart contracts become more common, Solidity has gained attention as being problematic for the Ethereum network. Unfortunately, many new projects that rely on smart contracts lack programmers with the experience needed to properly optimize and audit smart contracts.

For example, in terms of performance, gas fees can be astronomical when executing certain complex smart contracts. “Gas” is a nominal unit of Ether that is spent on operating transactions on the Ethereum network. It depends on the complexity of the Smart contract and the congestion of the network at the time of the contract execution. Ethereum automatically punishes slow and complex contracts, rightfully, by charging them very high gas fees. But, in many cases, the use case is inherently complex and such gas fees hamper the real adoption of smart contracts.

For instance, using an Ethereum smart contract to verify the header of a single Bitcoin transaction (i.e., a scrypt operation) will cost 370 million Ethereum gas — more than 1 billion Gwei (1 ETH) at the gas price of 3 Gwei. That is approximately $500 (USD) just to verify a transaction, which has to be done across more than 100 Ethereum contract transactions.

Security, specifically integer overflow, is also problematic when dealing with smart contracts written in Solidity. Hackers are now detecting bugs in smart contracts, allowing them to steal large amounts of cryptocurrency. This has resulted in a high security alert, as multiple ERC20 token contracts are prone to hacks.

Many of these hacks occurred simply due to mistakes that programmers have made when writing lines of code in Solidity. For example, the Beauty Chain (BEC) was a high-profile cryptocurrency in China, which started trading on OKeX on February 23, 2018. It spiked 4,000 percent on the first day of trading. From its peak market cap of around $70 billion (USD), the price has gradually decreased to around $2 billion (USD) as of April 22, when its trading value suddenly dropped to zero. (OKEX since suspended trading of BECs.)

This happened due to a bug in the BEC’s ERC20 smart contract. In the case of BEC, the developer added a method called “batchTransfer()” to the contract. The method is intended to facilitate token transfer to multiple parties at once (in other words, a batch).

Image credit from the CVE-2018–10299 security alert

However, the developer made a crucial mistake in the following line of code:

uint256 amount = uint256(cnt) * _value. (You can read more about this in Michael Yuan’s Medium post.)

Now what?

A Solution for Solidity

In order to solve the real-world problems facing smart contracts written in Solidity, one impressive language called “Lity” is being created for developing smart contracts across the CyberMiles blockchain, decentralized applications, and other customized blockchains. In particular, Lity aims to solve the performance and security issues facing Solidity.

Lity consists of a dynamically extensible language, a compiler, and a virtual machine runtime, making it an evolution of the Solidity language. This means that all of the existing Solidity programs today can run without changes on the CyberMiles virtual machine (CVM).

Another advantage of using Lity language is that it’s more flexible than Solidity, more powerful and safer. For example, Lity supports new language functions and features that can be added over-the-air.

In terms of performance, Lity extensions are for specific computing tasks and can be highly optimized. Known as “libENI” functions that are to be called from the CyberMiles virtual machine (CVM), this is executed as native code on the blockchain nodes.

For example, public/private key algorithms are typically very slow and prohibitively expensive on the Ethereum network. Many classes of applications, such as most “data marketplaces”, are practically impossible on Ethereum. With libENI, however, those operations take milliseconds (10,000 times faster) and require very low gas fees (a few cents, compare to the aforementioned $500 in gas fees to perform a cross-chain transaction).

Lity’s computational improvements have great implications on cross blockchain asset exchanges, as well as on incorporating off-chain data into blockchain transactions.

Finally, the Lity compiler checks for compliance and known bugs in ERC 20 and ERC 721 contract code, while providing support for ERC 223 standard in ERC 20 contracts to prevent accidental token transfers to unsupported contract addresses. At the virtual machine level, Lity automatically prevents common issues such as integer overflow, or setting contract owner to nil.

The Future of Smart Contracts

Unfortunately, Solidity has become a source of blame for the errors found in today’s smart contracts. In order to ensure the future of smart contracts, new programming languages like Lity are being developed.

But make no mistake, the Ethereum Foundation is actively looking for ways to innovate on its own. Chief among them is working on the implementation of “Casper” and native contracts, the transition mechanism that eventually will migrate Ethereum to a PoS consensus method. The Ethereum Foundation believes this change is necessary to solve the various problems associated with PoW. The CyberMiles Foundation, for its part, already claims to have figured out the solution: a working DPoS model and its CVM, as litylang.org outlines. The race is on.

While such modifications will mark a shift in one of the core technological elements that defines Ethereum today, its execution likely will have large implications for Ethereum, and particularly on its core components — smart contracts.

Read more of Rachel’s articles on blockchain and cryptocurrency on Forbes

Follow Rachel on Twitter at @Rachelwolf00