Foreword
As with most blockchains , Ethereum nodes aggregate transactions and form them into blocks, and once miners solve the consensus mechanism (currently Ethereum’s ETHASH PoW), those transactions are considered valid, as will the miners who solved the block Choose which transactions from this pool will be included in the block, this is usually determined by gasPrice transactions, there is a potential attack vector here, an attacker can observe the transaction pool for transactions that may contain a solution to the problem, smart contract audit services modify or revoke the attacker’s permissions or change the state in the contrac`t that is unfavorable to the attacker, the attacker can then get the data from this transaction and create a higher level transaction gas Price and include its transaction in a in the block.
Conditional competition
This contract contains 1000 ether, and the user who finds and submits the correct answer will get this reward. When a user finds the answer and calls the solve function with the answer as a parameter, unfortunately, the attacker can observe any transaction pool in the transaction pool. Answers submitted by people who see this solution, check its validity, and then submit a new transaction with a gasPrice that is much higher than the original transaction, miners that solve the problem may pack the attack first because the attacker’s gasPrice is higher The attacker will get 1000 ether, and the user who solves the problem initially will not get any reward (there is no remaining ether in the contract), and the conditional competition problem arises!
defensive measures
There are two types of users who can conduct this type of early transaction attack:
Users (modify the gasPrice of their transactions)
Miners themselves (they can reorder transactions as they see fit)
Overall, a contract vulnerable to type 1 (users) is significantly worse than a contract vulnerable to type 2 (miners), since miners can only perform the attack when solving a block, which is very important for any target This is not possible for a single miner of a particular block, here are some mitigations:
gaslimt
One approach that can be taken is to create a constraint in the contract, a gasPrice cap, which prevents users from increasing gasPrice and getting prioritizing transactions beyond the cap, this precaution only mitigates the first type of attacker (arbitrary user) Attack, smart contract audit in this case miners can still attack the contract because they can order transactions as they want regardless of gasPrice.
Disclosure Scheme
A more reliable approach is to use a commit-reveal scheme whenever possible, which states that the user sends a transaction using hidden information (usually a hash), after the transaction has been included in the block, the user sends a transaction to decrypt the data that has been sent (disclosure phase), this method prevents miners and users from forward-looking transactions, as they cannot determine the content of the transaction, however this method cannot hide the transaction value (in some cases, this needs to be hidden Valuable information), ENS smart contracts allow users to send transactions whose commitment data includes the amount of ether they are willing to spend, then users can send transactions of any value, and during the disclosure phase the user refunds the amount sent in the transaction with the amount they are willing to spend difference between.
Related discussion
There has been extensive discussion about the “conditional race” problem of the Approve function:
The first is that Ethereum officially gave a suggestion:
The main meaning of the above is to restrict the approve function to change the quota from N to M, only from N to 0, and then from 0 to M, which can be restricted by the following statement:
Later, someone proposed that the above security suggestion can solve the “transaction order dependency”, but if require is added, the contract will not conform to the ERC20 standard specification.
The meaning of reduce Approve here is to reduce the “quota” on the basis of the original “quota”
The author believes that if the three functions of approve, increase Approve, and decrease Approve are put into a contract, and these three functions are all public, and there is no security judgment in the approve function, then if the user can still call Approve for “quota” division, at this time The increase Approve and decrease Approve are basically the same as no exist, in this case the contract still suffers from “transaction order dependency problem”.
In the process of auditing smart contracts, the author found that many contracts adopted the following three methods to deal with the problem of “approve transaction order dependency”:
- Add Require to approve for security judgment,
2. Use the increase Approve and decrease Approve functions to replace the approve function. The Approve function maintains the ERC20 standard and does not add require for security precautions,
3. Use the increase Approve and decrease Approve functions to replace the Approve function. The Approve function uses require for security protection.
The above solutions can be seen in many bsc smart contract audit of which the first and second are mostly, and the third is less. The solution to the “transaction order dependency” problem can be viewed from the following two perspectives:
From a security point of view: the first and third types can successfully solve the “transaction order dependency” problem, while the second type still cannot effectively solve the “transaction order dependency” problem.
From the perspective of the ERC20 standard: the first and third types violate the ERC20 standard specification, and the second one conforms to the ERC20 standard specification.
Small thinking: The “require” judgment is added for safety, not for the standard, how would you choose? (Although this type of vulnerability is more difficult to exploit)
Conclusion at the end of the article
Contract developers should establish a set of development standards, and at the same time collect the types of loopholes, utilization methods and security remediation methods of existing contracts disclosed on the network as much as possible, and then continuously improve their development system and launch the contract. Before, it was recommended to find a special company to conduct a security audit of the contract and make an evaluation of the contract.
