Guest: Zihao Li, PhD student at the Hong Kong Polytechnic University
Organizer: aididiao.eth, Foresight News
This article is a transcript of the video shared by Zihao Li, a PhD student at the Hong Kong Polytechnic University, in the Web3 Youth Scholars Program. The Web3 Youth Scholars Program is jointly initiated by DRK Lab, imToken, and Crytape, and invites well-known young scholars in the field of cryptography to share their latest research results with the Chinese-speaking community.
Hello everyone, I am Zihao Li, a third-year PhD student at the Hong Kong Polytechnic University. Today, I will share the topic “Unveiling MEV Activities in Ethereum Transaction Bundles.” In simple terms, it is about how to discover unknown types of MEV activities in the Ethereum network through transaction bundles. First, I will provide a basic background introduction, such as the concept of MEV, transaction bundle mechanism, and the background of our work. Then I will explain the complete workflow and some design ideas in detail, such as the design principles we based our workflow on, the datasets we have, and the tools we used to evaluate our workflow on various metrics. Finally, I will introduce three applications and their relevant empirical analysis results.
- Sui Lutris Report Digest Core Distributed System Protocol of the Sui Public Chain
- Stanford Blockchain Weekly Summary of Theoretical Practicality, ZK, Modularization, and Current Development Status of Bitcoin Ecosystem
- The Decentralization Challenge of Ethereum Lido Becomes the Target of Criticism for Monopoly
Background Introduction: MEV, Transaction Bundles, Motivation
MEV activities refer to arbitrageurs in the blockchain who generate arbitrage transactions by monitoring the blockchain network, including block states, etc. Some transaction information is propagated on the blockchain P2P network or stored in the transaction pool of miners or validators before being formally included in a block. When an arbitrageur detects this transaction information, they generate their own arbitrage transactions using certain strategies and specify the position of these arbitrage transactions in the next block, for example, they may want to place them at the head of the next block or execute them immediately after a specific transaction to propagate the same arbitrage transactions. We can consider these specified arbitrage activities as MEV activities. For example, if an arbitrageur detects a fluctuation in asset prices, they can buy the corresponding assets in a low-priced transaction pool and sell them at a higher price in another fund pool. We consider this as an MEV activity.
Currently, MEV activities mainly revolve around the DeFi ecosystem, as the DeFi ecosystem has attracted over $40 billion in funds, including Ethereum and other chain DeFi ecosystems. Here, we need to mention a concept related to the DeFi ecosystem, called DeFi action, which refers to an atomic service operation provided by a DeFi application. For example, as we know, AMMs support the exchange of different types of assets, and a user can sell a USDC and get an ETH, which can be defined as a DeFi action. We can represent MEV activities using DeFi actions, for example, if a user detects price differences on different AMMs, they can profit from the price difference by buying low and selling high. We can represent this MEV activity as two DeFi actions.
Currently, there are three main types of research on MEV activities in the academic community. They are sandwich attacks, reverse arbitrage, and liquidation. In our dataset, we found that these three types of MEV activities occurred more than 100,000 times. There is actually a question here. After we know the definition of these MEV activities, how do we identify the occurrence of these activities? If we want to identify these MEV activities, we need to identify all of the arbitrage activities, such as what trades the arbitrageurs generate and what types of arbitrage are involved in these trades. Only then can we determine which type of MEV activity is occurring. The entire process heavily relies on our definition of known MEV activities. Taking sandwich attacks as an example, after we know the definition of sandwich attacks, in order to determine the arbitrage value of sandwich attacks and the corresponding arbitrage trades, we need to set many rules based on the definition and use these rules to filter out the candidate arbitrage values and trades for sandwich attacks. When using this approach to identify known types of MEV attacks, there are two questions. The first question is whether the three common types of MEV activities we know can represent all MEV activities. Obviously, they cannot, because the DeFi ecosystem is constantly evolving and new applications are being developed, and the strategies of these arbitrageurs themselves are also constantly iterating. The second question is how can we discover these unknown MEV activities. Let’s take a look at the transaction bundle mechanism with these questions in mind.
The transaction bundle mechanism was first proposed in 2021. Simply put, users can organize a queue of transactions, which can be a single transaction or multiple transactions, and then send these transactions to relayers in the blockchain network. The relayers collect these transactions and directly and privately send them to relevant miners or validators. Currently, relayers run transaction bundles to undertake relay tasks. The transaction bundle mechanism has a very important feature. When users construct transaction bundles, they can include transactions that have not yet been confirmed on the chain, and the order of transactions in the bundle can be manipulated arbitrarily. At this time, users or arbitrageurs who use transaction bundles can design their own arbitrage rules. For example, they can design more complex and profitable MEV activity strategies. Taking sandwich attacks as an example, without using transaction bundles, an arbitrageur of sandwich attacks needs to generate at least one pair of transactions to achieve arbitrage, and this pair of arbitrage transactions can only target a specific transaction. This attack transaction requires execution in a certain order to ensure its successful arbitrage. However, if an arbitrageur uses transaction bundles, they can collect many transactions that can be arbitrage, and only need one corresponding pair of arbitrage transactions to simultaneously arbitrage multiple transactions. Once this transaction bundle is confirmed on the chain, it will definitely be arbitrage successfully, and because it simultaneously arbitrages multiple tradable transactions, the profit from this arbitrage is also higher.
The characteristic of transaction packages is that they have rich and complex MEV activities. Users who use transaction packages encapsulate their complete transactions in the transaction package and then send them to the relays of the P2P network, and finally to the corresponding miners and validators. We can accurately and completely identify all activities through transaction packages. Therefore, we can compare and accurately identify some unknown MEV activities through transaction package media.
Workflow and Design Ideas
Next, let’s introduce our workflow in detail. How do we discover unknown MEV activities through the medium of transaction packages? The core workflow includes two tools. First, after collecting the transaction package from the relay, we use the ActLifter tool to identify each DeFi action in the transaction package. After obtaining the results, we represent all behaviors in this transaction package. Then, we use the ActCluster tool to cluster the transaction packages with similar activities together, and discover new MEV activities more quickly through the clustering results. If we want to discover unknown MEV activities, it is inevitable to manually confirm whether the MEV activity is an unknown type. Of course, the goal of our work design is to minimize the amount of manual work as much as possible and make the whole process as automated as possible.
Currently, there are some tools that can identify MEV activities from transactions. We can roughly divide them into two categories. The first category is pure manual summarization rules, and the second category is pure heuristic rules, which use a purely automated heuristic rule to identify specific types of MEV activities. For example, after it identifies some transfer information, it checks whether it meets the heuristic rules. If it meets, it can identify the corresponding activity. The first method of pure manual summarization rules can achieve relatively good accuracy, because this process is completely manual analysis of specific applications, and it can ensure that the detection results are accurate. However, the analysis task requires a very large amount of work, so it cannot cover all DeFi applications. Although the second method can achieve pure automation, heuristic rules can only cover some specific types. On the other hand, there are some design issues with heuristic rules, which result in unsatisfactory accuracy of their identification.
We have designed our workflow by integrating the advantages of both methods. We can identify ten currently major DeFi actions. We only need to manually determine which event in the DeFi application corresponds to which type of DeFi action after it is initiated, and then we can eliminate the need for manual analysis and fully rely on automated analysis. The second method can automatically identify DeFi actions, but it cannot determine whether the analyzed object is related to MEV activities. For example, if we identify a SWAP transfer, it may identify two completely unrelated transfers as one DeFi action, and naturally, the result of its identification is wrong. However, we can use this information to filter out information that is truly related to DeFi actions. After obtaining this information, we can use automated methods to avoid some error situations that occur in the second method.
For example, here is a transaction involving four transfers in total. The order of occurrence, amount of funds, and categories are indicated by numbers. In this process, AMM actually initiates an event related to the Swap action. The first type of method needs to recover the current content based on some parameters of the event after it is determined that the event has been initiated. For example, it needs to examine the code, business logic, and some function variables of Contract 699 to recover the current content. After obtaining this information, we designed a rule based on its unique asset transfer characteristics. For example, the rule we extracted is that the current operation of DeFi Contract involves receiving and transferring different types of assets. When we find two asset transfers that meet this characteristic, we can recover the corresponding Swap action content. The second type of method directly matches two asset transfers, where the accounts involved in the transfers receive and transfer different types of assets. It considers the first and fifth transfers as a pair of related transfers and considers the intermediate account as an AMM. Obviously, we can see that the identification result is inaccurate.
We have summarized rules for corresponding DeFi action types based on manual analysis of related events. Although the results are obtained through manual analysis, we still try to refine the manual analysis process into a semi-automated process to ensure the reliability of the entire process. We will query the official websites, developer documentation, and contract source codes of DeFi applications from DeFiPulse.com and Dapp.com. Our parsing tool can extract some descriptions of events in the documents, such as how the event is defined with tokens and in which functions, as well as code snippets and comments used by these events. After extracting these things, we analyze and discuss them manually to finally determine that there are 88 events corresponding to different types of DeFi actions.
We input the transaction to be analyzed into this dictionary and parse which events have occurred in the transaction. After the event appears in this dictionary, we extract key information based on the corresponding rules, such as which contract is operating this DeFi action, what is the type of this DeFi, and which asset transfers are related to this DeFi action. After obtaining such content, we summarize the rules for asset transfers and use these rules to match the final DeFi action. Starting from the definition of ten DeFi actions, we summarized the rules for asset transfer characteristics. After collecting this information in the previous step, we use these matching rules to identify which DeFi actions occurred and what specific content in this transaction. After ActCluster identifies each transaction in the transaction package, we can represent the behavior of the transaction package.
First, let’s understand the design principles of ActCluster. We know that human analysis is inevitable in this process, and it must rely on humans to determine whether the activities of a transaction package are unknown types of MEV activities. Based on this, our basic idea is to cluster some transaction packages with similar activities together. For each cluster, we only need to randomly sample one or several transaction packages for analysis, which can accelerate the process of human analysis and ultimately discover different types of MEA activities. When we cluster transaction packages using cluster analysis, we face a dilemma. When we set the clustering intensity of transaction packages relatively coarse, transaction packages containing different types of activities will be clustered together. At this time, although the number of clusters is reduced, the corresponding workload of human analysis is also reduced, but some new MEV activities may be missed. If we set the clustering intensity fine, although we can distinguish transaction packages corresponding to similar but different MEA activities, the workload of related human analysis increases significantly.
Based on this problem, we designed the method of iterative clustering analysis, which performs clustering analysis in multiple rounds of iteration. In each round, we remove the transaction packages containing newly discovered MEV activities from the previous rounds, and then increase the clustering intensity for the remaining transaction packages. We cannot directly cluster transaction packages using traditional clustering methods because a transaction package actually contains multiple transactions, and a transaction can contain multiple DeFi actions. If we represent the entire transaction package, its structure is heterogeneous and layered. At this time, we use representation learning methods to represent the content of this transaction package in a latent space. The advantage of using representation learning is that we do not need deep learning and understanding of the data we want to analyze and process, nor do we need rich domain knowledge. We only need to do data-driven processing.
For example, we only need to label the transactions included in the transaction package with the MEV activities they contain. If we know the definition of an MEV activity, it is relatively easy for us to design corresponding rules to automatically detect whether it exists. We can automate the labeling of these transaction packages for representation learning. Our clustering analysis is iterative, and after each iteration, we can discover new MEV activities. At this time, we can enrich the labels corresponding to these newly discovered MEV activities in our representation learning process. When the labels used in the representation learning process are enriched, the performance and efficiency of the entire representation learning model can be iteratively improved, and the representation ability of the transaction package’s activities in the representation learning can be iteratively enhanced. A transaction package can actually contain multiple transactions, and a transaction can actually contain multiple DeFi actions. We need to represent the transaction package. First, for each type of DeFi action, we define a standardized parameter, such as which contract is being operated, and the quantities and types of assets received and transferred. We define each type of DeFi action in this way. If we identify multiple DeFi actions in a transaction, we represent them using action blocks, so that the transaction block corresponding to this transaction can be represented, including the source information of the transaction, such as who initiated the transaction and who it was sent to. When DeFi actions occur in a transaction, we fill them in order using action blocks. Each transaction is represented by a transaction block, and finally, we obtain the structure of the transaction package, which can be regarded as a matrix. After representing the transaction package, we can proceed with representation learning. Each transaction package has a unified structure, and then we can use models for batch processing.
Performance Evaluation
Next, we will share the methods we used to evaluate the performance of the workflow. The dataset for our entire analysis process is obtained through the API provided by Flashbots, and we collected transaction package data from February 2021 to December 2022, including over 6 million transaction packages and 26 million transactions.
We designed some tools to compare the accuracy and completeness of DeFi actions. It is worth noting that among these on-chain tools, only Etherscan can recover DeFi actions from transactions through its website and the information it provides. For tools like DeFiRanger, we reproduced their methods based on their papers. In addition, we designed a tool called EventLifter to attempt to recover DeFi actions directly from transaction events. We tested ActLifter under different configurations and used various tools to compare the accuracy of identification. As for ActCluster, our main idea is to use ablation learning. After ablating a part of the ActCluster module for newly identified activities, if we still want to identify some new activities that have not been discovered, we need to analyze how many transaction packages manually or how much manual analysis work we need to do. For example, we performed an ablation on the dynamic label update module in the ActCluster representation learning module, which means we completely removed the entire process. We randomly sampled from 6 million transaction packages and observed how many transaction packages we need to manually analyze in order to discover the same number of new MEV activities.
Under the same configuration, our tool can achieve close to 100% accuracy and completeness. However, for other tools like Etherscan, although its accuracy can reach 100% which is satisfactory, it misses a lot of DeFi actions. Etherscan itself does not have an open-source method. We speculate that it may use manual analysis to summarize rules for identifying DeFi actions, which may lead to missing some types that cannot be covered manually. It is worth noting that Etherscan does not provide an automated interface, so if you want to perform large-scale identification, you cannot directly complete such a task. DeFiRanger, which relies solely on implicit rule identification, does not provide satisfactory accuracy and completeness. After conducting experiments on ActCluster, we found that by performing four rounds of analysis, we only need to analyze 2,000 transaction packages to identify 17 unknown MEV activities. After ablating some of the modules, we may need to analyze up to 170,000 transaction packages in order to identify the aforementioned 17 types of unknown MEV activities.
Evidence Analysis and Applications
What are the specific applications of the methods we can use to identify unknown types of MEV activities? First, can it enhance existing MEV mitigation measures and defend against some MEV activities? The second is whether we can analyze the impact of MEV activities on the blockchain ecosystem more comprehensively, including the impact on blockchain forks, reorganizations, and user financial security.
As mentioned earlier, MEV boost network attackers will run tools to take transaction packages from users and distribute them to the miners and validators connected to them. The relayers remove the transactions containing MEA activities from the received transaction packages, reducing the negative impact of MEA activities on the blockchain in this way. The main idea of this step is to design corresponding rules based on the definition of existing MEV activities to detect whether the transaction package contains MEV activities. Obviously, these relayers cannot exclude transaction packages containing unknown MEV activities. Based on our workflow, we have designed a tool called MEVHunter, which can detect new types of MEV activities from transaction packages.
The detection results show that there are over 1 million transaction packages containing reverse arbitrage MEV activities, and 30% of the transaction packages in another 6 million transaction packages contain three known types of MEV activities. For the newly discovered MEV activities, we found that nearly half of the transaction packages only contain these new MEV activities. If relayers use the MEVHunter tool, they can help filter out 3 million transaction packages containing MEV activities and choose to remove these transaction packages, reducing the negative impact of MEV activities on the blockchain.
The second application is to explore the impact of new types of MEV activities on blockchain forks and reorganizations. Some previous studies have reported that financial miners are motivated by the profits of some MEV activities to fork and reorganize the current blockchain, conduct their own MEV activities, and enjoy the profits. For example, when the profit from MEV activities in a block is four times the block reward, no less than 10% of the miners will fork and reorganize this block.
First, we use the MEVHunter tool mentioned above to identify which transaction packages contain new MEV activities, and then estimate the corresponding strength of these MEV activities based on the profits of miners in these transaction packages. Here, we need to introduce a concept. In the transaction packaging mechanism, these arbitrageurs usually share a portion of the MEV activity profits with the miners to ensure that their arbitrage transaction packages can be included in the blockchain. The miners will ultimately choose the transaction package with the highest profit to be included in the blockchain. We can estimate the MEV activity in each transaction package based on this profit. According to our statistical results, there are more than 900 blocks where the MEV profit is four to eight times the block reward, and one block even has a MEV reward that is over 700 times the block reward. We use the framework of Markov decision to determine how many miners can be motivated to fork and reorganize a block given a certain MEV profit. We ultimately found that there are over 1,000 blocks that can motivate no less than 10% of the miners to fork and reorganize the block. And for the most severe block, no less than 0.006% of miners will fork and reorganize the block.
The third application is to explore the impact of MEV activities on the financial security of blockchain users. MEV activities can actually cause delays in the time it takes for blockchain users’ transactions to be included in the transaction pool or P2P network, which is one of the main threats to users’ financial security posed by MEV activities. If a user’s transaction is delayed in being included in the blockchain, arbitrageurs will have more time to design more complex and profitable MEV activities. The third application is to compare the impact of MEV activities on the waiting time for user transactions to be included in the blockchain. In the first step, we also collect the waiting time for transactions. We mainly deploy nodes on the network and record the time when this transaction is first discovered on the network, as well as the time when this transaction is finally included in the blockchain, and finally calculate the waiting time. We use the three quartiles of the waiting time for all transactions in each block to do statistics, so that we can organize the waiting time for transactions into a time series on a per-block basis. Correspondingly, the MEV activities in each block are also characterized by the income obtained by miners from transaction packages containing new MEV activities in each block, so that we have multiple time series. We use Granger causality tests to evaluate the impact of MEV activities on transaction time. The causality test can determine whether fluctuations in one time series cause fluctuations in another time series, and the range and duration of its impact on another time series. When MEV activities fluctuate, whether they cause longer waiting times for user transactions, and the range of influence in the subsequent number of blocks.
When the p-value of the causality test is less than or equal to 0.5, it means that the waiting time for transactions in this block is extended due to the influence of previous MEV activities. According to the analysis results, it can be found that when MEV activities occur, 50% of the waiting time for transactions in the next two blocks will be extended. After MEV activities occur, 25% of the waiting time for transactions in the next 30 blocks will be extended. Miners or validators will put transactions with lower gas fees at the end of the packaged blocks. The lower the gas fee for user transactions, the larger the range of influence from MEV activities, and the longer the waiting time will be extended.
In conclusion, we first shared how to discover unknown MEV activities through the workflow, as well as the detailed design of the two modules in the workflow. Then we verified the effectiveness of the workflow through empirical analysis and listed three applications. Currently, we have discovered 17 new MEV activities using the workflow.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
