An arbitrage robot in Mempool, a super predator in the dark forest of Ethereum
Dan Robinson and Georgios Konstantopoulos, Paradigm research partner
Perry Wang
This is a horror story.
challenge
Like ordinary people, I have spent a great deal of time on the Uniswap Discord # Support channel. (Disclosure: Uniswap is part of Paradigm.)
On Wednesday afternoon, a question was raised about whether it would be possible to get the token back if the token was mistakenly sent to the smart contract itself.
My initial thought was that these tokens would be locked up forever. But late that night, I suddenly realized that if the tokens were still there, they could be taken away -- by anyone.
When anyone invokes the burn function on the Uniswap core contract, the contract will measure its own liquidity scrip balance and burn &Nbsp;; , returns the withdrawn token to the address specified by the caller. This is a core part of the expected behavior of Uniswap V2 (the basic mechanism is described in chapter 3, Section 2, of the Uniswap V2 white paper).
I found the contract. Liquid tokens still exist, worth about $12,000.
This means three things:
- There is a ticking clock. Even if no one else notices the free money, anyone can withdraw their liquidity at any time and accidentally receive tokens from the contract.
- I can play white hat hacker and try to retrieve tokens for people who mistakenly sent them to Uniswap contracts. Quite simply, you simply call the burn function from the pool and pass the token to your address.
Unless... I know it's not that simple.
The dark forest
The Ethereum blockchain is known to be a dangerous environment. If you can make a profit by exploiting a loophole in a smart contract, someone will. The frequency of new hacks suggests that some very smart people spend a lot of time looking for dodgy contracts.
But this insidious environment is nothing compared to memory pool mempool (a set of pending, unidentified transactions). If the blockchain itself is a battlefield, mempool is worse: a dark forest.
The Dark Forest The Dark Forest and NBSP; It's my personal favorite science fiction. It was the book that gave rise to the concept of the "dark forest", an environment in which advanced predators were constantly killing. In such an environment, revealing someone's hiding place is tantamount to destroying him or her. (The concept was also the inspiration for the Dark Forest game in ethereum Beta.)
In Ethereum Mempool, these super-predators take the form of "arbitrage robots." Arbitrage robots monitor pending trades and try to profit from every opportunity they create. The white-hat hacker most familiar with these robots is Phil Daian, an intelligent contract researcher and his colleagues who wrote Flash Boys 2.0& NBSP; The paper created the concept of miner extractable Value (MEV).
Phil once described to me a cosmic horror killer, what he called a "generalized front-runner." Arbitrage bots typically look for specific types of trades in mempool (such as trades on a decentralized exchange called DEX or a prediction machine update) and try to get ahead of the game with a predetermined algorithm. Generalized front-runners look for any trade that makes money, quickly copy their trade and replace the address in the original trade with their own address. They can even execute trades and replicate the lucrative internal trades generated by their execution trajectory.
That is why it is not so simple to say that the money sent by mistake was saved. Anyone can call this BURN&Nbsp; NBSP;; Function. If I submit a burn The deal, like a neon sign of "free money," announces the opportunity directly to the outside world. If these terror killers were actually in mempool, they would have seen this trade, quickly copied it, transplanted it and took over my trade, taking the money before I could trade it.
Note that this environment is far more brutal than the Ethereum blockchain state itself. The free money had been sitting undetected on the Ethereum blockchain for about eight hours, waiting for some BURN&Nbsp;; Sweeping. But any attempt to take the money would quickly be accurately sniped in the air.
save
To withdraw my money without spooking the robot, I need to hide my trades so that the robot can't detect calls to the Uniswap trading pair. This involves coding and deploying custom contracts. I am the thought leader of the DeFi domain expertise and I have never actually deployed any contracts to Ethereum before.
I needed help, and it was past midnight in America. Fortunately, some of the best intelligent contract engineers I know live in European time zones. Georgios Konstantopoulos, my colleague at Paradigm, agreed to assist in deploying the contract and submitting the transaction. Alberto CuestaCanada, chief engineer at Yield, another company we invested in, offered to execute the contract.
Some good Ethereum security engineers helped us develop a plan to hide the truth. In addition to hiding the call as an insider trade, we also split the trade into two parts: a SET trade that activates our contract, and a GET trade that rescues the funds that activate (if the contract is activated). It is implemented in the following path:
1. Deploy a Getter ; The contract, called by its owner, does not make BURN&Nbsp until it is activated; Call, otherwise restore the original.
2. Deploy a NBSP; A Setter contract, called by its owner, will activate NBSP; Getter Contract.
Submit in the same block & NBSP; set Trading and GET trading.
If the attacker only tries to execute the GET trade, it restores the contract without invoking the BURN function. What we had hoped to do was execute NBSP in the attacker's turn; The set and & have spent get Trade, find internal call pool. Burn The order then tries to overtake us when we have completed the transaction.
Our code script to save the money:
But to our surprise, this is a NBSP; get The deal was rejected by Infura, even if we manually overwrote the Gas estimator. After a number of failed attempts and resets, we became increasingly under time pressure and, in the hope of getting away with it, let the second trade slip into the subsequent block.
This turned out to be a fatal mistake.
Our & have spent get The trade did make it into the earlier block, but a NBSP; UniswapV2: INSUFFICIENT_LIQUIDITY_BURNED Error means its fluidity in Uniswap is gone. As a result, seconds after our GET trade entered mempool, someone executed the call and walked away with the money. The monsters of the dark forest devoured us anyway.
lesson
Real monsters
We did know that the generalized front-runner robot existed. But until you see them in action, you probably underestimated them.
The hope was that passing a variable from storage as the target address, through an authorization contract that USES internal calls to do the job of saving the money, might protect us, but it didn't work.
If you find yourself in this predicament, I suggest you talk to Scott Bigelow, vice President of engineering at Amberdata, a security researcher who has been studying the subject and has a prototype implementation strategy that makes it easier to hide things.
Don't take any chances
We should have stuck to the original plan even under time pressure. If we spend more time with the code script, tweaking the contract (perhaps changing the Getter contract to do nothing rather than being called before activation and then reverting to its original state), or even synchronizing our own nodes to avoid using Infura, we might be able to get the trade into the same block.
Don't rely on the regular infrastructure
The weirder your trick, the harder it is to block it with an existing infrastructure like Infura. In our case, we tried to submit a transaction that looked like it would fail based on the current blockchain state, and Infura had reasonable safeguards to prevent it. Using our own nodes might avoid this problem.
Even better, if you happen to know a miner (we don't), you can have them package their trades directly into a block, skipping mempool entirely and avoiding man-eating monsters altogether.
The future will only get scarier
This is just one example of a front-running deal. It happens countless times a day. Today's front-runners are just robots. It could be the miners tomorrow.
Miners are not taking advantage of these opportunities so far, leaving their money on the table. In the future they may reorder and commit transactions in mempool for their own benefit. Worse, they could destabilize the blockchain by reorganizing blocks dug up by other miners in an attempt to steal meVs that do not belong to them.
We believe that this terrible future can be prevented. Optimism (Another Paradigm investment company) has an ambitious vision of how MEV can be redirected to preserve the ecosystem's benefits, as part of their Layer 2 expansion solution Optimistic Rollup.
Thanks to Alberto Cuesta Canada, Scott Bigelow, Phil Daian, Charlie Noyes and Sam Sun for their comments on this article.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
