Not in the same block #255
Conversation
ghost
linked an issue
There was a problem hiding this comment.
Flash Loans only help some attacks, but are not required for any of them. Therefore any FL-protection is flawed by design, as it doesn't secure contracts against whales or successful hackers (those who have lots of stolen assets).
These types of attacks should be dealt without assumption that FL is utilized.
Similarly, there are options to execute multi-transaction attacks atomically (see MEV/flashbots/...), therefore a sophisticated attacker can bypass tx.origin checks.
| /// @notice A mapping of accounts stores those who | ||
| /// lend/withdraw on current block. | ||
| /// block => account => true/false | ||
| mapping(uint256 => mapping(address => bool)) internal hasInteracted; |
There was a problem hiding this comment.
If I understand correctly, you can simplify it to mapping(address => uint256) internal lastInteraction; // account => block
and the check should be lastInteraction[addr] < block.number
it will save some gas, mostly due to storage reuse
| _currentBlock = block.number; | ||
|
|
||
| /// @dev Check there are no previous txs in this block coming from same account. | ||
| require(!hasInteracted[_currentBlock][msg.sender], "Avoiding flash loan attack: several txs in same block from same account."); |
There was a problem hiding this comment.
checking against msg.sender doesn't protect against FL, only complicates the setup:
the attacker would need to add extra contracts A1, A2, ... for each individual interaction within their transaction
formally, you can achieve FL protection via tx.origin check, however it is discouraged.
Prevent lending and withdrawal within the same tx/block #199 (medium):
To protect from the lending fees manipulation using flash loan we need to prevent lending and withdrawing from the pools in the same tx/block by the same account.
Check more details at #199