Transaction spam attack: Next Steps
Transaction Spam Attack: Next Steps
Understanding the Attack
A recent transaction spam attack on the network has left users and developers scrambling to understand the root cause and implement fixes. The attack, which involved repeatedly calling the EXTCODESIZE opcode, resulted in blocks taking up to 20-60 seconds to validate due to the large number of disk fetches needed to process the transaction. This led to a significant reduction in the rate of block creation, with a 2-3x decrease in the rate of block creation during the attack.
Technical Details
The attack was possible due to the way the network processes transactions. When a node receives a transaction, it needs to validate the transaction by checking the state of the accounts involved. This involves reading the account state from disk, which can be a time-consuming process. The EXTCODESIZE opcode, which is used to retrieve the size of a contract, is particularly slow because it involves reading a large amount of data from disk.
Short-Term Fix
To mitigate the effects of the attack, users, including miners, enterprise users, and individuals, can run geth with the following flags:
--cache 1024increases the cache size, reducing the number of disk reads that nodes need to make.--targetgaslimit 1500000votes the gas limit down by 3x, reducing the maximum processing time of a block by a similar factor.
Similarly, Parity users can run with the following flags:
--cache-size-db 1024increases the cache size, reducing the number of disk reads that nodes need to make.--gas-floor-target 1500000votes the gas limit down by 3x, reducing the maximum processing time of a block by a similar factor.--gasprice 20000000000sets the gas price to a fixed value, reducing the incentive for spam attacks.
Medium-Term Fixes
In the medium term, the Go client team is working on several fixes that should provide a more stable resolution for the present issue and mitigate the risk of similar attacks. These fixes include:
- A change to miner software that automatically temporarily cuts the gas limit target by 2x when the miner sees a block that takes longer than 5 seconds to process.
- Numerical tweaks to cache settings to improve performance.
- Adding additional caches to reduce the number of disk reads.
- Adding an additional cache for EXTCODESIZE specifically to improve performance.
- An on-disk cache of state values that allows them to be more quickly accessed.
Long-Term Implications
In the long term, there are several low-level protocol changes that can be explored to improve the security and performance of the network. These changes include:
- Increasing the gas costs of opcodes that require reads of account state, such as SLOAD, EXTCODESIZE, and CALL.
- Increasing the gas cost of read operations that read external accounts.
- Implementing EIP 90 to increase the gas costs of certain opcodes.
These changes would put a much lower upper bound on the maximum number of bytes that a transaction may read, increasing safety against all potential attacks of this kind, and reducing the size of Merkle proofs and hence improving security for both light clients and sharding as a side effect.
Conclusion
The recent transaction spam attack on the network has highlighted the need for improved performance and security measures. The short-term fix of increasing the cache size and voting the gas limit down by 3x has mitigated the effects of the attack, but more work needs to be done to prevent similar attacks in the future. The medium-term fixes being worked on by the Go client team should provide a more stable resolution for the present issue, and the long-term implications of low-level protocol changes should be explored to improve the security and performance of the network.
Source: https://blog.ethereum.org/en/2016/09/22/transaction-spam-attack-next-steps
