1. Introduction
In recent years, the notion of Maximal Extractable Value (MEV) in Ethereum blocks production has been extensively discussed and investigated [
1,
2,
3,
4,
5,
6,
7]. There is now a consensus that value from transactions could be extracted through a variety of strategies [
8,
9]. Some of the best-known such strategies are
arbitrage,
liquidation,
and front/back-running sandwiching. The diffusion and relevance of the phenomenon have generated the need for data availability to estimate its overall impact in monetary terms, as well as the performance of alternative strategies [
10,
11]. For example, EigenPhi is a platform offering data provision service on the extent and type of MEV attacks.
A frequent connotation of MEV refers to extracting value from transactions/smart contracts in Ethereum, besides transactions fees. This takes place by changing the order of transactions and/or including additional transactions, which has attracted much attention in both the operational and research spheres. These are the so-called
front/back-running and sandwiching strategies, whose specificity has induced the entrance, in block building and block validation activities, of important new actors in the Ethereum ecosystem, such as Flashbots [
9,
12]. There have also been contributions discussing how the Ethereum protocol for block formation could be modified to prevent MEV attacks [
13]. Moreover, the efficacy of MEV extraction techniques on Ethereum has also been tested in alternative blockchains, like Algorand [
14], where the arrival time of the transactions decides the order of their inclusion in a block.
In the paper we shall focus on these strategies and, henceforth, our discussion on MEV will only refer to them, excluding arbitrage and liquidation from the analysis.
Despite the several contributions on MEV, to our knowledge, very few attempts have been made to try to provide a general characterization of it in a formal way. Mazorra et al. (2022) [
3] do present a definition of MEV, but within an approach and focus that differs from ours. A precise identification of the relevant elements associated with MEV extraction, and their properties, seems to be particularly compelling to clarify the main features of MEV and, possibly, to provide decision-making insights to relevant platforms.
The paper attempts to contribute to filling this gap. To do so, the work is structured as follows. In the next section we define what, for us, are the fundamental elements of a MEV attack on a transaction. As we shall see, these are the associated payoff and the set of ordered transactions used to obtain the MEV. In the work we call these two elements, respectively, the MEV mapping and the ATTACK mapping.
We then discuss some of the main features of such mappings, which allow us to propose a characterization of the MEV notion. Moreover, we extend the analysis to the MEV of a set of transactions and briefly discuss the possibility of a MEV self-attack. Some final considerations conclude the paper.
2. The Fundamental Elements to Characterize One-Transaction MEV
In this section we introduce what, for us, are the fundamental elements of the MEV associated with a single transaction. Initially, we do not specify the identity of the transaction submitter and the value extractor, assuming that they are different actors/users. Later, when considering the possibility of a so-called “self-attack”, identities will have to be specified.
Suppose is the set of transactions in the Ethereum network at some point in time, waiting to be stored in a block. In what follows we consider only MEV attacks on single transactions . For this reason, our approach is static, as we do not consider the dynamics of MEV attacks when the set changes because blocks of transactions are introduced into the blockchain and new transactions are implemented.
Then, each transaction for each single user, induces the following set:
- (a)
(ATTACK DOMAIN of ) The domain of a MEV attack to is defined as the set of transactions that can be selected by the user to extract value from . Hence , such that , is the set of transactions added to by the user for attacking .
We assume that, in principle, each transaction in the network that is not yet stored in the blockchain may generate value that a user could try to obtain by attacking it. Moreover, we assume that contains all the additional transactions the user considers relevant to attack , so that any is irrelevant for the attack. If , it means that to extract value from , the attacker needs to add no transaction to .
Based on (a), it is possible to introduce the following notion:
- (b)
(ATTACK SET of ) The subset is defined as the set of transactions that are effectively selected by a user to extract value from .
Hence, in general, the attacking set of transactions may contain elements from and . It is natural to assume that since, otherwise, it would be pointless to implement additional costly transactions that are not used for the attack. It is worth observing that, in principle, any subset of containing could be an attack set, which is indeed what we are going to assume below.
For the next definition we introduce an additional notion. Take any set of transactions; then indicates the set of orderings and permutations of . This allows us to define the following mapping.
- (c)
(ATTACK MAPPING of The mapping defines the set of orderings and permutations of the transactions in that can be implemented to extract value from . Assuming that is the number of transactions contained in the set , then is an ordering of the elements of and is the number of possible orderings.
Hence, the set of orderings is the image, codomain, of the attack mapping.
The last definition suggests that, to implement an MEV attack on , the transactions in must be ordered in a specific way when inserted into a block. In principle, such ordering can follow any criterion, although in blockchain practice ordering is based on transaction fees or timing.
Definitions (a)–(c) introduced the fundamental notions that identify which transactions, and their possible orderings, are implemented to extract value from . In what follows, we now introduce additional definitions to identify the payoff obtained through such attacks.
- (d)
(EXTRACTABLE VALUE mapping) The mapping : identifies the value that can extract from transaction . This is defined as the monetary payoff that a user can obtain when attacking with .
The above definition of an extractable value is intended to be net of the costs paid to implement the attack. This immediately leads us to the following:
- (e)
(LOCAL MEV mapping) The mapping is the local MEV associated with transaction when using to attack defined as follows:
- (f)
(MEV mapping) The mapping
is the MEV associated with each transaction , defined as follows:
Notice that if stands for the number of transactions in , the possible number of attacking sets , such that and , is , which is exponentially large in .
- (g)
(USER MEV) For each user, the associated MEV, which we indicate by is defined as follows.
Some comments are in order. Definitions (d)–(g) capture the following idea: a transaction can, in principle, be attacked in several ways, that is, with different and different orderings of . Alternative attacks may extract different values from . Hence, for a given attack set , is the maximum among those extractable values. can also be negative to allow for the possibility of a non-profitable attack. Therefore, we defined as a local MEV because it depends on the attack set. The MEV associated with transaction is , defined as the maximum across all attack sets. Finally, the MEV for a user is defined as the maximum MEV over all transactions
Therefore, it is immediately possible to extend the notion to a global MEV by considering the largest MEV across all users.
The following simple example illustrates the above notions. Assume contains two transactions. Moreover, suppose a user intends to perform a sandwich attack on transaction , with transactions , so that .
If
, then the associated set of permutations is given as follows:
Additionally, assume
while
which implies that
, since the most successful attack on
is the sandwich attack
. Assuming, as we shall see in the next Section, that
is included in any attacking set, then
could also be attacked by
with
containing
permutations. Then
is the maximum between
and
. Finally, an analogous reasoning can be conducted for
and the user MEV is given by the largest value between
and
Having introduced the fundamental elements to investigate the MEV, below we are going to discuss some of their features to provide an initial description of MEV.
3. A Characterization of MEV: Some Features of and
For the first characterization of MEV, we present a few features of and . As above, we shall also consider the possibility of attacking with alternative attack sets , with .
Since, as with , we assume it follows that ; that is, two alternative attack sets that differ only for transactions in . Likewise, is the value extracted from when attacking with the set , an ordering of .
- (1)
for all . That is, a transaction is included in all subsets of its attacking transactions. This seems to be a compelling feature for the MEV attacks that we consider.
- (2)
If then That is, if an attacking set of transactions is composed of only the attacked transaction, then there is no positive value to extract from when attacking with
Since , then implies that , and it follows that any attacking set such that satisfies .
The following third feature may hold, though not necessarily for all the attacking sets.
- (3)
A set may satisfy the following: if then, for the user, .
That is, when the user considers attacking with the associated local MEV is no smaller than the MEV associated with any transaction in the attacking set. When the above feature holds, it means that it is inconvenient for the attacker to attack an attacking transaction.
As a matter of fact, an immediate, though interesting, benchmark implication of feature 3 is as follows:
Proposition 1.
Suppose features 1–3 hold for all and all then for all
Proof.
Consider . Then, from feature (3), we have. Moreover, feature (1) implies and choosing , it follows that . Therefore, from feature (3) we also have , and the result is proved. □
It is interesting to conclude this section by asking the following question.
If is a set MEV attacking , then can any , such that induce at least the same local MEV level as ? Namely, is ? Intuition suggests that the answer is yes, however with some qualifications. Before discussing this issue, notice that since , it is also so that . That is, the transactions in are not added to , which implies that they generate no additional transactions fees to the attacker, unlike the attacking transactions in .
To see the point, consider the following example. Suppose a user is implementing a sandwich attack on transaction by considering with its ordering , and that .
That is, the attack with induces the local MEV and consists of placing transaction before and transaction after
Suppose now , and that the ordering is implemented. Then it is plausible that as with the above ordering transaction that appears after the attack and does not affect the ordering conditions before or during the attack by . That is, it would act like any other transaction stored in the same block.
Instead, the ordering would interfere with the ordering and, possibly, be such that Therefore, the above considerations suggest that in general, .
The following fourth feature indicates how may arise.
- (4)
A set may satisfy the following. Define with and Then, for some such it is that .
The above feature says that adding up to the attack set and a set of transactions disjoint from does not decrease the local MEV of
Hence, the next result holds as follows:
Proposition 2.
Suppose feature 4 holds for all . for any such that it holds that
Proof. Immediate. Define and the result follows. □
As above, notice that even though , since , launching the attack with does not require any additional transaction fee to be paid by the attacker, because the added transactions are already in .
Hence, a successful MEV attack on transaction may be possibly implemented by means of several sets. Indeed, for any given , it is possible to define other successful attack sets by appropriately adding up and ordering transactions to
Finally, it may be interesting to state the following simple result.
Proposition 3.
Suppose the attacking sets, with are the only ones such that . Moreover, assume there exists an index such that for all . Then is the smallest set of transactions for a successful MEV attack on
The last result identifies a sufficient set of transactions to extract MEV from transaction . No transaction could be withdrawn from set without compromising the success of the attack. It is intuitive to think that, in real life, would represent the most effective set to obtain MEV, and thus the one likely to be chosen by the attacker.
4. The MEV of a Set of Transactions
In this section, we extend the notion of MEV to consider the possibility that a set of transactions , appropriately ordered, rather than just a single transaction , could be subject to an MEV attack. Though perhaps uncommon in real life, if at all, we believe that, in principle, it is interesting to consider such a generalization of MEV.
In analogy with the above notation, we use to indicate the MEV associated with , while indicates an ordering of the attacking set of transactions ⊆, where and , such that , stands for the additional set of transactions attacking . Moreover, is the local MEV obtained when attacking with .
With sets of transactions, the following new feature can emerge.
- (5)
Two sets of transactions , where and are appropriately ordered and such that may satisfy . This is because and the attack on can always be focused on only.
To illustrate the point, consider the following example. Suppose , and that is implementing a sandwich MEV attack on , such that Moreover, consider and suppose Then, extending the previous reasoning for a single transaction , it may be that the ordering provides at least the same MEV as , since in transaction appears after .
It is important to note that for the monotonicity feature to hold, we assumed, as illustrated by the example, that in the ordering the additional transactions could interfere with the initial ordering of , because in transaction is placed between and . This seems to be a natural possibility to allow for, since in a block the order of the transactions stored could always be chosen by the validator.
An immediate implication of property (4) is that may hold for
5. Self-Attack
In the previous sections we did not specify the identity of a transaction submitter and of the MEV attacker of that transaction. It was, however, assumed that if the submitter is user , then the attacker is a different user .
However, at least in principle, one could ask the following question: if is the submitter of transaction , can also be the attacker of transaction ? That is, can there be an MEV self-attack? Although apparently paradoxical, in our framework the question seems to make perfect sense and deserving a discussion, albeit short.
In reality, self-attack does not seem to be widespread. Therefore, it would be interesting to understand why this is so. Among other possible reasons, we think there could be at least the following two. The first may be that is unaware about MEV and, therefore, of the possibility of self-attack. The second is that is aware of MEV, and also of the possibility of self-attack, which, however, is too costly to implement as compared to its returns.
An interesting example for this may be represented by swapping assets transactions in Automated Market Makers, such as Uniswap. Consider a liquidity pool with two assets,
and
, that can be swapped with each other. Additionally, suppose the current quantity of the assets, respectively,
and
, are
. Finally, assume user
is interested in obtaining as many units of
as possible against
units of
. In what follows we adopt the Uniswap Constant Product Function,
to determine the exchange price between
and
.
To do so we can envisage the following two procedures.
- (a)
The user swaps against the quantity
Hence, in this case, unit of swaps with units of .
- (b)
Alternatively, the user can first swap units of to obtain in exchange units of , so that now the liquidity pool is with and . Then, the user can swap units of against about units of Hence, eventually, the pool size will be and .
Therefore, subtracting from the units of are initially deposited, the final number of units obtained by the user is . Likewise, summing up units of , obtained after the initial deposit of units of to the units of available from the beginning, we reach the conclusion that with units of the user obtains units of . Therefore now unit of provides units of , that is twice as much as before.
Procedure (b) can be interpreted as a back-running self-attack on the first transaction, which, from the example seems sufficiently simple and rewarding for the user. If this attack is not widely diffused, it could be because of the high transaction fees to be paid by the user or because the user may not have units of to swap. Moreover, the second attacking transaction must occur at the right time for the swapping price not to change too much. If this is not the case, the user may even lose rather than gain from the attack. Therefore, sufficiently risk-averse users may decide not to implement (b).
As a consequence, self-attacks may not be profitable for .
6. Conclusions
In the paper we proposed a simple way to formalize the notion of MEV, concerning front/back-running and sandwich attacks, and, based on the defined fundamental elements, discussed some of its distinguishing features. We saw how the ATTACK mapping and the MEV mapping represent the building blocks of our framework, and their properties are key to providing a characterization of the MEV notion. Although in principle, non-negative value could be extracted from any transaction in the Ethereum network, we suggested that the MEV associated with the attacking transactions may be smaller than the MEV of the initially attacked transaction. This seems to be a needed requirement for the MEV mapping for attacks to enjoy some stability, namely to prevent users from beginning an attack and then dropping it to attack an attacking transaction. However, a thorough investigation of this topic would require a dynamic context, which we do not consider. We also argued that the same MEV could be obtained with alternative attack sets, although it is reasonable to think that users would select the smallest set of transactions to achieve their goal.