An Analysis of Ontology Smart Contract Security and Loopholes — Part 2
Foreword: The security of smart contracts is one of the hottest topics in blockchain technology. All the existing smart contract systems have shown some types of loopholes, whether they are backed by the Ethereum Virtual Machine (EVM) or the EOS WASM Virtual Machine. These loopholes have caused huge losses for projects and users, and have called into question the security of blockchain technology.
Chapter 1: Introduction
In our last article, we talked about cross-contract call attacks, a type of potential loophole attack that may happen when developing smart contracts on Ontology. Now you know how to prevent such an attack, we will go on to introduce another type of security threat and its solution.
But before that, we will briefly introduce how transactions are executed and how fees are charged after the node that generates blocks has bundled the transactions into blocks on the Ontology blockchain. The process can be divided into four steps:
- The blocks are confirmed by consensus validation;
- The transactions in the blocks are executed locally;
- Fees are charged for each transaction, and insufficient fees result in transaction failure;
- After transactions are executed successfully, the transaction state will be stored in the local ledger; if the transaction fails, then the transaction state will not be stored.
As can be seen, transaction execution happens before transaction fees are charged in the block. We also know that transaction fees on Ontology are paid in ONG, and each transaction charges a fee of 0.01 ONG. The transaction execution process and the way transaction fees are charged are working fine following the normal execution logic. However, in special cases, inattention to writing smart contracts may lead to a new type of security threat: force transaction failure attack.
Chapter 2: Force Transaction Failure Attack
The Ontology blockchain adopts a dual-token system of ONT and ONG, and supports both homogeneous and heterogeneous tokens, including OEP-4, OEP-5, and OEP-8 tokens. Normally, dApps will use one type of token, for example, ONG. We can see that ONG is both used in dApps and as transaction fees.
Developers need to pay special attention to this issue, as it may cause force transaction failure attack.
Here is an example. Let us say there is a simple real-time guessing game where users use ONG to guess numbers and send guess-the-number transactions. Users who guess the number correct will receive a certain amount of ONG as rewards, otherwise, the user will lose the ONG they use for guessing the number. For each guessing, users need to pay some ONG as transaction fees. Below is a code sample of such a smart contract:
The code sample uses _rollANumber to get a random number. If the user’s guessed number matches the random number, then the rewards the user receives will triple.
According to the transaction execution logic of the Ontology blockchain, the user transaction will be executed before transaction fees are charged, and whether the transaction state will be stored will be based on the transaction execution result. In the above example, a malicious user uses all the ONG in his account to guess the number, if he guesses right, then he will get rewards and pay the transaction fees. But if the user guesses incorrectly, since all his ONG has been used to guess the number, the user will have no ONG to pay for the transaction fees and thus the transaction will fail. As a result, the user will not lose his ONG. Obviously, the malicious user will be winning all the time.
Chapter 3: Prevention of Force Transaction Failure Attack
How do smart contract developers prevent such attacks? One viable option is to check whether the user who calls the contract has enough ONG as transaction fees at the very beginning. In the above code sample, smart contract developers can solve this problem by adding some restrictions in the contract, that is, users are not allowed to use all the ONG in their accounts and there must be enough ONG to pay for the transaction fees.
The code sample is as follows:
We can see that here the smart contract developer adds _avoidForceTxFailureAttack to check whether the user has enough ONG to pay for the guessing and transaction fees.
In the contract, this method is at the beginning of the execution logic, which means if the user does not have enough ONG in his account to pay for transaction fees, then the transaction will fail automatically. By doing this, smart contract developers can prevent malicious users from taking advantage of the loophole to attack the contract.
Chapter 4: Afterword
This article introduced the second type of potential attack Ontology smart contract developers may encounter and gave the solution. In our future tech point articles, we will continue to talk about other types of loophole attacks to help Ontology smart contract developers avoid potential loopholes.
Ontology smart contract developers can also use VaaS-ONT, an automatic smart contract formal verification platform integrated into SmartX, the Ontology smart contract IDE, to locate risky code and find out the cause in one click, which can verify common security loopholes, security properties, and function correctness of smart contracts or blockchain applications, thus improving security.
Are you a developer? Make sure you have joined our tech community on Discord. Also, take a look at the Developer Center on our website, there you can find developer tools, documentation, and more.
Find Ontology elsewhere
Ontology website / Ontology GitHub / ONTO website / OWallet (GitHub)
