0x00 Background
Recently, we observed an incident of frontrunning attack, with HopeLend as the victim. The attack tx is
https://etherscan.io/tx/0x1a7ee0a7efc70ed7429edef069a1dd001fbff378748d91f17ab1876dc6d10392
in block [18377042](https://etherscan.io/block/18377042)
The real hacker’s attack transcation is
https://etherscan.io/tx/0xa414de03bbf7baccea6b5c95af9ebfbed43b1c3151debd29673df979a0f4b0b0
is also in block[18377042](https://etherscan.io/block/18377042)
The position of the attacker’s transaction is 0, while the position of the other hacker’s attack transaction is 5. As a result, the front-running succeeds, and the real hacker’s attack fails.
How does the frontrunner control the transaction order? We can observe that the gas fees for frontrunning and the gas fees for the real hacker’s attack do not differ significantly. Is it really a coincidence that the frontrunning transaction just happens to execute before the victim’s?
We can observe a transfer of 264 ETH in this transaction.
Then we found that transfer is transfer to this block proposer.
So it is easy to understand that the proposer who propose this block they will get 265 ETH reward. That reward is MEV.
0x01 What is the MEV
MEV is known as Miner Extractable Value, which refers to the value that miners can extract from a block. Miner Extractable Value does not refer to the transaction fees that miners collect for including transactions in a block because these fees are agreed upon by users initiating the transactions, and miners cannot unilaterally increase the fees. MEV refers to the excess profit that miners can obtain by manipulating, removing, or altering the order of transactions in a block.
However, after the Ethereum upgrade, “MEV” was been changed to “Maximal Extractable Value,” which means the maximum value that can be extracted. Typically, there are several common scenarios related to MEV:
Arbitrage
Due to the use of different price oracles, DEXs may have price discrepancies, allowing for profit by buying tokens on the one DEX with lower prices and selling them on the other DEX with higher prices within a single transaction.
Liquidations
A lending protocol is a DEX (Decentralized Exchange) that connects borrowers and lenders, such as MakerDAO, Aave, Compound, and others. Borrowers provide supported collateral to borrow a certain amount of assets (usually requiring over-collateralization). When a borrower’s collateral is unable to repay the debt, liquidation occurs, and liquidators can purchase the collateral at a lower price to settle the debt. Liquidation bots typically monitor borrowers’ assets and initiate liquidations as quickly as possible to acquire the borrower’s collateral.
Sandwich Attack
The “Sandwich Attack” exploits the AMM (Automated Market Maker) mechanism in DEXs. For instance, in the case of the CPMM (Constant Product Market Maker) algorithm, a large buy order can drive up the price of the token. Therefore, when an attacker observes a significant buy order, they initiate a buy transaction just before it (keeping slippage within the acceptable range for the victim). Subsequently, they execute a sell transaction right after the initial buy to profit from the price change.
0x02 Flashbots and PBS
Flashbots
Flashbots is a research and development organization aimed at mitigating the negative impact of Maximal Extractable Value (MEV) on blockchain systems, particularly Ethereum. Their primary goal is to build a permissionless, transparent, and sustainable ecosystem for MEV through products like MEV-Boost. The future of MEV development should focus on cross-chain MEV capture, minimizing value loss, minimizing potential negative impacts on genuine protocol users, and ensuring fair distribution among participants.
PBS
PBS, which stands for Proposer-Builder Separation, originally aimed to split the responsibilities of miners in the PoW era into two parts: 1. Transaction sorting and building handled by Builders; 2. Verification and voting after building taken care of by Proposers. The benefit of this approach is to lower the barrier for nodes responsible for transaction verification, attracting more nodes to participate in verification and further increasing the decentralization of Ethereum.
If Builders directly send transaction bundles to Proposers, it won’t prevent malicious Proposers from replacing MEV opportunities with their own profitable transactions, causing losses to Builders. Therefore, Flashbots introduced a relay layer between Builders and Proposers. This relay doesn’t send the complete block content to Proposers but only the block header. Proposers then sign the block header, and after obtaining the signature, the relay sends the complete block to Proposers. If, at this point, a Proposer attempts to replace the block’s content, they would face penalties under the Ethereum mechanism.
Pay Tips (bribe) to proposer
How hacker pay outband tips to proposer? Simply speaking, hacker will transfer to block coinbase using smart contract. We can see blow.
function payForTips public payable(uint256 payTips) {
block.coinbase.call{value: payTips}(“”);
}
In this code context, “block” can get information about the block, and “coinbase” represents the proposer’s address. Consequently, it is possible to use this code snippet to pay a fee to the proposer of that specific block.
In this incident, the front-running attacker can build a bundle and place their own transaction at the very beginning. As the attacker’s front-running transaction successfully execute, the proposer receives an exorbitant fee of 264 ETH. Consequently, the proposer prioritizes proposing the front-running attacker’s bundle, resulting in the successful front-running attack.
0x03 What we can do
In this attack incident, the front-running attacker gained an advantage by paying exorbitant tips, allowing them to complete the attack before other attackers. Therefore, it seems that the Proposers did nothing wrong but simply chose the bundle with the highest profit for proposing. Of course, many attackers also engage in front-running of normal transactions, sandwich attacks, and so on. How can we prevent such attacks? In fact, when we understand the principles of MEV, we realize that virtually all MEV opportunities are discovered in the public mempool. To mitigate this risk, all we need to do is submit our transactions to a private mempool. For example, Flashbots offers a private mempool to help mitigate this potential risk.
0x04 Reference
https://ethereum.org/en/developers/docs/mev/
https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/block-proposal/
https://noxx.substack.com/p/order-flows-kingmaker-of-the-block
https://eips.ethereum.org/EIPS/eip-4895
https://medium.com/taipei-ethereum-meetup/after-the-merge-mev-309e836698cf
