Questions regarding the profit properties for a specific displacement attack

[Otto-AA]

I've started to look through the displacement attacks by Frontrunner Jones and got confused why the following attack got reported also by this tool.

The transactions:

• victim transaction: https://etherscan.io/tx-decoder?tx=0xca04cec2436f9ad5b13345da20d8b2a569bbaa8be2d4e6ba640fe6f0ff4c28e7
• attacker transaction: https://etherscan.io/tx-decoder?tx=0xaa79afe1a556284a16117bea20bcfad49f4c3ab3a371ba06b5ebdcebc0b6a331
• the results in displacement.evaluate.output.txt: 6011110951c8410f31be6577 true true

The victim transaction is contained in the attacker transaction, which explains why it is included as a displacement attack in the Frontrunner Jones paper. However, from my current understanding, I don't see how these transactions fulfill the Attacker Gain and Victim Loss properties.

Property definitions from the paper

Property 1 (Attacker Gain): The attacker obtains financial gain in the attack scenario compared with the attack-free scenario.

Property 2 (Victim Loss): The victim suffers from financial loss in the attack scenario compared with the attack-free scenario.

Understanding the transactions

I'm relatively new to analyzing ethereum transactions, so I may have missed something. Feel free to double check :)

The victim transaction directly calls multihopBatchSwapExactIn(...) from this ExchangeProxy contract. The attacker transactions makes a call with exactly the same data (as we can see here at "Action [11]"), but also performs some pre- and postprocessing.

The call essentially converts between different currencies/tokens:

• 6 ether to 6000000000000000000 WETH
• all WETH tokens to 100495097474324020199 BAL
• all BAL tokens to 2013713552 USDC

The USDC are the final outcome without any additional WETH left. For the attacker this means that they converted 6 ether to 2013713552 USDC. In the preprocessing, the attacker withdrew these 6 ether from 6000000000000000000 WETH, so all in all they changed WETH to USDC.

For the victim, the transaction failed and they only paid a small transaction fee, while the 6 ether value were returned.

My profit calculations

The victim case is easier, so I will start with this one:

In the attack scenario (where the transaction failed) the victims balance is:

• 6 ether (the ether it didn't spent)
• 0 USDC tokens

In the attack-free scenario the victims balance would likely be (I could not verify this with an EVM simulation, because I couldn't setup my test environment that well yet):

• 0 ether
• 2013713552 USDC

While the amount of USDC tokens increased, the ether balance would decrease. Looking at profit_test.go this seems like an "ErrNotComparable" case to me, where we can't compare the profits and thus should disregarded this possible attack.

For the attacker it is likely the same case but mirrored. However, this also depends on the pre- and postprocessing of the executing contract (in particular how it catches errors and how it handles them). So while this also looks strange to me, I'm less sure about this one.

Questions

Did I miss something in general? Or used the definitions wrong? For the attacker profits, I was also confused for which account the profits are calculated (for tx.origin who initiated everything, or the contract that orchestrates everything, or the sub-contract that actually executes the swap transaction, or even a mixture of them?).

---

And in case you are curious, I'm asking these questions in the process of defining my master thesis topic. Currently I'm trying to understand better the different types of frontrunning attacks, before diving into how they could be detected by a code analysis tool. With my current setup, even a full node is not possible for me, so I couldn't run the erebus-redgiant analysis myself on these transactions and also couldn't find the results in the repository.