Imperfectly Programmed Smart Contracts Will Gobble Your Money

Ethereum is by far one of the most popular cryptocurrencies, as more than 10 million transactions have already taken place on Ethereum’s blockchain, since the cryptocurrency was first launched in 2015. Ethereum’s blockchain is considered the most popular smart contract platform today. On Ethereum’s blockchain, a smart contract can be coded using a myriad of programming languages including Solidity (best option), LLL, or Serpent. No matter what programming language is used, smart contracts’ source code is compiled into binary code, or bytecode, so that it can run on the Ethereum Virtual Machine (EVM).

Smart contracts are executed on miners’ machines, who are rewarded with Ethers ( i.e. cryptographic gas that fuels contracts and circulates in Ethereum) for donating their computing power. The developers and users of smart contracts, will also be charged a given amount of Ether in exchange for the computing power of miners. The cost of a smart contract is equal to the product of the amount of Ether consumed by executing the smart contract and the price of Ether. Furthermore, when executing smart contracts, the developers will also be charged an amount of Ether which is directly related to the bytecodes’ size of the smart contract.

It has been proven that under-optimized smart contracts cost more than necessary gas; hence, developers and users will be overcharged. To decrease costs, developers have to follow what we can call gas efficient programming approaches. Unluckily, there are currently no such guidelines, and it is rather hard for developers to detect under-optimized, gas costly, code and replace it with gas efficient code, because it necessitates deep understanding of EVM’s mechanisms and the exact amount of gas needed to execute various operations. Accordingly, a compiler that has the ability to optimize smart contracts’ bytecode to minimize the consumption of Ether gas is highly demanded.

A recently published research paper conducted the first ever investigation on Solidity, Ethereum’s recommended compiler, and proved that it fails at optimization of gas costly programming approaches. More particularly, the authors of the paper pinpointed 7 gas costly programming patterns and divided them into 2 groups: useless code programming patterns and loop related programming patterns. Moreover, they presented and developed GASPER, or GAS costly Patterns Checker, a new tool for detecting gas costly programming patterns automatically within bytecode. GASPER promotes symbolic execution and it can presently detect three representative programming patterns, which represent the two categories.

The authors of the paper applied GASPER to analyze all executed smart contracts until November 5th, 2016. Interestingly enough, they found out that 93.5%, 90.1% and 80% of smart contracts suffer from these 3 programming patterns, respectively. Even though the list of programming patterns mentioned through the paper is far from being complete, this research study highlights this crucial issue and hopefully will open the door to more research on it.

GASPER:

GASPER is proposed by the authors of the paper to detect gas costly programming patterns throughout the contract’s bytecode. GASPER directly handles bytecode without having to refer to the source code, mainly due to the fact that only a small percentage of smart contracts open their source codes. GASPER can detect now all programming patterns that belong to category 1 and one representative pattern that belongs to category 2. The developers are working on detection of other patterns.

Symbolic execution is conducted on bytecode via GASPER to handle all reachable blocks of code (a block represents a straight line of code sequence that has no branches except its entry and exit). GASPER will first disassemble a smart contract’s bytecode using Ethereum disasm function. Then, GASPER will construct the Control Flow Graph (CFG). Symbolic execution begins at CFG’s root node and then traverses the CFG. Whenever a conditional jump is detected by GASPER, it will check which are the feasible branches (i.e. true or false), via querying the Z3 solver. If it happens that both branches are feasible, GASPER will select only one branch via following the depth first search.

The developers will continue working on GASPER to produce better versions that can improve smart contract programming and produce cost efficient smart contracts.