Smart contract bugs & best ways to protect smart contracts

When starting smart contract development, many programmers strongly believe that learning Solidity takes less than two weeks, especially if they know JavaScript and have experience in working with it.

Though Solidity is rather simple, companies that specialize in ensuring the security of smart contracts, ask for huge money for smart contract audit.

Also, sometimes even large corporations and experienced developers make mistakes resulting in losses of millions of dollars. You’ve probably heard of the DAO when the attacker took away $50 million. So, why does it happen?

Unfortunately, smart contracts have some vulnerabilities, which makes the use of protection tools and smart contract audit very important. In this post, I'll consider the main types of bugs and technologies you can apply to provide smart contract security.

Smart contract vulnerabilities

Transaction Ordering Dependence (TOD)

Miners control the order of transactions, meaning that your transaction can be outrun by paying more gas in the other one (the higher the amount of gas, the higher the priority of your transaction for a miner is).

Only the miner who closes the block decides the transaction order, and this is the vulnerability, called transaction ordering dependence. In TOD, you may face unexpected malicious behavior from miners.

Timestamp Dependency

Unfortunately, the timestamp can be manipulated by the miner who isn’t always a user’s friend. The miner can adjust the timestamp provided by a few seconds, thus changing the output of the contract to his own benefit.

It can work as follows: when a smart contract uses the timestamp in order to generate random numbers, the miner can post a timestamp within 30 seconds of the block being validated, enabling to predict a more preferred option to his chances in this lottery.

So, be aware that the timestamp of the block can be manipulated by the miner, and all direct and indirect uses of the timestamp should be considered. Block numbers and average block time can be used to estimate time, but this is not future proof as block times may change (such as the changes expected during Casper).

Reentrancy

The first version of reentrancy vulnerability involved functions which could be repeatedly called before the first function call was ended. For this reason, different function calls could interact in destructive ways. Take a look at the code below:

// INSECURE
mapping (address => uint) private userBalances;

function withdrawBalance() public {
uint amountToWithdraw = userBalances[msg.sender];
if (!(msg.sender.call.value(amountToWithdraw)())) { throw; } // At this point, the caller’s code is executed, and can call withdrawBalance again
userBalances[msg.sender] = 0;
}
]

Find out more about other smart contract bugs and ways to provide smart contract security and protection.

Also, check out smart contract audit best tools and practices that help deliver the code of the highest quality.