If jump start trading becomes a service

Original title: "the view | if jumping the gun trading becomes a service"
Original author: Ed Felten
Min Min,O sword

Recently, I have repeatedly mentioned and proposed a solution to the front-running trade problem in ethereum applications. As I wrote in my previous post (MEV auctions are bad), front-running deals are not only bad for users, but also disrupt the app market. Therefore, we should try our best to reduce its negative effects. In addition, trying to permanently control the front-running trade is likely to make things worse.

Vitalik Buterin responded to my article and made an argument that I don't think is true, which I will explain later. After a long discussion with Vitalik on Telegram, I finally understood his point of view. To make a long story short, I still don't think he's right.

For those of you who don't know, I'll give you a quick rundown. Because ethereum miners could decide which trades to package and the order in which they were executed, they were able to put their own trades at the top or sell the top positions to others. This is front-running. The point I debated with Vitalik was how a false start would affect miners' behavior, and thus ethereum's overall health.

Vitalik believes that there must be a certain miner who is better at front-running than other miners, so as to gain economic benefits, thus increasing the proportion of his calculation power and eliminating other miners who are not good at front-running. In this way, the trend of centralized computing power will be formed and the stability of the network will be destroyed.

When jump - start trading becomes a service

I'm sorry to announce that you now have access to our high-end customization service

I don't agree with that. Why is that? Let's say Fred is the best jump-start trader in the world. He knows how to package ethereum blocks, and his ability to profit from false starts is unsurpassed. And let's say that Alice is a miner who controls two percent of the computing power. Naturally, Fred will sell the jump trade to Alice as a service. If Alice buys Fred's services, Alice's revenue increases by V for every block she digs, and then she pays Fred no more than V. In this way, both sides will benefit, and Alice and Fred will certainly not refuse. There's nothing special about Alice. The problem is that Fred will sell this service to every miner.

It's important to note that this deal is good for Fred and Alice, regardless of whether Fred is a miner or not. If Fred had been a miner, he would have made a profit by packing blocks. However, if he were to package the block and sell it to Alice, he would make even more money, because Alice has a 2% chance of getting the block, which would give Fred extra money. Therefore, the decision whether to sell the block package to Alice will not affect Fred's decision whether to invest in the mine.

(Also, let's assume that Fred is involved in the mining, but has no cost advantage over other miners. Fred could offer a front-running trade for his mining business at a discount or even for free, but it would do him no good: an X dollar discount would mean that Fred would earn X dollars more for his mining business, but X dollars less for his front-running trade. Therefore, if Fred were to buy a front-running trading service for his mining business, as Alice did, he would be equally motivated.)

As a result, Fred will sell his jump-start service to any interested miner. Other miners will buy.

FRaaS, then, are the corollary: in an active market, freds rush to sell block packages to Alice. This will not drive concentration at all. FRaaS can lower the barriers to entry by letting Fred solve the problem of how Alice can use jump start trading to increase returns. This, in turn, helps to decentralise mining.

FRaaS and mineral pools

Eventually, the entire market will consist of a set of pools. Fred would run a pool and would be able to pay miners higher rates of return than any other pool, because Fred would always be able to dig blocks that produced higher returns than any other pool. In the FRaaS market, Fred's competitors do the same. Most miners will choose the honest pool that pays the highest returns.

Importantly, miners are free to choose which pool to work with, avoiding those pool operators who misbehave and moving on to other pools for each block dug. As a result, the pool operator's power to determine the order of transactions can only be used on one block at a time. Of course, Taifang has given the miners in the bundling blocks the power to decide which order to trade. So the "monopoly power to sort transactions within a single block" that needs to be earned in the open market is what we are, not something that violates the agreement.

How are systems designed for FRaaS

If there is to be a future FRaaS industry, how can we design more robust systems? I have two principles.

1. Maintain competition in the FRaaS industry

The first principle is that if there is going to be an industry like FRaaS in the future, we want it to have internal competition so that ranking rights are not monopolised by one party. In general, monopolists are more powerful than market leaders in competitive markets, and they often use their power to gain value, resulting in less efficient markets and loss of end users. Thus, we should not artificially give one party a monopoly on packaging blocks. Otherwise, it leads to artificial centralization, the erosion of community principles, and the abuse of power that is impossible in competitive markets. Even if monopoly is only temporary, it will only lead to unnecessary centralization of power.

2. Reduce false starts

The second principle is to remember that front-running trading is harmful and should be minimized. We should take anti-false start trading as one of the criteria of evaluation system and protocol.

In evaluating any new agreement, for example, we should ask ourselves the question: will it increase or decrease the front-running rights of miners or other participants?

In the future, I'll detail how this principle works in our Arbitrum protocol design, and why we think the Layer 2 solution of actively spreading transaction sort rights is superior to Eethum.

MEV (Miner can fetch value) auction

Those pondering these questions may ask: what is the point of having a MEV auction with the FRaaS pool? Should we create a centralized transaction sorting mechanism and auction off temporary control of this mechanism? My answer is: No. I'll explain that in the next article.

Text link:https://medium.com

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia