Ethereum is a Dark Forest

In the Ethereum mempool, these apex predators take the form of “arbitrage bots.” Arbitrage bots monitor pending transactions and attempt to exploit profitable opportunities created by them. No white hat knows more about these bots than Phil Daian, the smart contract researcher who, along with his colleagues, wrote the Flash Boys 2.0 paper and coined the term “miner extractable value” (MEV).

Phil once told me about a cosmic horror that he called a “generalized frontrunner.” Arbitrage bots typically look for specific types of transactions in the mempool (such a DEX trade or an oracle update) and try to frontrun them according to a predetermined algorithm. Generalized frontrunners look for any transaction that they could profitably frontrun by copying it and replacing addresses with their own. They can even execute the transaction and copy profitable internal transactions generated by its execution trace.

Basically, frontrunners could automatically copy any transaction in the mempool, replace its addresses with their own and make sure that the duplicate operation gets picked up by miners first. In the current situation, that meant $10 million could’ve been easily stolen by frontrunners in a matter of seconds. Secrecy was essential.


In the articles, these frontrunner bots look for exploitable transactions – in both cases a BURN call – in the Ethereum mempool. Upon finding one, the bots create a new BURN transaction replacing the original destination address with a new address and ensure the copied transaction is picked up ahead of the original transaction. This reverts the original transaction as INSUFFICIENT FUNDS because the funds have been successfully stolen by the frontrunner bot.

For the team —

Could the shield/unshield (or other) functions in Incognito’s Ethereum smart contracts 1,2 be susceptible to a similar style attack? Could some of the ideas in the first article be used to strengthen the security of the Incognito smart contracts?


Well in the case of a few seconds, I’d like to point out I’ve never had a transaction completed that quickly here!

hey @Mike_Wagner, yeah, front-running has been a well-known attack in blockchain generally and Ethereum particularly. And Incognito has also tried to prevent the sort of attack right from the design phase.

Specifically, in the shielding process, once one deposit tokens to Incognito contract, he would enclose his Incognito address in the contract function call so whoever takes (even a front-runner) the deposit proof and submit to Incognito chain, the shielded tokens would still be issued to original user’s address.

Similarly, in the unshielding process, once one burn pToken over Incognito chain, he would enclose his Ethereum address in the burn transaction’s metadata so Ethereum token would always unlock to the user’s address regardless who submits the burn-proof to the Incognito contract.


@duc Thanks for the detailed reply!

Love that you guys are ahead of the curve, so to speak, and already mitigating these type of attacks in the very design of the Incognito Chain protocol.


Speaking of front running:

1 Like