Private transactions can neither completely eliminate the risk of being attacked nor reduce market fees.
Speech: Wang Ye, Assistant Professor, Department of Information and Computing Science, University of Macau
Compilation: aididiaojp.eth, Foresight News
*This article is a compilation of texts shared by Wang Ye, Assistant Professor of the Department of Information and Computing Science at the University of Macau in the Young Scholars Program. The Young Scholars Program is co-sponsored by DRK Lab, imToken and Crytape. Well-known young scholars in the encryption field will be invited to share some of the latest research results with the Chinese-speaking community. *
Before I start, let me briefly introduce myself. I am Wang Ye. I am currently working as an assistant professor in the Department of Information and Computing Science of the University of Macau. My current research focuses on DeFi and related fields. We regard DeFi as an emerging financial market, and research issues from the perspective of economics and finance, including analyzing user behavior and market structure. In addition, I will also pay attention to the potential security issues that exist during user use, and how to reduce some dangers and security issues that Web3 and DeFi-related applications may bring about by improving user experience. The content I share today is mainly related to the first research direction, that is, we will study some user behavior problems under the new model in such an emerging decentralized financial market, and how we can optimize such a market structure.
Such a financial market based on the blockchain system will have some endogenous problems. We do not know some common solutions in the market and their impact on the entire market. Next, we will introduce how to model the current problems in the blockchain market from the perspective of economics or finance after understanding the existing problems, and how to use the model for theoretical analysis. In the last part, we compare and analyze the theoretical research results with the experimental data observed in the blockchain market, and then prove the application of our theoretical derivation in the actual market.
Everyone knows that there are two different types of participants in the blockchain: one is ordinary users, what they do is to send their transactions to the entire blockchain network, and then expect their transactions to be published on the network. is run in the system. The other kind is generally called a miner, or it may be called a verifier in the new system. They will collect the transactions sent by these users in the network and form a block. When such a block is broadcast and verified by most of the system participants, we consider that all transactions in this block have been confirmed, or completely verified successfully. In this, we will find that there are several core problems that are very different from the traditional financial market. The first problem is that transactions are transparent until they are determined to run and execute. In the past two years or so, everyone has widely proposed the concept of Frontrunning. In fact, this matter does not only exist in the context of decentralized finance, but has always existed in traditional finance. It just means that traditional finance can be used Some policies or rules and regulations completely eliminate risks, but in the blockchain system, we have to pay attention to this issue.
When a transaction is broadcast to the public network and before it is executed, it is already observable by everyone, which involves a very serious risk exposure problem. Secondly, the second very critical issue is about the ordering of transactions. At present, the most common way for miners to package and sort all transactions is to package them in order according to the level of handling fees. Then this will bring about a very serious problem. At present, people are paying more and more attention to related issues that cannot be ignored in the decentralized financial market, that is, there will be a large number of Running Attacks, or we may collectively refer to them in many cases. For MEV, Running Attack may be just a part of MEV.
Let's briefly describe this process again. When we find a transaction, it has not been executed. Any of our attackers can use known information to create a new transaction, and provide a higher Gas fee to make the newly submitted transaction executed before the leaked transaction. This is due to the endogenous problems in the blockchain system, which at present have always existed at least in the public blockchain system and are difficult to prohibit. Next, let's review some of the most common Frontrunning attack modes.
The first attack mode, I believe that many friends may be familiar with it, so let’s give a more clear introduction here. This mode is called Sandwich Attack. Its core point is that there is a constant product market maker pricing through AMM itself. mechanism, before a transaction is completed, through another transaction in advance to change the transaction fee rate in the market, then after the victim trader further pushes the transaction fee to a more extreme result, then through the reverse transaction to obtain The received funds are exchanged at a more favorable price, and the benefits are obtained through the exchange rate difference contained in the transaction. In such an attack mode, we can see that when there is a victim transaction in the market, this transaction is usually a transaction in AMM, and the attacker will use a higher value before the victim transaction Gas fees for a front-running transaction. After this transaction is over, they will use another transaction to perform a reverse operation, and gain benefits through the exchange rate difference between the previous and subsequent transactions. This is what we call the first type of Frontrunning.
The second type is the more common Suppression Attack. In the financial market, time is a very important factor. Many transactions execute one block later and one block earlier will cause huge market fluctuations, especially when we consider that some transactions may involve liquidation prices. The main target of this class of attacks is such critical transactions. For example, we hope that the transaction can be executed in the next block. If a malicious attacker observes this transaction and then kicks the transaction request out of a specific block with a transaction that proposes a higher gas fee, then he is attacked The transaction may wait until the next or next few blocks before being executed. Due to the time difference, we may not be able to complete the market operations of critical transactions in time, resulting in relatively serious market turmoil.
The third attack is called Displayment Attack, which is a one-time arbitrage attack. You can imagine that when we are doing some cyclical transactions, the market prices may actually be different. However, the potential speculative opportunity brought by the exchange rate difference is one-time. If I can smooth out the exchange rate difference in the market through repeated transactions, then subsequent attackers will have no way to speculate to make a profit. Then this is aimed at this kind of type of one-time arbitrage opportunity. We assume that Tv is a transaction that obtains profits through market transactions. After a malicious attacker observes Tv, he can perform exactly the same market transaction behavior, but the only difference is that he will use an arbitrage transaction of his own Submit with higher gas fee. Then it will be run in advance in the real blockchain system. Since he runs the one-time arbitrage opportunity first, the transaction of TV itself will no longer gain benefits.
These three are the MEV attacks that we are currently focusing on. Due to the setting of the system mechanism, the blockchain network has some endogenous problems. When we say that Frontrunning is very common, the next natural question is whether this matter is really a serious matter, and how much value loss will MEV cause?
We have a statistic that in less than a year, the financial losses caused by MEV attacks in the market have exceeded 80,000 Ethereum, which means that it has caused quite a lot of economic losses, which is why everyone will To pay attention to this issue, many people also consider how to eliminate MEV attacks. In addition to paying attention to economic losses, we actually also think about the further impact of the whole incident on the blockchain network, because it not only caused economic losses, but also wasted a certain amount of block space.
When this problem exists, everyone must be constantly thinking about how to solve it. The current solution is to broadcast through Private Pool, which used to be called Relay Service. Transactions don't just propagate through a distributed network that users expose, they provide a private communication channel that enables a direct connection between users and miners. Through such a communication channel, you can imagine that the advantage is that we will no longer have information leakage. Since we believe that Frontrunning is also a part of MEV, this kind of Private Pool is introduced into the network in the hope of minimizing the appearance of Frontrunning.
At present, Frontrunning Attack is caused by information leakage in the blockchain system. We also know that some people have proposed some new mechanisms to avoid this situation. So whether the new mechanism can play a role, and what kind of impact it will have on the blockchain system, naturally become the questions we want to study.
When we introduce Private Channel into the blockchain, what impact will it have on the entire ecosystem? First of all, will it be widely accepted by users and block validators? Because they are the core participants in our entire system. Then the second question is whether it has achieved our desired goal after being accepted, which is to reduce transaction fees and avoid Frontrunning. The third point is after the new mechanism is introduced, what kind of impact will it have on all users in the entire system? These are the three research questions we raised after discovering possible solutions.
We build models to study and explain the possible impact of different choices made by different participants on the market, and finally make predictions. Then we compare and analyze the user behavior of the market itself and our theoretical analysis results. Then we will show here how to divide the problem into three stages. We involved three different assumptions in our three-stage model. The first is that we think that the participants are rational, which is a common assumption we do in many economic and financial research. Secondly, we will think that some transactions will face the risk of being attacked, and there will be some transactions that will never be attacked in the system. At the same time, we will build a model based on the arbitrageurs or attackers that exist in this market.
Throughout the system, we believe that all transactions have two different transaction channels, one is our common public distributed network Public Pool, and the other is the private network Private Pool. Finally we assume that each block has enough space to accommodate transactions. Next, in different steps of this model, each user and each verifier must choose one of the networks for transactions. First of all, the first choice is the verifier, the second is the user, and the last is the attacker. This is actually in line with our normal operating mode in the block system. After these three different participants make their choices, we then perform a reverse calculation of what state the entire market will eventually enter.
First of all, miners have two different options. The first option is not to join the Flashbots system, and the second option is to join it. Obviously, these two options always exist for them. If they stay in the public channel, they can only see the transactions that exist in the Public Mempool. But if they join the Private Pool, they can see not only the transactions of Mempool, but also the transactions in the Private Pool. In the first stage of the model, everyone will make a selection, and then we use alpha to indicate the proportion of the selection using the flashbox.
The second part is about the user's choice in the whole transaction. Will they choose to propose their own transactions in the Mempool, or will they choose to propose in the Private Pool? If they propose transactions in the Mempool, then they will face the risk of being attacked. They can also choose Private Pool, but there are certain risks. The main source of this risk is that these transactions that join the Private Pool may not 100% win the right to record the next block, but we can continue to propose transactions later.
The third stage is that the attacker will observe the attackable transactions and carry out the attack transactions. For example, an attacker observes transaction P and decides to attack this public transaction. When an attacker submits his own transaction, he also faces two choices, either in the Public Pool or in the Flashbox. If an attacker submits a transaction in the Public Pool, the attacker may bid for higher bids in multiple rounds, and the Gas of their transaction will gradually increase. This is a common attack mode in many cases. If it is in the Private Pool, the attacker does not know whether there are other attackers competing with them at the same time. If in the Public Pool, if someone else competes with the attack, the attackers can actually know each other. But in the Private Pool, firstly, the attacker doesn’t know if there is any competition, and secondly, I don’t know how much gas fee the competitor has paid, so the attackers become a new competitive relationship, which will Causing them to make trade-offs. The Gas fee they are willing to pay will actually be very different. If the attacker's transaction is finally accepted, they will eventually have a Profit C, which is also the economic loss caused.
Then it's time for a trade-off. The first is about users and attackers, the main trade-off they encounter is actually operational risk.
Users need to weigh whether my transaction information will be leaked or whether I am safe, and the attacker will not give his transaction information to another attacker. They also face the same operational risk, that is, the private pool validators do not have 100% right to record the next block, so there is a high probability that this transaction will not be included in the next block, even if It is useless to pay enough gas fees.
Users who have not joined Flashbots, they only need to sort these transactions according to the gas fee from high to low, but if they join Flashbots, they must first rank the transactions proposed by the Private Pool in the block, and then verify The rest of the deal. For example, transaction K is smaller than the Gas fee of its previous and subsequent transactions, but transaction K is still placed in the front for verification.
After the catalog of hypothetical models is established, we will gradually analyze what choices you will make from three perspectives. We first conduct behavioral analysis from the perspective of the attacker. Attackers will naturally face higher and higher gas fees after going through continuous competition. This is a core conclusion we will find that the Gas price they need to submit in the Private Pool is much higher than the Gas price they need to submit in the Public Pool price. But many of them will still choose Private Pool. There are two core reasons. The first reason is that the arbitrage transactions they submit in Private Pool will not be seen by other attackers, and they do not need to conduct Bidding, this is a benefit. The second advantage lies in the sorting order of the blocks. If it is submitted through the Private Pool, its priority is naturally higher than those proposed by the Public Pool. In this case, attackers will naturally choose Private Pool. At the same time, in order to avoid the impact of operational risks, they will also choose to trade in some Public Pools at the same time.
The next step is the trade-off for users. They will mainly consider two factors, one is the adoption rate, and the other is the probability of potential attacks. If a is relatively large, then you can actually imagine that the operational risk they face is relatively small, and they will naturally be more inclined to use Private Pool. If the alpha is very small, it may not be useful for them to submit in the past, so the Public Pool will become their choice.
Also for part c, it is actually a very important factor. We found that if C is large enough, they actually have no other choice but to propose a transaction in the Private Pool. If this happens, we can find out. In fact, the arbitrage opportunities for attackers are completely eliminated. If everyone does not use the Public Pool, then this matter will no longer exist at all. But we also have to consider one point. In fact, in actual operation, not every transaction that causes MEV has such a high arbitrage space.
What we can see right now is say a lot of deals that can be sandwiched and maybe they only have a few dollars in return. After the attacker completes the attack, sometimes he even has to distribute most of the profits to the miners, and the remaining incentive may be less than $1. In fact, there are many cases where C is very small. In this case, they will not choose Private Channel, because Private Channel is not an optimal choice for them. The core reason is that for many users, they don't care whether their transactions are attacked or not, they are willing to bear the risk of being attacked, and they feel that running risks is a worse thing for them. In this case, we know that if the adoption rate is not 100%, then many transactions must be attacked.
Next to answer the second question, has the priority fee been reduced? Our final conclusion is that even after we introduce Private Pool, the priority fee will not be reduced. There are two main factors here. The first part, in fact, as you can imagine, verifiers will choose to use Private Pool only when they get higher fees, which naturally raises the benchmark fee for entering the block. Another factor is that some people may be vulnerable to attacks, so they are unwilling to choose the Public Pool. At this time, they prefer to use the Private Pool for transactions. These transactions that would not appear in the Private Pool will further increase priority fee. The final core conclusion is that it has led to an increase in priority fees.
The last core question is whether the overall value of the blocks we are concerned about has increased? We can think about this core factor because the Private Channel cannot actually achieve a 100% adoption rate, so there will still be a lot of Frontrunning, which will occupy our own block space. Then after the introduction, since these Running Attacks that generate MEV do not actually bring new network benefits to the system, they obtain a part of the rewards of the attacked users as their own speculative returns, and they will not bring some to the system. New value, so from this point of view, even after we have a Private Pool, we still cannot achieve the optimal and effective allocation state of the network. At the same time, due to the existence of MEV, in the whole system, the higher the overall welfare of the network is, the most beneficial choice for verifiers is not. In this case, the choice of miners will also lead to the fact that the network welfare of our final system cannot reach an optimal solution.
Next, we will go further to discuss whether there are some potential methods to help us solve such problems. The core argument is that the speculative return of the attacker and the optimal resource allocation of the network are actually incompatible. Attackers need the generation of MEV to help them increase their rate of return. In fact, one possible method is to change the uneven distribution of network value, that is to say, to provide an incentive for attackers to engage in a more reasonable and effective network participation method.
Finally, I would like to briefly share with you some data we obtained after theoretical analysis. First of all, we actually look at the acceptance rate of Flashbots. What we mainly do is to see whether the transaction block is intuitively reflected by this part of the data. Then we find that the transaction is still in such a state at present, neither all No one has seen it, nor does it mean that everyone can see it. This is our first conclusion. The second conclusion we got is that the probability of users choosing Private Pool actually has a very obvious positive correlation with whether they are vulnerable to attacks.
In the third part, we got a time-related conclusion. We found that compared with the attackers in the Mempool, the attackers in the Private Pool do not need to bid round after round. The attackers who obtain MEV, they have to submit to Miner fees are much higher. In Public Pool, the average payout ratio is around 0.3, but in Flashbox, it has risen to close to 0.8. We found that the probability of choosing a Private Pool is actually positively correlated with their risk of being attacked. This picture is such a probability distribution that you may see, and then we found that when the probability of being attacked increases by 1%, then their preference for choosing Private Pool will increase by 0.6%.
Our first and most core conclusion is that its Private Pool can neither completely eliminate the risk of being attacked, nor can it reduce market costs. Secondly, we found that the introduction of Private Pool will increase the welfare of validators and reduce the welfare of attackers. The overall welfare of the network will become higher due to more effective block space allocation, but it cannot reach the optimal state.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Wang Ye, University of Macau: Allocation Inefficiency, MEV, and Private Transactions in Public Blockchains
Speech: Wang Ye, Assistant Professor, Department of Information and Computing Science, University of Macau
Compilation: aididiaojp.eth, Foresight News
*This article is a compilation of texts shared by Wang Ye, Assistant Professor of the Department of Information and Computing Science at the University of Macau in the Young Scholars Program. The Young Scholars Program is co-sponsored by DRK Lab, imToken and Crytape. Well-known young scholars in the encryption field will be invited to share some of the latest research results with the Chinese-speaking community. *
Before I start, let me briefly introduce myself. I am Wang Ye. I am currently working as an assistant professor in the Department of Information and Computing Science of the University of Macau. My current research focuses on DeFi and related fields. We regard DeFi as an emerging financial market, and research issues from the perspective of economics and finance, including analyzing user behavior and market structure. In addition, I will also pay attention to the potential security issues that exist during user use, and how to reduce some dangers and security issues that Web3 and DeFi-related applications may bring about by improving user experience. The content I share today is mainly related to the first research direction, that is, we will study some user behavior problems under the new model in such an emerging decentralized financial market, and how we can optimize such a market structure.
Such a financial market based on the blockchain system will have some endogenous problems. We do not know some common solutions in the market and their impact on the entire market. Next, we will introduce how to model the current problems in the blockchain market from the perspective of economics or finance after understanding the existing problems, and how to use the model for theoretical analysis. In the last part, we compare and analyze the theoretical research results with the experimental data observed in the blockchain market, and then prove the application of our theoretical derivation in the actual market.
Everyone knows that there are two different types of participants in the blockchain: one is ordinary users, what they do is to send their transactions to the entire blockchain network, and then expect their transactions to be published on the network. is run in the system. The other kind is generally called a miner, or it may be called a verifier in the new system. They will collect the transactions sent by these users in the network and form a block. When such a block is broadcast and verified by most of the system participants, we consider that all transactions in this block have been confirmed, or completely verified successfully. In this, we will find that there are several core problems that are very different from the traditional financial market. The first problem is that transactions are transparent until they are determined to run and execute. In the past two years or so, everyone has widely proposed the concept of Frontrunning. In fact, this matter does not only exist in the context of decentralized finance, but has always existed in traditional finance. It just means that traditional finance can be used Some policies or rules and regulations completely eliminate risks, but in the blockchain system, we have to pay attention to this issue.
When a transaction is broadcast to the public network and before it is executed, it is already observable by everyone, which involves a very serious risk exposure problem. Secondly, the second very critical issue is about the ordering of transactions. At present, the most common way for miners to package and sort all transactions is to package them in order according to the level of handling fees. Then this will bring about a very serious problem. At present, people are paying more and more attention to related issues that cannot be ignored in the decentralized financial market, that is, there will be a large number of Running Attacks, or we may collectively refer to them in many cases. For MEV, Running Attack may be just a part of MEV.
Let's briefly describe this process again. When we find a transaction, it has not been executed. Any of our attackers can use known information to create a new transaction, and provide a higher Gas fee to make the newly submitted transaction executed before the leaked transaction. This is due to the endogenous problems in the blockchain system, which at present have always existed at least in the public blockchain system and are difficult to prohibit. Next, let's review some of the most common Frontrunning attack modes.
The first attack mode, I believe that many friends may be familiar with it, so let’s give a more clear introduction here. This mode is called Sandwich Attack. Its core point is that there is a constant product market maker pricing through AMM itself. mechanism, before a transaction is completed, through another transaction in advance to change the transaction fee rate in the market, then after the victim trader further pushes the transaction fee to a more extreme result, then through the reverse transaction to obtain The received funds are exchanged at a more favorable price, and the benefits are obtained through the exchange rate difference contained in the transaction. In such an attack mode, we can see that when there is a victim transaction in the market, this transaction is usually a transaction in AMM, and the attacker will use a higher value before the victim transaction Gas fees for a front-running transaction. After this transaction is over, they will use another transaction to perform a reverse operation, and gain benefits through the exchange rate difference between the previous and subsequent transactions. This is what we call the first type of Frontrunning.
The second type is the more common Suppression Attack. In the financial market, time is a very important factor. Many transactions execute one block later and one block earlier will cause huge market fluctuations, especially when we consider that some transactions may involve liquidation prices. The main target of this class of attacks is such critical transactions. For example, we hope that the transaction can be executed in the next block. If a malicious attacker observes this transaction and then kicks the transaction request out of a specific block with a transaction that proposes a higher gas fee, then he is attacked The transaction may wait until the next or next few blocks before being executed. Due to the time difference, we may not be able to complete the market operations of critical transactions in time, resulting in relatively serious market turmoil.
The third attack is called Displayment Attack, which is a one-time arbitrage attack. You can imagine that when we are doing some cyclical transactions, the market prices may actually be different. However, the potential speculative opportunity brought by the exchange rate difference is one-time. If I can smooth out the exchange rate difference in the market through repeated transactions, then subsequent attackers will have no way to speculate to make a profit. Then this is aimed at this kind of type of one-time arbitrage opportunity. We assume that Tv is a transaction that obtains profits through market transactions. After a malicious attacker observes Tv, he can perform exactly the same market transaction behavior, but the only difference is that he will use an arbitrage transaction of his own Submit with higher gas fee. Then it will be run in advance in the real blockchain system. Since he runs the one-time arbitrage opportunity first, the transaction of TV itself will no longer gain benefits.
These three are the MEV attacks that we are currently focusing on. Due to the setting of the system mechanism, the blockchain network has some endogenous problems. When we say that Frontrunning is very common, the next natural question is whether this matter is really a serious matter, and how much value loss will MEV cause?
We have a statistic that in less than a year, the financial losses caused by MEV attacks in the market have exceeded 80,000 Ethereum, which means that it has caused quite a lot of economic losses, which is why everyone will To pay attention to this issue, many people also consider how to eliminate MEV attacks. In addition to paying attention to economic losses, we actually also think about the further impact of the whole incident on the blockchain network, because it not only caused economic losses, but also wasted a certain amount of block space.
When this problem exists, everyone must be constantly thinking about how to solve it. The current solution is to broadcast through Private Pool, which used to be called Relay Service. Transactions don't just propagate through a distributed network that users expose, they provide a private communication channel that enables a direct connection between users and miners. Through such a communication channel, you can imagine that the advantage is that we will no longer have information leakage. Since we believe that Frontrunning is also a part of MEV, this kind of Private Pool is introduced into the network in the hope of minimizing the appearance of Frontrunning.
At present, Frontrunning Attack is caused by information leakage in the blockchain system. We also know that some people have proposed some new mechanisms to avoid this situation. So whether the new mechanism can play a role, and what kind of impact it will have on the blockchain system, naturally become the questions we want to study.
When we introduce Private Channel into the blockchain, what impact will it have on the entire ecosystem? First of all, will it be widely accepted by users and block validators? Because they are the core participants in our entire system. Then the second question is whether it has achieved our desired goal after being accepted, which is to reduce transaction fees and avoid Frontrunning. The third point is after the new mechanism is introduced, what kind of impact will it have on all users in the entire system? These are the three research questions we raised after discovering possible solutions.
We build models to study and explain the possible impact of different choices made by different participants on the market, and finally make predictions. Then we compare and analyze the user behavior of the market itself and our theoretical analysis results. Then we will show here how to divide the problem into three stages. We involved three different assumptions in our three-stage model. The first is that we think that the participants are rational, which is a common assumption we do in many economic and financial research. Secondly, we will think that some transactions will face the risk of being attacked, and there will be some transactions that will never be attacked in the system. At the same time, we will build a model based on the arbitrageurs or attackers that exist in this market.
Throughout the system, we believe that all transactions have two different transaction channels, one is our common public distributed network Public Pool, and the other is the private network Private Pool. Finally we assume that each block has enough space to accommodate transactions. Next, in different steps of this model, each user and each verifier must choose one of the networks for transactions. First of all, the first choice is the verifier, the second is the user, and the last is the attacker. This is actually in line with our normal operating mode in the block system. After these three different participants make their choices, we then perform a reverse calculation of what state the entire market will eventually enter.
First of all, miners have two different options. The first option is not to join the Flashbots system, and the second option is to join it. Obviously, these two options always exist for them. If they stay in the public channel, they can only see the transactions that exist in the Public Mempool. But if they join the Private Pool, they can see not only the transactions of Mempool, but also the transactions in the Private Pool. In the first stage of the model, everyone will make a selection, and then we use alpha to indicate the proportion of the selection using the flashbox.
The second part is about the user's choice in the whole transaction. Will they choose to propose their own transactions in the Mempool, or will they choose to propose in the Private Pool? If they propose transactions in the Mempool, then they will face the risk of being attacked. They can also choose Private Pool, but there are certain risks. The main source of this risk is that these transactions that join the Private Pool may not 100% win the right to record the next block, but we can continue to propose transactions later.
The third stage is that the attacker will observe the attackable transactions and carry out the attack transactions. For example, an attacker observes transaction P and decides to attack this public transaction. When an attacker submits his own transaction, he also faces two choices, either in the Public Pool or in the Flashbox. If an attacker submits a transaction in the Public Pool, the attacker may bid for higher bids in multiple rounds, and the Gas of their transaction will gradually increase. This is a common attack mode in many cases. If it is in the Private Pool, the attacker does not know whether there are other attackers competing with them at the same time. If in the Public Pool, if someone else competes with the attack, the attackers can actually know each other. But in the Private Pool, firstly, the attacker doesn’t know if there is any competition, and secondly, I don’t know how much gas fee the competitor has paid, so the attackers become a new competitive relationship, which will Causing them to make trade-offs. The Gas fee they are willing to pay will actually be very different. If the attacker's transaction is finally accepted, they will eventually have a Profit C, which is also the economic loss caused.
Then it's time for a trade-off. The first is about users and attackers, the main trade-off they encounter is actually operational risk.
Users need to weigh whether my transaction information will be leaked or whether I am safe, and the attacker will not give his transaction information to another attacker. They also face the same operational risk, that is, the private pool validators do not have 100% right to record the next block, so there is a high probability that this transaction will not be included in the next block, even if It is useless to pay enough gas fees.
Users who have not joined Flashbots, they only need to sort these transactions according to the gas fee from high to low, but if they join Flashbots, they must first rank the transactions proposed by the Private Pool in the block, and then verify The rest of the deal. For example, transaction K is smaller than the Gas fee of its previous and subsequent transactions, but transaction K is still placed in the front for verification.
After the catalog of hypothetical models is established, we will gradually analyze what choices you will make from three perspectives. We first conduct behavioral analysis from the perspective of the attacker. Attackers will naturally face higher and higher gas fees after going through continuous competition. This is a core conclusion we will find that the Gas price they need to submit in the Private Pool is much higher than the Gas price they need to submit in the Public Pool price. But many of them will still choose Private Pool. There are two core reasons. The first reason is that the arbitrage transactions they submit in Private Pool will not be seen by other attackers, and they do not need to conduct Bidding, this is a benefit. The second advantage lies in the sorting order of the blocks. If it is submitted through the Private Pool, its priority is naturally higher than those proposed by the Public Pool. In this case, attackers will naturally choose Private Pool. At the same time, in order to avoid the impact of operational risks, they will also choose to trade in some Public Pools at the same time.
The next step is the trade-off for users. They will mainly consider two factors, one is the adoption rate, and the other is the probability of potential attacks. If a is relatively large, then you can actually imagine that the operational risk they face is relatively small, and they will naturally be more inclined to use Private Pool. If the alpha is very small, it may not be useful for them to submit in the past, so the Public Pool will become their choice.
Also for part c, it is actually a very important factor. We found that if C is large enough, they actually have no other choice but to propose a transaction in the Private Pool. If this happens, we can find out. In fact, the arbitrage opportunities for attackers are completely eliminated. If everyone does not use the Public Pool, then this matter will no longer exist at all. But we also have to consider one point. In fact, in actual operation, not every transaction that causes MEV has such a high arbitrage space.
What we can see right now is say a lot of deals that can be sandwiched and maybe they only have a few dollars in return. After the attacker completes the attack, sometimes he even has to distribute most of the profits to the miners, and the remaining incentive may be less than $1. In fact, there are many cases where C is very small. In this case, they will not choose Private Channel, because Private Channel is not an optimal choice for them. The core reason is that for many users, they don't care whether their transactions are attacked or not, they are willing to bear the risk of being attacked, and they feel that running risks is a worse thing for them. In this case, we know that if the adoption rate is not 100%, then many transactions must be attacked.
Next to answer the second question, has the priority fee been reduced? Our final conclusion is that even after we introduce Private Pool, the priority fee will not be reduced. There are two main factors here. The first part, in fact, as you can imagine, verifiers will choose to use Private Pool only when they get higher fees, which naturally raises the benchmark fee for entering the block. Another factor is that some people may be vulnerable to attacks, so they are unwilling to choose the Public Pool. At this time, they prefer to use the Private Pool for transactions. These transactions that would not appear in the Private Pool will further increase priority fee. The final core conclusion is that it has led to an increase in priority fees.
The last core question is whether the overall value of the blocks we are concerned about has increased? We can think about this core factor because the Private Channel cannot actually achieve a 100% adoption rate, so there will still be a lot of Frontrunning, which will occupy our own block space. Then after the introduction, since these Running Attacks that generate MEV do not actually bring new network benefits to the system, they obtain a part of the rewards of the attacked users as their own speculative returns, and they will not bring some to the system. New value, so from this point of view, even after we have a Private Pool, we still cannot achieve the optimal and effective allocation state of the network. At the same time, due to the existence of MEV, in the whole system, the higher the overall welfare of the network is, the most beneficial choice for verifiers is not. In this case, the choice of miners will also lead to the fact that the network welfare of our final system cannot reach an optimal solution.
Next, we will go further to discuss whether there are some potential methods to help us solve such problems. The core argument is that the speculative return of the attacker and the optimal resource allocation of the network are actually incompatible. Attackers need the generation of MEV to help them increase their rate of return. In fact, one possible method is to change the uneven distribution of network value, that is to say, to provide an incentive for attackers to engage in a more reasonable and effective network participation method.
Finally, I would like to briefly share with you some data we obtained after theoretical analysis. First of all, we actually look at the acceptance rate of Flashbots. What we mainly do is to see whether the transaction block is intuitively reflected by this part of the data. Then we find that the transaction is still in such a state at present, neither all No one has seen it, nor does it mean that everyone can see it. This is our first conclusion. The second conclusion we got is that the probability of users choosing Private Pool actually has a very obvious positive correlation with whether they are vulnerable to attacks.
In the third part, we got a time-related conclusion. We found that compared with the attackers in the Mempool, the attackers in the Private Pool do not need to bid round after round. The attackers who obtain MEV, they have to submit to Miner fees are much higher. In Public Pool, the average payout ratio is around 0.3, but in Flashbox, it has risen to close to 0.8. We found that the probability of choosing a Private Pool is actually positively correlated with their risk of being attacked. This picture is such a probability distribution that you may see, and then we found that when the probability of being attacked increases by 1%, then their preference for choosing Private Pool will increase by 0.6%.
Our first and most core conclusion is that its Private Pool can neither completely eliminate the risk of being attacked, nor can it reduce market costs. Secondly, we found that the introduction of Private Pool will increase the welfare of validators and reduce the welfare of attackers. The overall welfare of the network will become higher due to more effective block space allocation, but it cannot reach the optimal state.