What is a smart contract?


A smart contracts is a type of code that allows you to verify and execute a contract automatically and easily. Although the conditions for hiring external agents to execute the plan have been discussed, it is clear that this represents a key paradigm shift for the business world. These contracts work on the blockchain and do not require human intervention in advance to verify and enforce the conditions.

Some relevant use cases are found in loan contracts, where smart contracts allow the debtor to automatically close access to the money if the debtor does not pay the agreed interest or installment payments. Smart contracts allow the data verification process or the implementation of the insurance contract clauses, and avoid possible disputes.

But a good smart contract is difficult to do well. Its three main attributes, the ability to express value, transparency and immutability are fundamental to its operation. However, these attributes also make them a security hazard and a high-interest target for cybercriminals. Even if there is no deliberate attack, there are many examples of capital collapse and business losses due to certain vulnerabilities.

As a result, they may have certain tendencies to suffer from vulnerabilities. In this article, we will describe the five most common problems that often happen.

 

1-Arithmetic error of integers

A very common error is the arithmetic error of integers. Due to the lack of floating point support, smart contracts generally represent values as integers.

Using whole numbers to represent values ​​(which is common in financial programs) requires reducing the value to a smaller unit to allow sufficient precision. The simplest example is to express the value in cents instead of dollars, because otherwise it would not be possible to express 0.5 dollars. In fact, the accuracy of smart contracts tends to be further improved, with many tokens supporting 18 decimal places.

One problem that developers are aware of today is the possibility of integer overflow.

Like the mileage of a car, the integers represented in the computer also have a maximum value, once this value is reached, they simply return to the starting point and start from the minimum value. Similarly, subtracting 4 from 3 in an unsigned integer will overflow, resulting in a very large number. Developers are often aware of this potential problem, which can be avoided by using a secure math library.

However, what many developers don’t seem to appreciate is the lack of precision when integer arithmetic is performed incorrectly. In particular, the order of operations is very important, and the typical case is the calculation of percentages. For example, to find 25%, we generally divide it by 100 and multiply it by 25.

Suppose we only want to use whole numbers to calculate 25% of 80. Due to rounding errors, expressing it as 80/100 * 25 will result in 0. A small error here is that the division was done before the multiplication.

It is an example that happens frequently despite being a very simple mistake.

2-Vulnerabilities of the block gas limit

Ethereum makes sure that the block does not grow too large, thanks to the block gas limit. This only means that the amount of gas that the transactions contained in these blocks can consume is limited. In short, if a transaction consumes too much gas, it will never get into trouble and therefore will never execute.

This can lead to a common vulnerability: If data is stored in resizable arrays and then accessed by looping through these arrays, the transaction can quickly exhaust and roll back. This happens when the number of items in the assembly increases, which generally occurs in production, not during testing.

The reason is that the test dataset is usually smaller than the production dataset, which makes this vulnerability very dangerous because the contracts related to this issue generally pass unit testing and work well with a small amount. of users. However, as the project develops and the amount of data increases, they will fail. In this case, it can affect the funds, making their recovery impossible, when using recurring payments.

3-Frontrunning

This can be defined as the occupation of unconfirmed transactions and is the result of the transparency of the blockchain.

All unconfirmed transactions are visible in the memory pool before miners include them in the block, and interested traders can simply monitor the contents of the transaction and “advance” the transaction by paying higher fees. This can be easily automated and has become very common in decentralized financial applications.

These types of problems usually require some form of major refactoring or redesign to resolve them.

 

Frontrunning

 

4-Lack of parameters or precondition controls

Another basic programming feature, but common, is the lack of verification of the function parameters or forgetting to make the necessary checks for a certain operation to be valid. Typically this includes address parameters that are not verified against address zero, or if an unauthenticated user has enough token balance to perform a specific operation, for example. Another good example is access control, where only certain types of users should be allowed to call a certain function, but this verification is never done.

These errors are often the result of an oversight in the design process. It is a good idea to have written instructions for all functions, indicating the parameters, preconditions, and operations to perform. Sticking to design patterns, such as Check-Effect-Interaction, can also help prevent this type of vulnerability.

5-Logic bugs

The 4 previous points are more specific to smart contracts, but there are others that are inherent to programming. However, the most common problem is usually a basic error in the logic of the smart contract. These errors can be caused by simple typographical errors or specification misunderstandings, which have a serious impact on security.