Original title: "Censorship... wat do?》

Original title: "

This article is from the WeChat public account Old Yuppie.

This article is from the WeChat public account Old Yuppie.

introduce

introduce

Censorship is incompatible with Ethereum values.

We've spent enough time over the past month or so thinking about how we got here. I will discuss the way forward - how do we solve this problem?

What should developers do?

Fighting censorship head-on should be the number one priority. Divestment will likely also need to be resolved as quickly as possible.

Issues like scaling can really take a back seat, though. Ethereum can survive slightly higher fees, but it cannot survive censorship. EIP-4844, Danksharding, and other upgrades are complex and can take a lot of time and attention away. If really needed, EIP-4488 can be implemented very quickly and very efficiently.

Prioritizing censorship resistance is the clearest way to demonstrate community values. Failure to do so would be a very bad signal that could damage credibility - why should validators, Flashbots, or any other relayers/builders prioritize resistance if core protocol development won't do it What about censorship?

MEV-Boost

Plus, it's a bear market and everyone is poor, or on the run. Fees are acceptable.

Let's start with a brief overview of the architecture.

Capturing MEVs requires sophisticated technology. If validators were given this task, they would become centralized - only mature validators able to extract MEV would earn competitive rewards. Proposer-Builder Separation (PBS) solves this problem - creating a new dedicated "builder" role to build optimal blocks. Builders then bid to proposers (validators) to accept their blocks. It's still easy to become a proposer, they earn competitive rewards = stay decentralized.

PBS will eventually be built into the protocol, but it's not ready yet. PBS is already here though - MEV-Boost is currently a stepping stone outside the protocol (despite the extra trust assumption). It is an additional sidecar software that validators can run to query outsourced block building. Validators still retain the option to use their own executing clients and build blocks locally.

Many MEV searchers run specific strategies and bid for builders to include in their bundles. Builders can aggregate these bundles + any other private order stream + public mempool transactions → build optimal full blocks. Some builders can also internalize search and take on this role themselves.

Overview of repeaters

Relayers are intermediaries that both proposers and builders trust. They receive builders' blocks and escrow them before sending them to proposers. For a particular relayer, the process could look like this:

Design goals

MEV-Boost addresses two major shortcomings of MEV-Geth:

1. Solo-staker participation

PoW miners will receive the bundles, and they will then create a full block putting these bundles on top. They were never sent full blocks. Flashbots never included OFAC-blacklisted transactions into their bundles, but that doesn't matter since miners can include them anywhere else in a block.

This scheme means trusting the mining pool operators - they can clearly see these bundles, so they can directly steal these opportunities for themselves if they want. This trust does not scale to a large set of Ethereum validators. This is why MEV-Boost provides complete blocks to proposers. Proposers sign and submit block headers before the block body is revealed to them. If they try to MEV steal after seeing the body of the block, they will need to propose another block. Their original signatures are presented → proposers are chopped for duplicate signatures.

This full-block approach enables decentralization of validators, but it adds significant censorship risk at the relayer/builder level. If validators accept blocks from censoring relayers, they become de facto censors.

• If the review builder is the most profitable builder, then the proposer is forced to choose between the following two. :

• Economic rationality - accept the highest value block, even if censored

Altruism - accept less valuable blocks without censorship

Ideally, altruistic assumptions should be removed entirely or minimized as much as possible.

2. Customer Diversity

Most miners were running the Go Ethereum (Geth) client, so Flashbots simply forked it, creating MEV-Geth. Running it is the only way to participate in the Flashbots Auction. PoS is an opportunity to increase customer diversity. MEV-Boost sidecars are interoperable with all consensus and execution clients.

• MEV-Boost is infrastructure neutral:

• Relayers - are free to operate under any constraints or policies (e.g. censorship/non-censorship, "fair" ordering/maximum profit, etc.). Relayers can accept blocks from builders as they wish.

• Builders - are free to run any strategy they like and deploy to any relayers they trust who are willing to accept their blocks.

MEV-Boost does not review OFAC transactions or sandwich transactions. It simply allows proposers to outsource the build, choosing from relayers that match them.

review

review

• Here is the framework for my discussion of the review:

• Weak review = delayed but eventually included. If 50% of validators do not include OFAC transactions, then on average, they will be included after 2 blocks (24 seconds). With 90% censorship, they will be included after 10 blocks (120 seconds), and so on.

Strict censorship = censored transactions are not included on-chain. In Gasper, this requires 51% of validators to not only censor OFAC transactions for their own blocks, but to actively ignore all new blocks that include them.

Validators appear to have no imminent threat of censorship. They appear to have taken the position that they have no obligation to review OFAC transactions. This could be resolved through user-activated soft forks or slashes if desired, but that's not my main focus here.

• The looming threat of censorship is at the relayer/builder level. This is mostly from Flashbots who run the largest repeaters and builders. However, other relayers also do censorship - they just have a lower market share, these include:

• Blocknative

• Eden Network

bloxRoute "supervised" relayer

• Non-censoring repeaters:

• bloxRoute "profit-maximizing" relayer

• Manifold Finance

"Ethics" relayer for bloxRoute

I will focus on how to mitigate threats at this level.

What should a validator do?

I wrote this thread a while ago, but recently I've been thinking about it again. I still have a similar feeling - I think it's best to run MEV-Boost, but only with non-censored repeaters.

To be honest, if I were a validator, I'd rather not run MEV-Boost at all. Flashbots are the most reliable live repeater/builder operators, so I'm uncomfortable using some of them. But actively promoting more censorship is harmful.

So running a personal client sounds nice and easy, but I think it's better to run MEV-Boost with those other non-censored relayers. Otherwise, low adoption would in turn bring negative externalities (pga, etc.). Furthermore, validators who run it will earn more than altruistic validators who don't - they will systematically increase market share long enough to crowd out altruistic validators.

Ignoring MEV won't make it go away, and we've seen that happen before.

Lower Flashbots relayer adoption could mean less scrutiny. At the time of writing - MEV-Boost adoption accounts for 42% of validators and Flashbots are building ~60% of MEV-Boost blocks = ~25% of Ethereum blocks are censored there. Adoption of MEV-Boost is also steadily increasing. Currently, there is very little scrutiny from other relayers (they just don't have meaningful market share).

Actually, I don't think "less censorship" makes a difference. If your censorship rate is 20% vs. 40% vs. 60%, then those OFAC addresses are censored and they have to wait. If the scrutiny rate rises, they will wait a little longer.

However, I do think it's very important from a signaling perspective. Ethereum should communicate to the world that this behavior is not in line with our values ​​and will not be tolerated.

What does the agreement do?

Unfortunately, the above "just don't use Flashbots relayers" solution relies on the altruism of the proposer. If Flashbots ever built the most valuable blocks (which they usually do), validators actively choose not to use them to make less money. Validators willing to accept censored blocks will again gain proportional market share, and meaningful altruism is simply not a sustainable long-term strategy. We need better protocol design.

Enshrined PBS and crList

When PBS is built into the protocol, repeaters disappear. Builders will interact directly with proposers through an in-protocol auction. Builders promise to pay unconditionally, eliminating the need for trust. Once a proposer signs a block header sent by a builder, they can get the associated bid (even if the builder subsequently discloses an invalid block body or withholds it entirely).

• crLists checks for this capability. The exact implementation is an open design space, but here's a simplified overview of a "hybrid PBS". Proposers specify a list of all eligible transactions they see in the mempool that builders will be forced to include (unless the block is full):

• The proposer publishes a crList and a digest of the crList, which includes all eligible transactions.

• Builders create a proposed block, then submit a bid containing a hash of the crList digest to prove they have seen it

• The proposer accepts the winning bidder's bid and block header (they haven't seen the block body yet)

• Builders publish their blocks and include a proof that they have included all transactions from crList, or that the block is full. Otherwise, the block will not be accepted by the fork choice rules.

The authenticator checks the validity of the issued principal

Note that you can actually implement some version of crList before enshrined PBS as well, though it will look different. Here's a suggestion from Quintus from Flashbots. Before enshrined PBS, a proposal to replace crList is also in progress. Some form of inclusion checklist, perhaps even some minimal form of enshrined PBS, should be prioritized. Looking forward to more suggestions here.

Barnabé offers another similar idea. Essentially, the proposer can create a prefix for the block to include the other censored transactions on top, and then the builder can build the rest (or the entire block if there are no censored transactions to include).

Preserving Block Proposer Proxy via MEV-Boost Using EigenLayer

Another method returns the proposer's proxy to attach the transaction. This scheme utilizes EigenLayer to enhance MEV-Boost, thereby increasing its censorship resistance.

EigenLayer is a "reinvented" collection that is expected to go live later next year. Ethereum validators who opt-in to EigenLayer subject themselves to additional slash conditions by setting the validator withdrawal address to the EigenLayer smart contract.

The protocol can be deployed permissionlessly on top of EigenLayer and attempts to incentivize these validators to choose to secure their own solution (in addition to Ethereum) with the same stake. Validators opt-in to any EigenLayer application of their choice. They can be axed for violating the application's rules. This allows other protocols (whether new cross-chain bridges, data availability layers, or anything else) to directly leverage Ethereum's economically secure subset.

• So, how does this apply to MEV-Boost? Participants who chose this structure did the following:

• Proposers re-stake their ETH with EigenLayer

• Builders send their block (builder_part) to relayers along with the Merkle_root of the contained transactions and their bid

• Relayers provide data availability (DA) by storing transactions. Relay sends merkle_root and bids to proposers for the most profitable valid block

• The proposer selects the highest bid from all connected relayers

• Proposers build their own backup alternative block B_alt locally

• The proposer sends a certification to the merkle_root of the winning bidder, connects it with the committed commit_B_alt (not the block header, may be the transaction root), and sends it to its own block B_alt

• The relayer reveals the builder_part containing the underlying transaction and sends it to the proposer

The proposer builds a new block containing the builder_part and appends an additional proposer_part (if they see other transactions they want to include and there is room in the block). If the relayer fails to release the underlying transaction, the block proposer will propose the block B_alt they built.

If the proposer proposes blocks other than B_alt, the proposer must include the builder_part, otherwise they will be chopped via EigenLayer. This is an additional condition they must abide by. This removes the need to trust the proposer - if they try to steal MEV after seeing the underlying transaction, they will have to propose a block other than B_alt and will be slashed.

This allows proposers to outsource block construction to maximize profits while still attaching vetted transactions. Proposers no longer have to choose between altruism and economic rationality.

If the most profitable builders are reviewing, and proposers are not obligated to review - the main strategy is to opt-in to this EigenLayer structure (assuming they can accept the additional liability and EigenLayer smart contract risk). This way, they are able to accept the highest value block and possibly make it more profitable by appending additional transactions.

Note that builder_part may end up being just a part of a block or the whole block. If the entire 30 million gas is used, of course there is no guarantee that it will ever be included. But EIP-1559 ensures that there is spare space available most of the time.

The Devil You Know vs. The Devil You Don't

Assuming Flashbots is turned off. The devil as you know it has been thwarted - most scrutiny will probably go away. Sounds good right?

But now demons you didn't know might appear. There is a power vacuum that needs to be filled, and other builders will fill it. The risk we face is that another builder simply takes the throne and cements itself as the dominant builder, which could do more damage.

In my opinion, the greatest risk of this happening comes from Exclusive Order Flow (EOF):

Builders can ensure that specific orders are sent only to them (e.g. promise not to previous users and give rebates on later profits). We can see some early examples of this. They can then bid higher, win more blocks, and prove more exclusive agreements.

A centralized block builder can wreak havoc:

rent

A competitive market ensures minimal rent extraction. Users are fairly compensated for the value they provide, and builders bid the remaining MEV to proposers. So far it looks good - builders vying for market share, bidding almost all captured MEV to validators. Even the relatively dominant Flashbots pass all the profits on to the validators.

EOF is the opposite. A dominant builder is incentivized to extract rent - they just need to outbid what other builders can get. More EOFs widen this gap with other builders.

For example, the wallet sends EOF to a builder because they are fairly compensated. But now, builders are getting bigger and bigger, and they build almost all Ethereum blocks. Then they reduce their fee rebates. The wallet wants to withdraw its EOF and go elsewhere. However, sending to other builders means that the wait times for block inclusion are unbelievably long, or they don't quite win the block. The wallet is stuck while the builder continues to withdraw.

review

review

First of all, fancy things like crList are not real-time. Today, the web is especially vulnerable to censorship.

• In the example below, I assume the market consists of only two builders:

• B₁ = censorship resistant builder

B₂ = builder with censorship rights

If B₂ gained significant market share today, they could enforce meaningfully weak censorship - and we've seen that. Remember, however, that this is not strong censorship.

A perfectly competitive market with rational validators prevents even weak censorship under any circumstances. Under optimal network conditions other things being equal, bid B₁ ≥ bid B₂. Both can include public mempool transactions, but only B₁ can also include OFAC transactions. Thus, a competitive PBS is only 1/N resistant to censorship as assumed by the builders.

Of course, this is not reality - builders have different order flows and algorithms, resulting in different bids. However, this clearly shows why we should strive for a competitive market. If B₂ controls too much market share due to EOF or other reasons, they can conduct meaningful scrutiny.

If they keep building the most valuable blocks, you're relying on effective validator altruism to avoid censorship. Hopefully they will ignore censored relayers and only connect to relayers that provide blocks from non-censored builders. But this may not be sustainable in the long run - the cost of being an honest validator should be reduced to ~0 (or ideally more profitable to be non-censored).

Note that crList doesn't completely eliminate this possibility. If B₂ consistently produces the most valuable blocks, then proposers broadcasting crLists containing OFAC transactions know they will not be able to accept the most profitable blocks. The economically rational decision is to broadcast an empty crList. However, if the difference between bid B₁ and bid B₂ is negligible (even in favor of B₁) due to market competition, then it is a reasonable assumption that the validator will publish crlist.

EOF poses a significant threat to censorship resistance — it can force validators to choose between honest and economically rational behavior. This disincentivizes honest behavior and allows review participants to earn higher rewards through increased market share. This should be avoided.

Less builder innovation

PBS is an opportunity for builders to provide innovative new features (eg account abstraction, pre-confirmation).

Competitive builders are encouraged to innovate in functionality to attract users' OF. Builders with solid foundations are not. Even if another builder starts offering better features, switching costs may be too high or simply not achievable (extremely long time to include transactions, never win blocks, PFOF transactions, etc. for other builders).

• Note that OF≠PFOF is obtained due to the superior function:

• Obtained OF due to superior functionality - the barrier to entry is the provision of new functionality.

PFOF - Barriers to entry are explicit payments, users need to wait for a long time, and may even violate the contract

Simply put, PFOF here means exclusivity, but its function is not. If some builders only provided desirable features in exchange for EOF, this would be as undesirable as PFOF.

What about EOF?

I won't go too deep here, but one possible route is to run an order flow auction. In fact, some auctions are held for the right to execute user orders. They get fair value for creating MEV and good execution guarantees. You can have an open auction, or a hidden auction in the form of fee escalations.

decentralized builder

The basic idea here is to make the winning builder itself a decentralized protocol. This is a very interesting design space that counters the threat of builder centralization.

There is also a wider design space for how decentralized builder marketplaces securely share order flow.

Here are the goals stated on the Flashbots homepage:

We are building a decentralized block building network to empower users and maximize the decentralization of public blockchains.

What do Flashbots do?

I understand that Flashbots is currently hesitant to hand over the keys to other builders, and I do believe that the people out there are well intentioned. As described earlier, some other builders may try to use more dubious motives to bolster their position and cause more damage to the network. This is obviously not desirable. It may be easier to push decentralized builders to operate from a vantage point.

But Flashbots will censor. And the applicable regulations are still a bit unclear, but that's beside the point. If the continued operation of Flashbots (including censorship) yields significantly better outcomes than otherwise, then they will be in Ethereum's long-term best interest. This scrutiny may just be a blip on the radar that will fade over the next year or so as the aforementioned ideas are fleshed out and realized.

Having said that, I personally find it difficult to definitively justify censorship in the hope that it will prevent others from doing so in the future.

Open source its builders and lead the market

The logical next step should be to open source their builders (again under the AGPL) as soon as possible. This will be an important step in lowering barriers to market entry for builders and will largely signal their intent. This will directly prioritize the health of the ecosystem over their short-term competitive advantage.

Research

Research

Flashbots research should continue to focus on solving censorship issues - decentralized builders, include lists, shared order flow, etc. These are the stated goals of Flashbots.

However, it's hard to see this from an outside perspective. Currently, only a handful of people are effectively deciding whether the entire Ethereum network is being censored at scale. Supporting any company undertaking this activity, regardless of their track record or stated goals, can hardly be rationalized.

Significant progress around this research needs to be made and kept open in the near term.

Repeater Operations

Honestly, I've thought twice on repeaters - should they run it? I asked Vitalik, Justin Drake, Phil Daian, Zaki Manian and Francesco D'Amato.

Vitalik reiterated one option — Flashbots could separate the neutral research entity from the corporate operating entity. This eliminates conflicts of interest in research and we no longer need to question the motives of the operators. We simply understand that they, like most others in the field, are working for themselves. The downside of this can be that research and product departments together create a positive feedback loop that produces meaningful progress, and you risk losing some of that. We saw that MEV-Boost was initially run as a research and later implemented by the product side.

• If they simply stop running their repeaters, the problem won't go away completely. Censorship rates may drop, but other review relayers may fill the void. Unforeseen new threats of censorship may also emerge over time. The participation of Flashbots as relayers/builders has two effects on the overall adoption of MEV-Boost:

• Increased adoption - The presence of Flashbots as a reliable service provider increases marginal adoption. But over time, this benefit may taper off as other relayers and builders work out their problems. Importantly, Flashbots can and should actively work to make this a reality, supporting it in every way possible.

If they are going to keep running their relayers, it should make sense to eventually impose a cap on the percentage of validators at some point. Again, actually either way, censorship is weak. But I still see a big difference in signal between 1% and 99% review. This will be most needed if the percentage of censored Ethereum blocks continues to climb, and no new changes are implemented to mitigate this (whether crLists, EigenLayer proposal, etc.).

final thoughts

final thoughts

I mention Flashbots here mainly for several reasons. They are certainly a major source of censorship, but they also generate a surprising amount of active work in the Ethereum ecosystem. Additionally, I believe they have a significant responsibility to the ecosystem if they are to stand between neutral community builders and traditional enterprise operators. In the end, because they're smart, they might create something cool.

Original link

Original link