Solidity Pitfalls and How to Avoid Them

“The currently unrivaled programming language for smart contracts is Solidity for the Ethereum blockchain.” - Alfred Shaffir iOlite.io

Solidity is still a new, fast-changing language which has some serious pitfalls. As with all new things, bugs and logical faults are inevitable. Luckily, the ICO craze has triggered a new movement of research into the security aspects of blockchain and high-level programming languages as certain smart contracts hold millions of dollars, making it a perfect target for hackers.

This article is based on the following research paper: “Ethereum Smart Contracts: Security Vulnerabilities and Security Tools” written by Ardit Dika at the Norwegian University of Science and Technology.

ERC20 critical bug

ERC20 assumes two ways of performing a token transaction.

1. The transfer function lets you send tokens to someone’s address.
2. For depositing tokens to a smart contract, you have to use the combination ‘approve & transferFrom’.

But, when you send tokens to a smart contract using the transfer function, the smart contract won’t detect your deposit request. This results in permanently losing your funds. A lot of novel developers have experienced this critical bug firsthand.

Standards like ERC223 and ERC777 try to mitigate this bug. More specifically, ERC223 allows developers to send funds to an address or contract using the same function: transfer. ERC223 allows developers to handle incoming token transactions, and reject non-supported tokens. At last, the ERC223 token standard is more efficient as it’s a one-step process, rather than the approve & transferFrom two-step process. In short, ERC777 focuses on adoption by offering a wide range of transaction handling mechanisms. — Source: Cointelligence.

Unchecked send function

Kalra S., Goel S., et al have recently published a research paper on analyzing the safety of smart contracts. They describe the problem of the unchecked send function: “Since Solidity allows only 2300 gas upon a send call, a computation-heavy fallback function at the receiving contract will cause the invoking send to fail. Contracts that do not correctly handle such failed invocations and allow modifications to the global state following the failed send call, may incorrectly lead to loss of Ether.”

Publicly visible data

All data on the Ethereum blockchain is publicly visible to anyone. Regardless of the positive impact Ethereum has, the benefits are limited by this property. Companies cannot use Ethereum to pay the wages of their employees as that would expose their monthly income.

As you can see, there is a serious need for blockchains that introduce more security properties like encryption, data obfuscation, and secure transaction handling mechanisms. The Enigma project is doing a great thing with its so-called ‘secret smart contracts’.

Unchangeable smart contracts

Once a smart contract is deployed, it’s not possible to modify or alter it. It’s advantageous as it represents a trustworthy platform. On the other side, due to this property, a significant number of smart contracts contain vulnerabilities that can be exploited gaining illegal profit.

In addition, a common safety guide for ICOs is to use an arbitrary name when deploying their ICO smart contract on the testnet. It has happened before an ICO smart contract got hacked because attackers were able to locate the testnet smart contract weeks before the actual deployment on the main net, giving them enough time to find critical bugs.

In 2016, a symbolic execution analysis tool (Oyente) was developed by Luu et al. This tool revealed 45% of the 19,366 smart contracts back then were vulnerable for at least one known security issue.

Exceeding the maximum gas amount

Let’s end with a slightly funny problem. The GovernMental website was doing a jackpot. A large amount of 1100 ETH could be claimed by the lucky winner. However, because of a bug in the code, a gas amount of 5057945 was needed to claim the Ether. However, back then, the maximum gas amount for a transaction is only 4712388.

The problem was caused by an array that looped all creditors and deleted them one by one, returning the winner. Even Vitalik Buterin jumped in and gave this piece of advice: “In general, it seems like we need one new piece of standard advice for contract developers: make sure that if you have arrays that users can extend then either find some way for each user to separately handle the array elements associated with themselves or split up the work among several transactions.”

Luckily, this problem has been solved now. Such hard-to-find problems will keep popping up in the future.

Golden Tip: Use Experts and Audit Audit Audit!

I don’t want to be rude, but don’t trust novel Solidity developers to code your ICO smart contract. Proper developers know the problems that have occurred in the past and know how to respond to it.

Most Solidity contracts being developed will be used for ICOs, so we are speaking about millions of dollars. Have your smart contract audited by several independent organizations, it’s for your own safety.

Another possibility is to use platforms that assist you in the creation of a smart contract. The iOlite product is a community-driven tool that accepts natural language or any other programming language as input for the creation of smart contracts. Solidity experts are able to define structures linked to their smart contract code. iOlite uses a modified version of the Stanford Natural Language Processing engine. The whole idea is based on machine training, driven by a community of Solidity experts. The benefit of iOlite is that it allows you to craft smart contracts easily and for free.

Find out more about iOlite.io or join their Telegram channel.