A2MM: Mitigating Frontrunning, Transaction Reordering and Consensus Instability - Liyi Zhou

all right so thanks for the introduction tina um so today we are going to talk about a2mm which is uh which is an application layer solution we propose to mitigate um mev this is a joint work with kaiwa and asa so to start i want to discuss why maximizing mev even in a decentralized way might be problematic sometimes so let's consider a simple scenario where we have two minors one is honest and the other one is malicious so both of the miners are trying to um append to block b1 and um they try to they both observe some mvv opportunity on the network layer and they are trying to extract them so let's assume that the honest miner succeeds in mining the muv opportunity once the monitor's miner receives block b2 from the network layer it will need to decide whether to forfeit and i mean the immunity opportunity or not so there are two cases in the first case the malicious minor fourth is the movie opportunity so it jumps onto b2 um just like following the standard ethereum protocol to my on the longest um block blockchain um however mining on the longest chain might not be the optimal strategy because the miner can choose to keep mining on block c2 um yeah attempt to fork the blockchain um if the malicious miner is lucky then the fourth chain can catch up um to b2 and then um this forking behavior is actually quite dangerous because it's going to waste the computational power of the honest miner and it's also going to increase the stealth rate which makes the game easier for the adversary to to do double spending attacks and selfish mining attacks so um how does the um how does the malicious miner decide whether to fork or down or not so there are many factors he needs he needs to consider what's the average block reward was the mev reward was the hashing power he controls and how long does it take to switch from mining the old block to the new block so in order to quantify this problem we have modeled the entire thing as a markov decision process so based on the funding in this paper we find that if the adversarial miner owns 10 percent of the hashing power directional behavior is to fork the blockchain if the mvv is four times larger than the average block reward but four times is nothing we have observed mev opportunities exceeding 874x of the average block reward this is actually the bzx attack in the past so here is the critical takeaway message when the muv speak even small miners would fork the blockchain in order to steal the mbb opportunity from the other miners so although we have not seen substantial efforts indicating such behavior at the moment um according to our quantifications this is actually the optimal strategy to do um so why the miners are not doing it at the moment uh remember one year ago miners are not extracting mev so i believe this is basically because minor miners do not have the setup at the moment to help them the blockchain um i really hope i do not see this kind of working behavior in the future because this is definitely going to be a disaster and i um i hope um flashbacks can can also you know be aware of this risk and try to mitigate um the problem so um so is there any simple way to reduce the mvv um to to kind of mitigate the risk so when i think about this problem i always ask myself the following two questions so who is the creator of the mev and if the creator can close that movie itself so this is very similar to what tom said about the unionized idea where which implemented by the b protocol so i will give a different example here um so let's think about an arbitrage opportunity let's say a user makes a trade on unit swap in this transaction here this will cause an arbitrage opportunity between unit swap and sushi swap um so what we observed um previously was meb searchers will try to background this opportunity with the background in arbitrage transaction so if the mbv is not extracted in time just in time within the same block then the searchers will try to front run in the next block with the arbitrage transaction so here comes the core idea of of a2mm so instead of leaving the money on the table why don't the trader the black trader here in orange why doesn't the trader atomically close them ev themselves by performing the arbitrage atomically in one single transaction so what's the pro and cons of a2mm um a2mm will minimize mdb um it is backward compatible so it doesn't require any changes to the ethereum implementation and it's a decentralized solution it doesn't require any additional trust assumptions which is different from um other like for example background me background me services and where they rely on private communication channels with the miners a2mm also have some financial benefits but it also has some cons so ethereum has this block gas limit so sometimes um it's impossible to extract old mevs um in a single transaction which means that some mvvs uh some some mv muvs will be left for the next block and searchers will do front running in the next block it's it's not triple to determine optimality on chain sometimes so especially if the if the underlying pricing formula is complex for example it's quite hard to determine the optimal parameters for arbitrage between unit swap and curve also a2mm only mitigates some types of mev not everything so here i give one example of one type of one type of an ev that cannot be mitigated by hmm this is actually inspired by ritalic's comment on on our medium article so in a sense um there is a contract which rewards an encoder after certain block number so um the creator of the mbb opportunity opportunity actually wants the opportunity to to appear in a future block in a way that it doesn't want anyone to close the mev opportunity atomically therefore a2mm will not be able to mitigate this muv this is something different from a2mm but i also want to mention um in our previous paper we have um actually proposed a simple application layer solution for sandwich attacks so here we show a concrete example this is units for version one easier to sign market at block number nine minute so on the x-axis we have the ether transacted by the victim and on the y-axis we have the ether transacted by the adversary the color here indicates um how much revenue the adversary can gain so so so um so what's in what's interesting here is um there is this threshold which we call it the minimum profitable victim input if the victim transacts an amount that's below this threshold then no matter how much the adversary trades for the sandwich transactions it's always not going to be profitable so it's there's no incentive for the attacker to attack um so um so yeah so so basically there is a application layer solution for sandwich attacks and i hope in the future we can see some amm protocols implementing this solution so to summarize um let's minimize mdb to to reduce the risk of walking thanks that's that's that's it