The concept of smart contracts was first described by Nick Szabo in 1996. "The digital revolution has become possible thanks to new institutions and new ways of formalizing the relations that make up these institutions. I call these new contracts "smart", because they are much more functional than their inanimate ancestors, based on paper. It is not meant to use artificial intelligence. A smart contract is a set of promises specified in digital form, including protocols in which the parties fulfill these promises," he described his idea. But not everything is so smooth: such large-scale ideas invariably entail mistakes and inaccuracies. What are the problems in the smart contracts of one of the biggest and oldest blockchain already found?
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, and to manage tokens and raise funds with the ICO. So, the Ethereum blockchain, one of the first sites that have implemented smart contracts in their own blockchain, has more than 1500 decentralized applications, each of which uses smart contracts for performing a variety of tasks. However, the problem with smart contracts is that they are code-based, and some errors in it can become literally catastrophic.
According to a number of experts, Ethereum has a "birth trauma", because its blockchain is largely built in Solidity - an advanced programming language. Thus, many developers need to learn a completely new language, which increases the likelihood of human error.
And it didn't take long till such errors started to appear. 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 have created an analytical algorithm for transferring the ERC-20 tokens. The system is designed for automatic notification of suspicious transactions. As a result, the "catch" did not take long to wait - the program issued an alarm signal after seeing a strange transaction of the BEC token. In this transaction, a prohibitive number of BEC tokens has been listed as — 0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,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 took advantage of a previously unknown vulnerability in the contract (batchOverflow). Source.
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) can be a random 256-bit integer (for example, 0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,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-259, after which the subtraction in line 261 is absolutely irrelevant.
As a result, as demonstrated in lines 262-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.
According to the team, then they have 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 can not even stop the attackers from laundering their tokens. On the other hand, we can face additional 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?" - then asked the team that discovered the bug.
In early 2018, five researchers from the UK and Singapore, using the MAIAN tool they created to detect vulnerabilities directly via bytecode and not requiring access to the source code, found 34,200 smart contracts that could have potential bugs and store information in themselves about transactions worth several million dollars on air.
They divided the vulnerable contracts into conditional three groups: suicidal, prodigal and greedy.
The tap function blocks the ETH, because the condition in line 4 can never be fulfilled. However, optimizing the Solidity compiler allows this to happen when more than 20 bytes are used to call the function. At the byte code level, EVM will only be able to load pieces of 32 bytes of incoming data. In line 3, when pressed, the first 20 bytes are assigned to preview, and the remaining 12 bytes are simply ignored. This error occurs because the EVM in line 4 gently nullifies the 12 byte preview. This contract lost 5,0001 broadcasts 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. However, this function has a self_destruct instruction, which can be executed if the last tools were added to it more than 4 weeks ago. Therefore, if the "investor" calls this function 4 weeks after the last investment, all means 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 broadcasting in unlimited quantities. If an arbitrary address sends the air along with the transaction that calls the set function, the balance of the contract increases in proportion to the number of the ETH. When an arbitrary address sends the air along with the transaction that calls the set function, the balance of the contract is increased by the number of the ETH. However, in the contract there are no instructions on the release of the air, and, thus, it blocks it on the blockchain.
The payable keyword was introduced in Solidity not long ago to prevent the adoption of the default ETH functions - functions that do not have the payable keyword are not executed if during the transaction the ETH was sent. However, although this contract has no function associated with payable, it accepts the ETH, 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 aired (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.
Obviously, because of the human factor associated with the application in Ethereum Solidity, and a number of other problems that are likely to not disappear even after finding and eliminating all bugs, the shortcomings of the Ethereum smart contracts will of course remain. Nevertheless, it is quite possible to minimize them. The team has already started to enter Vyper - similar to Solidity, but easier to use language. In addition, Ethereum 2.0 is not far off - in 2018 the blocking 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?
11 Months ago at Articles
10 Months ago at Articles