The concept of smart contracts was first described by Nick Szabo in 1996. "New institutions and new ways to formalize the relationships that make up these institutions are now made possible by the digital revolution. I call these new contracts 'smart' because they are far more functional than their inanimate paper-based ancestors. No use of artificial intelligence is implied. A smart contract is a set of promises, specified in the digital form, including protocols within which the parties perform on these promises," he described. But not everything is so smooth, as such large-scale ideas invariably entail mistakes and inaccuracies. What problems have already been found in the smart contracts of one of the biggest and oldest blockchains?
What's Wrong with Ethereum?
After more than 20 years, the abstract idea of smart contracts became a reality. The potential inherent in smart contracts is huge. The emerging technology can be used to authenticate, securely exchange data, manage tokens, and raise funds with the ICO model. The blockchain company Ethereum, one of the first sites to have implemented smart contracts in their own blockchain, has more than 1,500 decentralized applications, each of which uses smart contracts for performing a variety of tasks. The problem with smart contracts, however, is that they are code-based, and errors within them can become catastrophic.
According to a number of experts, Ethereum has a "birth trauma,” as its blockchain is largely built on Solidity, an advanced programming language. Thus, many developers need to learn a completely new language, which increases the likelihood of human error.
And these kinds of mistakes did not take long to manifest. On April 23, 2018, PeckShield, which deals with security on the blockchain, stated that batchOverflow errors were found in several ERC20 smart contracts.
The developers created an analytical algorithm for carrying the ERC20 tokens. The system is designed for automatic notification of suspicious transactions. As a result, the "catch" appeared rather quickly, as the program issued an alarm signal after seeing a strange transaction of the BEC token. In this transaction, a prohibitive number of BEC tokens had been listed (0x800,000,000,000,000,000,000,000,000,000,000,000,000,000,000.00)
Such an unusual transaction prompted developers to look at the smart contract code. The study revealed that such a transfer could be the result of an "in-the-wild" attack, which takes advantage of a previously unknown vulnerability in the contract (batchOverflow).
The vulnerable function was located in the batchTransfer. Line 257 shows that the local variable of the sum is found by multiplying cnt and _value. The second variable (_value) may even be a random 256-bit integer (for example, 0x800,000,000,000,000,000,000,000,000,000,000,000,000,000,000.00).
Thus, having two _receivers sent to batchTransfer, with this extremely large value, we can fill the sum and make it equal to zero. In case of zeroing, an attacker can safely pass the health checks in lines 258 and 259, after which the subtraction in line 261 is absolutely irrelevant.
As a result, as demonstrated in lines 262 to 265, the balance of the two wallets will be replenished with a huge amount. Interestingly, according to the developers, at that time more than a dozen ERC20 contracts were also vulnerable to batchOverflow errors.
According to the team, they had then already tried all possible ways of communicating with the developers, but after the introduction of the "code law" principle in the Ethereum blockchain, there was no longer a well-known security mechanism to eliminate these vulnerable contracts. "The presence of decentralized exchanges with autonomous trade services can cause additional problems since they cannot even stop the attackers from laundering their tokens. On the other hand, we can face even more serious difficulties. In particular, it is very likely that an attacker has a huge number of tokens using these vulnerable contracts. What if they switch to the possibility of exchanging cryptocurrencies and trading these tokens for ETH, BTC, or even USD?" Asked the team that had discovered the bug.
Are Prodigal, Greedy, and Suicidal the Main Traits of Ether Smart Contracts?
In early 2018, five researchers from the U.K. and Singapore using the MAIAN tool created a way to detect vulnerabilities directly via bytecode, thus not requiring access to the source code. They found 34,200 smart contracts that could have potential bugs and store information in themselves about transactions worth several million dollars in Ether.
They divided the vulnerable contracts into conditional three groups: suicidal, prodigal, and greedy.
The tap function blocks the Ether because the condition in line four can never be fulfilled. Optimizing the Solidity compiler, however, allows this to happen when more than 20 bytes are used to call the function. At the bytecode level, EVM will only be able to load pieces of 32 bytes of incoming data. In line three, when pressed, the first 20 bytes are assigned to prev, and the remaining 12 bytes are simply ignored. This error occurs because the EVM in line four gently nullifies the 12-byte prev. This contract lost 5,001 Ethers from different addresses in the Ethereum blockchain.
The contract can be killed by using an unsecured SUICIDE statement. A trivial example is the function of public annihilation, in which the suicide instruction is placed. Sometimes SUICIDE is protected by a weak condition. This contract allows users to buy tokens or withdraw their funds. The logic for the withdrawal of funds is provided by the output function. This function has a self_destruct instruction, however, which can be executed if the last funds were added to it more than four weeks ago. Therefore, if the "investor" calls this function four weeks after the last investment, all the funds go to the contract owner, and all the entries of the "investors" are erased from the blockchain.
The SimpleStorage contract is an example of a contract that blocks Ethers in unlimited quantities. If an arbitrary address sends the Ethers along with the transaction that calls the set function, the balance of the contract increases in proportion to the number of the Ethers. When an arbitrary address sends the Ethers along with the transaction that calls the set function, the balance of the contract is increased by the number of the Ethers. In the contract, however, there are no instructions on the release of the Ethers, and, thus, it blocks the function on the blockchain.
The payable keyword was introduced in Solidity not long ago to prevent the adoption of the default Ether functions that do not have the payable keyword and are not executed if an Ether is sent during the transaction. Although this contract has no function associated with payable keywords, however, it still accepts the Ether, because it was compiled with an older version of the Solidity compiler (without payable support).
Drawing conclusions from their work, the researchers came to a rather disappointing result. "Analyzing 970,898 contracts, our new MAIAN tool found thousands of vulnerable contracts. In addition, 6,239 Ethers (about $5.6 million) are locked in posthumous contracts, which are currently on the blockchain, of which 313 were sent to dead contracts after their murder," they summed up.
Will the Problems Be Solved?
Obviously, because of the human factor associated with the application of Solidity in Ethereum, and a number of other problems that are not likely to disappear even after finding and eliminating all bugs, the shortcomings of the Ethereum smart contracts will surely remain. Nevertheless, it is quite possible to minimize them. The team has already started to work with Vyper, a simpler language similar to Solidity. In addition, Ethereum 2.0 is not far off in 2018, as the blockchain community will see the "second phase" of the system's maturation. Perhaps, it is these measures that will lead to the solution of the main problems of its smart contracts.