Censorship... wat do?
The Road Ahead
Introduction
Censorship is incompatible with Ethereum’s values.
We’ve spent enough time dwelling on how we got here this past month or so. I’ll discuss the road ahead - how might we fix this?
Devs… wat do?
Combatting censorship head-on should be priority #1. Staking withdrawals probably have a strong claim to be addressed ASAP as well.
Scaling and the like can honestly take a back seat though. Ethereum can survive with a bit higher fees, but it cannot survive with censorship. EIP-4844, Danksharding, and other upgrades are complex and likely to divert a significant amount of time and attention. If it’s really needed, EIP-4488 can be implemented very quickly and is perfectly effective.
Prioritizing censorship resistance is the clearest way to demonstrate the community’s values. Failing to do so would be an incredibly poor signal which risks undermining credibility - why should validators, Flashbots, or any other relays/builders prioritize censorship resistance if core protocol development won’t even do it?
Besides, it’s a bear market and everyone’s poor, dead, or on the run by now. Fees are fine.
MEV-Boost
Brief architecture overview first. If you need further context, this Ethereum report may help.
Capturing MEV requires sophistication. If validators are tasked with this, they’ll become centralized - only sophisticated validators capable of extracting MEV will earn competitive returns. Proposer-builder separation (PBS) addresses this - create a new specialized “builder” role to build the optimal block. The builder then bids to the proposer (validator) to accept their block. Being a proposer remains easy, and they earn competitive returns = remain decentralized.
PBS will eventually get built into the protocol, but it’s not ready. PBS is here though - MEV-Boost is the out-of-protocol stepping stone for now (albeit with additional trust assumptions). It’s an additional sidecar piece of software that validators can run to query for outsourced block building. Validators still retain the option to use their own execution client and build blocks locally.
Many MEV searchers run specific strategies and bid for builders to include their transaction bundles. Builders can aggregate these bundles + any other private orderflow + public mempool transactions → build the optimal full block. Some builders can also internalize searching and play that role themselves.
Relay Overview
Relays are intermediaries which are trusted by both proposers and builders. They receive builder blocks and escrow them before sending them to the proposer. For a given relay, the process can look like this:
Design Goals
MEV-Boost addresses two main shortcomings of MEV-Geth:
1. Solo-staker participation
PoW miners were sent bundles, then they would create the full block with these bundles at the top. They were never sent full blocks. Flashbots never included OFAC-blacklisted transactions in its bundles, but it didn’t really matter because miners could just include them anywhere else in the block.
This scheme meant trusting the mining pool operators - they could see the bundles in the clear, so they could just steal those opportunities for themselves if they wished. This trust doesn’t scale to a giant set of Ethereum validators. That’s why MEV-Boost instead provides full blocks to proposers. Proposers sign and commit to the block header before the block body is revealed to them. If they try to MEV-steal after seeing the block body, they would need to then propose another block. Their original signature can be presented → proposer is slashed for double-signing.
This full-block scheme enables validator decentralization, but it adds significant censorship risk at the relay/builder level. If validators accept blocks from censoring relays, they will be de facto censoring.
If a censoring builder is the most profitable builder, then the proposer is forced to choose between being:
Economically rational - accepting the highest value block, even if censored
Altruistic - accepting a lower value block which does not censor)
Altruism assumptions should ideally be removed entirely or minimized as much as possible.
2. Client diversity
Most miners were running the Go Ethereum (Geth) client, so Flashbots simply forked it to create MEV-Geth. Running it was the only way to participate in the Flashbots Auction. PoS was an opportunity to improve client diversity. The MEV-Boost sidecar is interoperable with all consensus and execution clients.
MEV-Boost is neutral infrastructure:
Relays - Free to be run with whatever limitations or strategies they wish (e.g., censoring/non-censoring, “fair” ordering/max-profit, etc.). Relays can accept blocks from builders as they wish.
Builders - Free to run whatever strategies they please and deploy to any relay they trust that is willing to accept their blocks.
Validators - Free to run MEV-Boost or not. Free to use it alongside whatever clients they wish. Free to connect to as many or as few relays as they wish. MEV-Boost is effectively a relay aggregator that chooses the most profitable bid from the proposer’s selected relays.
MEV-Boost doesn’t censor OFAC transactions or sandwich trades. It simply allows proposers to outsource building, selecting from whichever relays they align with.
Censorship
This is how I’ll frame the censorship discussion:
Weak censorship = delayed but eventual inclusion. If say 50% of validators don’t include OFAC transactions, then on average they’ll get included after 2 blocks (24 seconds). If 90% censor, they’ll get in after 10 blocks (120 seconds), etc.
Strong censorship = censored transactions aren’t included on-chain. In Gasper this requires 51% of validators (simplifying here, proposer boost can change the math) to not only censor OFAC transactions for their own blocks, but to also actively ignore all new blocks which include them.
There doesn’t appear to be an imminent censorship threat from validators. They’ve seemingly taken the stance that they’re not obligated to censor OFAC transactions (yay!). This could be dealt with via a user-activated soft fork or slashing if needed, but that’s not my primary focus here.
The imminent censorship threat is at the relay/builder level. This has come primarily from Flashbots who runs the largest relay and builders. However, other relays censor as well - they just have lower market share, including:
bloxRoute’s “Regulated” relay
Blocknative
Eden Network
Non-censoring relays:
bloxRoute’s “Max-profit” relay
bloxRoute’s “Ethical” relay
Manifold Finance
I’ll focus on how to mitigate the threat at this level.
Validators… wat do?
I wrote this thread a while back, but I’ve been thinking about it again recently. I still feel similarly - I think it's best to run MEV-Boost, but only to use non-censoring relays.
Honestly, I would love to not run MEV-Boost at all if I was a validator. Flashbots is the most reliable relay/builder operator live (e.g., others have had bugs resulting in proposers missing slots), so I get the discomfort using some of them. But actively contributing to more censorship is harmful.
So running my solo client sounds nice and easy, but I think it's still best to run MEV-Boost with those other non-censoring relays. Otherwise, low adoption brings back negative externalities (PGAs, etc). Additionally, validators who do run it will earn more than the altruistic validators who don’t - they’ll systematically increase market share crowding out the altruistic ones over a long enough time period.
Ignoring MEV doesn't make it go away, we've seen this before.
Lower Flashbots relay adoption likely means less censorship. At the time of writing - MEV-Boost adoption sits ~42% of validators, and Flashbots is building ~60% of MEV-Boost blocks = ~25% of all Ethereum blocks are being censored there. The rate of MEV-Boost adoption is also steadily increasing. The censorship from other relays is pretty de minimis at the moment (they just don’t have meaningful market share).
Practically speaking, I don’t think “less censorship” makes much of any difference. If you’re at 20% censorship vs. 40% vs. 60%, those OFAC addresses are being censored and they have to wait. If the censorship rate goes up, they’ll just wait a bit longer.
However, I do think it’s incredibly important from a signaling perspective. Ethereum should be communicating to the world that this behavior is not in line with our values, and it will not be tolerated.
Protocol… wat do?
Unfortunately, the above solution of “just don’t use the Flashbots relay” relies on proposer altruism. If Flashbots is ever building the most valuable blocks (they usually do), a validator is actively choosing to make less money by not using them. Validators who are willing to accept censored blocks will again proportionally gain market share, and meaningful altruism is simply not a sustainable long-term strategy. We need better protocol design.
Enshrined PBS & crList
When PBS is built into the protocol, the relays will go away. The builder will interface directly with the proposer via an in-protocol auction. The builder commits to an unconditional payment removing the need for trust. Once a proposer signs the block header sent by the builder, they’re guaranteed to be paid the associated bid (even if the builder then reveals an invalid block body or withholds it entirely).
crLists put a check on this power. The exact implementation is an open design space, but here’s a simplified overview of “hybrid PBS” to get an idea. Proposers specify a list of all eligible transactions they see in the mempool, and the builder will be forced to include them (unless the block is full):
Proposer publishes a crList and crList summary which includes all eligible transactions
Builder creates a proposed block body then submits a bid which includes a hash of the crList summary proving they’ve seen it
Proposer accepts the winning builder’s bid and block header (they don’t see the body yet)
The builder publishes their block and includes a proof they’ve included all transactions from the crList or that the block was full. Otherwise the block won’t be accepted by the fork-choice rule
Attesters check the validity of the body that was published
Note that you can actually implement some version of crList prior to enshrined PBS as well, though it’d look different. One such proposal is covered by Quintus from Flashbots here. Alternative crList proposals prior to enshrined PBS are being worked on as well. Some form of inclusion lists and potentially even some minimal form of enshrined PBS should be prioritized. Looking forward to more proposals here.
Barnabé offered another similar idea here. Essentially the proposer can create a prefix for the block to include otherwise censored transactions at the top, then the builder could build the rest (or the whole thing if no censored transactions to include).
Preserving Block Proposer Agency with MEV-Boost using EigenLayer
Another approach returns proposers’ agency to append transactions. This proposal leverages EigenLayer to augment MEV-Boost, increasing its censorship resistance.
EigenLayer is a “restaking” collective expected to go live some time later next year. Ethereum validators opting into EigenLayer subject themselves to additional slashing conditions by setting their validator withdrawal address to the EigenLayer smart contract.
Protocols can permissionlessly deploy on top of EigenLayer and try to incentivize these validators to opt into securing their own solution (in addition to Ethereum) using their same stake. Validators opt into whichever EigenLayer applications they choose (it’s not all-or-none). They can be slashed for acting against this application’s rules. This allows other protocols (whether it be a new bridge, data availability layer, or anything else) to directly leverage a subset of Ethereum’s economic security.
Now, how does this apply to MEV-Boost? Participants opted into this construct do the following:
Detailing the above:
Proposers restake their ETH with EigenLayer
Builders send their part of the block (builder_part) to the relay along with a merkle_root of the transactions contained and their bid
Relay provisions data availability (DA) by storing the transactions. Relay sends the merkle_root and bid to the proposer for the most profitable valid block
Proposer selects the highest bid from all connected relays
Proposer locally builds their own backup alternative block B_alt
Proposer sends an attestation to the winning bid’s merkle_root concatenated to a commitment commit_B_alt (not the header, but perhaps the transaction root) to their own block B_alt
Relay reveals the builder_part with the underlying transactions and sends it to the proposer
Proposer assembles a new block with the builder_part included, and appends an additional proposer_part (if they see additional transactions they want to include, and there is still room in the block). If the relay failed to release the underlying transactions, the block proposer instead proposes the block B_alt they assembled
If the proposer proposes a block other than B_alt, the proposer must include builder_part or they will be slashed via EigenLayer. That’s the additional condition they subject themselves to. This removes the need to trust the proposer - if they tried to MEV-steal after seeing the underlying transactions, they would have to propose a block other than B_alt and would be slashed.
This enables proposers to outsource block building to maximize profits and still append censored transactions. Proposers no longer have to choose between altruism and being economically rational.
If the most profitable builder is censoring, and the proposer is not obligated to censor - the dominant strategy is to opt into this EigenLayer construct (assuming they’re comfortable with the additional responsibilities and EigenLayer smart contract risk). They’re now able to accept the highest value block, and potentially make it even more profitable by appending additional transactions.
Note that builder_part may end up being only a portion of the block or the entire block. If all 30 million gas is used, inclusion of course can never be guaranteed. EIP-1559 ensures though that excess room is available most of the time.
See Sreeram’s talk at SBC here where he elaborates on design possibilities.
The Devil You Know vs. The Devil You Don’t
Say Flashbots shuts down. The devil you know has been thwarted - most censorship likely goes away. Sounds great right?
But now the devil you don’t know could appear. There’s a power vacuum to be filled, and other builders will fill it. We run the risk of another builder simply taking the throne and entrenching themselves as the dominant builder, potentially inflicting even more harm.
The greatest risk to this playing out is due to exclusive order flow (EOF) in my view:
Builders could make sure that certain orders are sent only to them (e.g., promise not to front-run users and give them a rebate on back-running profits). We can see some early examples of this playing out. Then they can bid more, win more blocks, and justify more exclusivity agreements. Another h/t to Quintus for his great articles on the topic here and here.
A centralized block builder can inflict serious damage:
Rent Extraction
A competitive market ensures minimal rent extraction. Users are fairly compensated for their value provided, and builders bid the remainder of MEV to proposers. We look pretty good today - builders fighting for market share are bidding nearly all MEV captured to validators. Even Flashbots in its relatively dominant role passes all profits to validators.
EOF flips this. A dominant builder is incentivized to extract rent - they only need to outbid the amount that other builders can capture. More EOF widens this margin over other builders.
The builder probably extracts very little at the start of this EOF cycle - fairly compensating users is one of the easiest ways to secure EOF. However, the builder becomes incentivized to extract rent once they’ve established a monopolistic position. They’re also empowered to do so - the switching cost increases as they build a higher percentage of blocks.
Example - wallet sends EOF to a builder because they’re being fairly compensated. But now the builder grows larger, and they build almost all Ethereum blocks. Then they reduce their fee rebates. The wallet wants to pull its EOF and go elsewhere. However, sending to the other builders means incredibly long wait times for block inclusion, or they’re unable to win blocks entirely. The wallet is stuck, and the builder continues to extract.
Censorship
For starters, the fancy stuff like crList isn’t live. The network is particularly vulnerable to censorship today.
In the following examples, I’ll assume the market includes only two builders:
B₁ = censorship resistant builder
B₂ = censoring builder
B₂ could perform meaningful weak censorship today if they gained large market share - we already see this. However, remember this is not strong censorship.
A perfectly competitive market with rational validators would prevent even weak censorship in all cases. All else equal in optimal network conditions, bid B₁ ≥ bid B₂ . Both can include public mempool transactions, but only B₁ can also include OFAC transactions. Competitive PBS then has only a 1/N builder assumption for censorship resistance.
Of course this isn’t the reality - builders have different order flow and algorithms which result in different bids. However, this clearly demonstrates why we should strive for a competitive market. If B₂ controls an undue market share due to EOF or some other reason, they can censor meaningfully.
If they consistently build the most valuable blocks, you’re relying on significant validator altruism to avoid censorship. The hope is that they will ignore the censoring relays, and only connect to relays which provide blocks from non-censoring builders. This is likely unsustainable in the long-run though - the cost of being an honest validator should be reduced to ~0 (or ideally it’s more profitable to be non-censoring).
Note that crList doesn’t remove this possibility entirely. If B₂ consistently produces the highest value blocks, a proposer who broadcasts a crList with OFAC transactions knows they will not be able to accept the most profitable block. The economically rational decision is to broadcast an empty crList. However, if the difference between bid B₁ and bid B₂ is negligible (or even in favor of B₁) due to a competitive market, it’s a reasonable assumption that validators will publish crLists.
EOF presents a significant threat to censorship resistance - it can force validators to choose between honesty and economically rational behavior. This disincentivizes honest behavior, and it allows censoring participants to earn higher rewards compounding their market share. This should be avoided.
Reduced Builder Innovation
PBS is an opportunity for builders to offer innovative new features (e.g., account abstraction, pre-confirmations). Great talk by Alex Stokes on the topic here.
Competitive builders are incentivized to innovate on features to lure users’ OF. An entrenched builder is not. Even if another builder starts offering better features, the switching cost may be too high or completely infeasible (very long transaction inclusion time for other builders, unable to ever win a block, contractual payment-for-order-flow a.k.a. PFOF deal, etc.).
Note that acquiring OF due to superior features ≠ PFOF:
Acquiring OF due to superior features - The barrier to entry is offering new features.
PFOF - The barrier to entry is explicit payment, users incurring long wait times, or possibly even breaking contracts
Put simply - PFOF implies exclusivity here, but features do not. In the event that certain builders provide desirable features only in return for EOF, this would be equally as undesirable as PFOF.
EOF… wat do?
I won’t get too in the weeds here, but one possible route is to run order flow auctions. Effectively, some auction is run for the right to execute users’ orders. They receive fair value for their MEV created and good execution assurances. You can run an explicit auction or an implicit one in the form of fee escalators. Please see Quintus’ article linked again here for a great description of their current state.
Decentralized Builders
I’ll keep this short agin as I’ve written about this previously (linked below). But the basic idea is to make the winning builder itself a decentralized protocol. This a very interesting design space to combat the threats of builder centralization.
There’s also a wider design space of how a decentralized builder market can possibly share order flow securely.
The below is a stated objective on Flashbots’ homepage:
We are building a decentralized block-building network to empower users and maximally decentralize public blockchains.
Flashbots… wat do?
I understand Flashbots’ hesitancy to hand the keys over to other builders at the moment, and I do believe the people there are generally well-intentioned. As described earlier, some other builder could try to entrench themselves with more questionable motives and inflict even more pain on the network. This is obviously undesirable. It may be easier to drive toward decentralized builders operating from a position of strength.
But Flashbots censors. The applicable regulations are a bit unclear still, but that’s besides the point. This is what matters - Flashbots would be acting in Ethereum’s long-term best interest if their continued operations (including censorship) results in a clearly better future than the path that would unfold otherwise. This censorship may just be a blip on the radar that goes away within the next year or so as the ideas above are fleshed out and come to fruition.
That being said, I personally find it hard to justify explicitly censoring now with the hope that it prevents someone else from censoring in the future.
Open-Source Their Builder & Bootstrap the Market
If Flashbots is unwilling or unable to walk back relay censorship, I believe they owe it to the community to further bootstrap and support other non-censoring relays/builders. They’ve already taken some important steps here, such as open-sourcing their relay prior to the Merge. This was done under AGPL - an aggressive copy-left license that requires derivatives to be developed in the open.
The logical next step should be to open-source their builder ASAP (again under AGPL). This would be a significant step in lowering the barriers to entry for the builder market, and it would go a long way in signaling their intentions. It would directly place the ecosystem’s health over their short-term competitive advantage.
Research
Flashbots’ research should remain focused on addressing censorship - decentralized builders, inclusion lists, sharing orderflow, etc. These are Flashbots’ stated goals.
However, it is difficult to square this from an outside perspective. Currently a handful of people are effectively deciding whether the entire Ethereum network is being censored at scale. Supporting any company conducting this activity in the hopes that it leads to future research and action is difficult to rationalize, no matter their track record or stated goals.
Significant progress and openness surrounding this research in the near-term is needed.
Relay Operations
I’ve honestly gone back and forth on the relay - should they run it or not? I asked Vitalik, Justin Drake, Phil Daian, Zaki Manian, and Francesco D’Amato exactly that at SBC linked here at 39:49 if you’d like to hear their far more educated take first.
Vitalik reiterated one option - Flashbots could split the neutral research entity vs. the corporate operator entity. This removes conflicts of interest in research, and we no longer have to question the operator’s motives. We’d simply understand they’re working as the rest of the field mostly is - for themselves. The downside here could be that the research and product arms together create a positive feedback loop which yields meaningful progress, and you could lose some of that. We saw MEV-Boost start out as a research effort later implemented by the product side.
The problem doesn’t go away entirely if they were to simply stop running their relay. Censorship rates likely drop, but other censoring relays may fill that hole. Unforeseen new censorship threats are also likely to emerge over time. Flashbots’ participation as a relay/builder has two effects on MEV-Boost’s overall adoption:
Increased adoption - Flashbots’ presence increases adoption on the margin as a reliable service provider. This benefit is likely to diminish though over time as other relays and builders work out their kinks. Importantly, Flashbots can and should actively work to make that come to reality, offering support in every way possible.
Decreased adoption - Flashbots’ presence has reduced trust in this system overall which prevents at least some further adoption. I think it’s fair to speculate that adoption would be higher if no relays or builders censored.
If they’re to continue operating their relay, eventually imposing a cap at some level on the percentage of validators should be reasonable. Again, you have weak censorship either way practically speaking. But I still see a big difference in signaling between 1% and 99% censorship. This would be most needed if the percentage of censored Ethereum blocks continues to climb, and no new changes are being implemented to mitigate this (whether it be crLists, EigenLayer proposal, etc).
Final Thoughts
I mostly called on Flashbots here for a few reasons. They are of course the primary source of censorship, but they’ve also been the source of an incredible amount of positive work for the Ethereum ecosystem. Additionally, I believe they hold a significant responsibility to the ecosystem if they’re going to toe the line between neutral community builder vs. traditional corporate operator. Lastly, because they’re pretty smart so they can probably build some cool stuff.
To be clear - I’m not here to place any more blame, or talk about past actions. We are where we are. I just want to see this fixed. This requires productive and open discussion around the best course of action for the most important players. Flashbots is one of them.
However, I also strongly implore other relays and builders to operate in a good-faith manner and support the ecosystem as much as possible through similar actions. Ethereum and crypto as a whole may have a limited window to get this right.
