Visualization for builders reputation

Abstracts

This article addresses the centralization of block builders, which may reduce the user experience and censorship resistance of Ethereum. I argue that an important solution from a future where the supply chain building blocks becomes centralized, dominant & predatory is to make the reputation of the builders visible.

Background

Factors for centralization

Block builders collect order flow to build high-value blocks. If the collection is only from open, permissionless access, then centralization will not occur. Currently, however, they can be collected from private spaces as well, and this is a factor in centralization.

Order flow collection channels

Public Order Flow : Transactions that are publicly broadcast through mempool and are the easiest to study because anyone with the resources to run a few Ethereum nodes can have high visibility
Searcher order Flow : Transactions where the searcher sends bundles to n builders, and needs to select builders who can build highly competitive blocks without stealing their own MEV. Or, in some cases, resourceful searchers who do not want their MEV stolen may build a full block themselves.
Private Order Flow : This is the collection of order flow independently through RPC endpoints, and is basically a channel dedicated to a specific builder, so other competing builders do not have access to it.

Correlation between builder market share and searcher order flow

As the number of searchers increases, the number of bundle order combinations increases, potentially allowing builders to extract more value. According to data from Frontier Research 31, the top four of the 38 active builders have a combined 87% market share with more searcher submissions than the other builders, with 88.5% of searchers submitting to four or more builders.

Rational Searcher Selection

Since the combined market share of the top seven builders covers nearly 94% of the market, the most rational choice for searchers would be to submit to multiple builders.

However, increasing the number of submissions to too many builders makes it difficult to identify which builder has stolen the bundle and makes it easier for one builder to dismantle and sandwich the bundle. Also, if the share ratio is low just because they are trustworthy, they will not be able to build competitive blocks, which will negatively affect inclusion. So how does a searcher select the builders? It chooses a small number of trustworthy builders who can build highly competitive blocks. There is a trade-off between the cost of trusting these builders and inclusion.

Also note that searchers follow economic rationality, so it is likely that they will all make the same choice. For example, if builder A appears in the future with more than 50% market share, a rational choice would be to send to builder A and a few other builders.

Now, what if this is closer to 100%? The rational choice for most searchers would be to send only to the builder with a share rate close to 100%.

This rational choice of searchers and competitive environment of builders will cause centralization of block builders.

What is the problem with centralization of block builders?

Disincentives for new entrants and competition.

Source: Builder Dominance and Searcher Dependence

The figure of the percentage of blocks built by each builder normalized by searcher transmission rate shows that the differences in searcher transmission among builders are more pronounced. Searcher rationales and the competitive environment of the builder market tend to create further disparities even among the top builders, as certain block builders have the advantage of monopolizing the market, discouraging new entrants and competition.

censorship-as-a-service

As newcomers and competitors are weeded out, a dominant n = 1 builder may emerge and extract maximum value from users by exploitative means to maintain its dominance. One example of this is the formation of the censorship-as-a-service market to exclude users from trading from the block. The formation of an open market where users can bid to exclude transactions from the block. The user sends a bribe and a hash of someone else’s transaction that he does not want included in the block to the n = 1 builder. The block builder is only considered if the bribe is more than the gas (and MEV) he would have received from the transaction, allowing him to make a profit by censoring traction. Similarly, an n = 1 builder could also provide a protection service by sending a hash and a bribe to help users protect themselves from this censorship, which would only be considered if it is more than the highest censored bid for the transaction. With the formation of such a self-contained market, users would have to guess whether their own transactions could be censored, and would have to pay an additional fee to pay for censorship protection.

The Downside of Block Generation

If a dominant block builder is created, all block creation may stop if for some reason the n = 1 builder goes offline. It has been argued that it is not particularly important that there are many regular block builders, but that it is critically important that there are several people who regularly try to create blocks, even if some of them do not succeed.

So what to do?

Visualizing Block Builder Reputation

Visualizing the reputation of block builders will reduce the cost of credit for searchers and make it easier to send to multiple builders. This can put builders at risk for dishonest behavior.

For example, there are searchers who assign specific values such as calldata, priority fee, hash, etc. to each builder and AB test which builder also sandwiched it. Creating a receptacle to collect the results of such AB testing and visualize reputation would have the effect of helping searchers and POF decide which builders to send to.

There may also be a strong need to develop tools that can easily monitor and detect plagiarism, assuming searchers are unable to spot dishonest builders.

Who will this lead to value for?

This page 12 asks, “To whom does scoring a block lead to value?” It is argued that the scoring target will vary depending on the question "to whom does it lead to value?

is it value to the builder?

the value to the proposer?

For example, if one were to calculate 1, it would not be to the builder’s advantage to include in the calculation transactions that would increase the value of the block, as it would give the impression that the builder is lining their own pockets with a large portion of the MEV. 2. The value to the proposer must be taken into account in the calculation.

In this article, neither 1 nor 2, but the value to searchers and users, who are at a more upstream layer than builders, needs to be considered, and they are the focus of the calculation here, as risk management against dishonest behavior such as reverse engineering of bundles is important to them.

Concerns

the account of the user or searcher doing the evaluation may be revealed. Since searchers, in particular, tend to avoid account identification, it is necessary to use a mechanism such as stealth addresses to ensure the privacy of the evaluator.

the system to measure evaluators and their credibility should also be taken into consideration. For example, in the popular Japanese service “Tabelog”, people who visit many restaurants and write many reviews have a large influence on the score, while those who write reviews for only a few restaurants have a small influence. How to calculate such indicators needs to be discussed.

it is possible that the effect of the reputation system works in the opposite direction, encouraging order flow to be attracted to the top few builders more. The problem, however, is that n = 1 dominant builders will arise, and the ease of sending to multiple builders due to reputation visualization could prevent the worst case. The issue of new builders not getting order flow will be explored in depth in another article.

Conclusion

The right of builders to build competitive blocks needs to be decentralized, and this requires searchers to keep sending bundles to multiple builders. To do this, we will lower the cost of credit for searchers and make it easier for them to send bundles to multiple builders by providing builders with appropriate monitoring and reputation systems.

This is similar in many ways to the behavior we have seen when booking a meal or hotel in a new location, where we search for high ratings on Google and other search engines to reduce the likelihood of encountering low-quality service.

Nevertheless, there is much room for discussion about formulas, implementation, new options and trade-offs, and we would like to hear other ideas and opinions from the community. The purpose of this article is to advocate the concept, facilitate discussion, and hopefully talk about ways to solve the centralization of block builders.

List of Notes, Citations, and References

Block scoring for mev-boost relays - Relays - The Flashbots Collective 4

Block builder centralization 6

MEV-Boost: Merge ready Flashbots Architecture 2

Two-slot proposer/builder separation - #5 by pmcgoohan 4

Builder Dominance and Searcher Dependence 31

https://members.delphidigital.io/reports/the-year-ahead-for-infrastructure#intro 1