I have a proposal on why (Miner extracted value) MEV exists and how to fix it. MEV causes two problems. One is increased cost for the users, but the second and most important is compromising chain progression and security. If there are large incentives (MEV opportunities) these will compete with block reward incentives and will potentially make miners want to compete over getting the MEV opportunities rather than co-operatively extending the longest chain per the consensus rules.
The reason that MEV exists is because all current cryptos have two mechanisms for ordering. One mechanism for ordering blocks and a second mechanism for ordering transaction inside blocks.
The distinction between intrablock ordering and block ordering is arbitrary and is un-needed. There should only be one market for ordering transactions in the chain which functions both for intrablock ordering as well as interblock ordering. Presently, having two markets for fundamentally the same service, ordering within a chain, puts the markets in competition with one another. This can lead to lower security and slower finalization because MEV opportunities, which are a fee market, can compete with the progression of the longest chain, a hash market.
Therefore, if you want to have an ordering market that is based on hash you must use it for both transaction ordering as well as block ordering. This will eliminate the competition between intrablock ordering (tx ordering) and block ordering thus removing conflicts between transactions and blocks.
I propose that a base fee should be paid for processing, but the ordering should be determined by worked transaction hashes. This would be done by creating a mechanism wherein transactions could be merge mined with blocks. The work that is performed on a transaction would then effectively represent a mined share which would determine the ordering of the transaction within a given block. The transactions with the most work would be included first and the least work would be included last.
This would mean that to MEV a transaction, say sandwich or front-run, a MEV bot would have to mine a transaction with appropriate order around the targeted transaction. This may seem trivial for transactions which do not have significant amounts of work, however, sandwiching a tx would not only require finding a mined tx which is in front of and behind the target transaction, but would create a competition to mine transactions which are exactly 1-bit greater and 1-bit lower difficulty which is significantly more difficult. Moreover, any MEV bot would have to execute these attacks in real-time.
In addition to ordering the transactions by hash, the protocol would also count the included transaction hash difficulty into the sum of the blocks total difficulty. In doing so the chain would weight the blocks with more work in the transactions with higher weight making that block more likely to be the canonical head. This competition would cause alignment of the transaction ordering market with the progression and choice of the longest chain. The algorithm for counting tx work towards block difficulty necessarily needs some consideration. If the transactions can be mined independently of a block and then arbitrarily included a miner could store up a large number of mined txs and bring them out at any point in the future to effectively win a block. To prevent this, the block hash with which the tx is being merged mined could be used as a reference and the contribution of the tx weight to the block weight could be discounted based on the age of the referenced merged mined block and the block within which the tx as actually included. This would encourage miners to include transactions as quickly as feasible possible in their blocks. One version of weighting that could be feasible would be to have the threshold work weight which must be met by hash on the block itself. Then in addition to this there could be worked transaction weight that could be a prorated addition to the intrinsic block difficulty based on the percentage of the gas limit used in the block. This would mean that the tx weight could count for as much as 50% of the blocks total computed difficulty.
There is however a downside to counting tx work towards block weight. Specifically, this could incentivize miners to withhold transactions with a large amount of work to give themselves an advantage in mining a block. This could cause a negative effect on a network because referencing txs in a block which have not yet propagated throughout the network will add significant time to verification of blocks by the network because nodes validating the block will first need to fetch the tx data. This incentive is offset somewhat by two factors. First, if there is a significant delay to validation of a block due to inclusion of txs which have not yet propagated, the block is more likely to get uncled which will penalize the offending miner. Secondly, as a user that is broadcasting a tx that has worked a tx, they are incentivized to ensure that the tx quickly propagates across the network so it is more likely to get included with highest priority. However, if these two incentives are not sufficient there are two mechanism by which they can be further incentivized.
Firstly, a symmetric delay function (SDF) could be used to amplify the effect of the first two incentives. If worked txs also required the broadcaster to include a SDF, eg PBKDF2, a delay of say 1-2 seconds could be added to the verification time of a transaction. This would cause miners that withhold txs prior to mining a block to suffer a greater uncle penalty. The addition of a SDF would require nodes to have a high thread count processor as the number of threads on the processor coupled with the delay duration would dictate the verification limited TPS of the network. However, given that GPUs can easily be acquired that have >4,000 threads capable of parallelized verification of a PBKDF2 SDF, this would not impede network performance. The SDF would increase the incentive of miners to forward propagate txs once received as well as potentially delay inclusion of a transaction in their block mining until they believe the tx has propagated fully. This would then increase the aggregate throughput of the network as all data referenced in a block would be available to the entire network prior to the block being found allowing verification to only be constrained by computational time rather than limited by network bandwidth rates.
Alternatively, if each one of the worked txs or group of txs was rewarded a portion of the coinbase for the work that was contributed to the block, this would cause miners to want to propagate the work as soon as possible to ensure that it gets inclusion in the next block. The amount of the coinbase that is rewarded to the tx work would be prorated by the age of the block which has merged mined with the tx group relative to the block in which it was included. This accomplishes two things. First, it causes the miners to reference the freshest head available at the time to merge mine txs with as this will give them the greatest chance of maximizing the reward. Second, this would optionally allow a consensus rule that enforces aging of the tx groups after propagation and prior to inclusion because the network has a guarantee on when the tx group was likely worked given the countervailing incentive of tx work share maximization. This would mean that you would be able to guarantee some degree of staleness and therefore consistency in the newly propagated tx sets prior to referencing in blocks which would vastly improve overall network performance. Of the two possible solutions PBKDF2 vs coinbase rewards the latter is likely more favorable due to its simplicity as well as the alignment of incentives with chain efficiency and progression.
There is a subtle implication of merge mining a transaction which can only be included if the reference with which the tx was merge mined must be a canonical block. By mining on top of an already included block the work that goes into merge mining the txs is attesting to the validity and canonicalization of the block with which it is merged mined. This means that the work is actually contributing to the security of the chain through implicit verification and can be added into the chain weight. However, when adding in the tx work into the block weight, any given set of work must be limited to the intrinsic work threshold weight. Doing this will prevent the added tx work from being able to overwhelm the intrinsic work. This should happen just through mathematics because if any given share is greater than the block work that share itself would be the block itself. The only way that it isn’t the block is if the producer somehow withholds the block are references a block which is not canonicalized. This weight should be ignored. Additionally, we should consider the depreciation of the weight computation of tx set inclusion as they are included further away from the current tip. I would propose that the tx work weight falls off with a factor of two with each block after the tx set is eligible for inclusion. This will limit the total possible tx work weight to 2 relative to the intrinsic weight of the block.
The proposal of using tx work shares creates a mechanism for share based mining without having to use the centralizing pools. This is because the transaction weight will be rewarded proportionally to the work presented. This means there is no difference in reward from presenting an including tx share or mining the block itself.
Here I will elaborate on the specifics of the block weight calculation to provide some further clarity in the proposal as well as provide a basis for further exploring incentives.
Let a worked transaction Tx_i_n where n is the block reference with which the group was worked relative to the head block n, and i is the unique reference for each worked tx.
Let D_in be the intrinsic difficulty of mining a block.
Let D_tx be the weight which is contributed by the included transaction groups.
The value of D_tx = sum(min(Tx_1_n, D_in), min(Tx_2_n, D_in), …) + 1/2 * sum(min(Tx_1_n-1,D_in), min(Tx_2_n-1,D_in)…) + 1/4 * sum(min(Tx_1_n-2,D_in), min(Tx_2_n-2, D_in),…) …) .
The weight of a block D_block = D_tx + D_in.
Note that neccassarily D_tx <= 2 * D_in based on the sum of the series 1/2^n from n=2->inf
Lets explore what would happen here if there was a transaction that can be exploited by being front run by a MEV bot. All MEV exploits normally require a MEV bot to get at least 1 tx in-front of the tx they are trying to exploit. To front run a tx the MEV bots would have the option of mining a transaction which has greater difficulty than the tx which they are trying to front run or by attempting to mine an alternate chain tip. Lets assume that there are at least 2 competing MEV bots, Alice and Bob, which have roughly the same amount of hash power which in total are both less than 50% of the hash rate. If Alice finds a difficulty greater than the mined transaction difficulty D_Alice > D_tx, Bob will need to mine his transaction such that D_Bob > D_Alice. This back and forth competition will proceed until Alice, Bob, or some other miner finds a difficulty D > D_in which would lead to the mining of a new block.
Lets say that at this point in time Alice has managed to order her transaction in front of Bobs. That means that the block will have a block difficulty of at least D_block_n >= D_in + D_Alice + D_tx.
If Bob is unsatisfied with this result he can try and mine a new tip which is a fork with the block that was just mined. Bobs expected difficulty for the nth block will be D_block_n_bob >= D_Bob + D_Alice + D_tx.
For bob to be able to statistically outrun the chain and successfully mine a fork which become canonical then D_Bob > D_in.
This means that Bob would have to have a majority of the hash rate to have a chance at running a successful fork. Additionally, once Alice has priority ordering in the block it would behoove Alice to increase her hash rate temporarily to ward off any potential re-org attacks by Bob up until the point that the cost of defending the front run of the MEV tx approaches the benefit. In the case that Alice or Bob decides to fight over the MEV tx the net effect on the chain will be to temporarily increase the total hash rate on the chain. The increase in the hash rate would be proportional to the bounty offered by the MEV tx with the net hash rate which ultimately gets committed to the chain being greater than or equal to the base hash rate. The delta in the hash rate that would go to waste from competitive tip mining would necessarily have a 1-to-1 offset with the additional work that gets canonicalized on chain.
This is just a starting point in the proposal and likely will need to be discussed more and fleshed out with different scenarios. However, I think that this has a basis for aligning tx ordering with chain tip progression, thus preventing MEV from compromising chain security.