Ethereum Censorship and SafeStake: MEV, OFAC and Flashbots (Part I)

Daniejjimenez
SafeStake
Published in
8 min readNov 7, 2022

How MEV contributes to Ethereum Censorship

Red flags were raised for the entire crypto world and especially the Ethereum community this past August when Tornado Cash was sanctioned by the U.S. Treasury.

However, the alarm bells really went off when a large number of transactions were delayed for Tornado Cash users by Flashbots, one of the largest MEV relays operating on the Ethereum network. This kind of ‘soft’ censorship poses a threat to the very essence of blockchain technology, decentralization.

As you can see in the graphic below, post-Merge OFAC compliant blocks account for 65% of new blocks being added to Ethereum’s Beacon Chain. It has been said that once these compliant blocks exceeded 50%, Ethereum was effectively ‘censored.’

This post is the first in a two-part series where we’ll explain what ‘soft’ censorship of Ethereum means and explore how SafeStake’s infrastructure can support PBS (Proposer Builder Separation) relays in a decentralized manner for massive numbers of validators.

Part I will focus on what MEV (Maximal Extractable Value) is, how it works, and why it contributes to Ethereum’s centralization and censorship issue. Part II explores how SafeStake can help decentralize PBS relays to minimize censorship on Ethereum.

What is MEV?

MEV (Maximal Extractable Value) refers to the maximum value that can be extracted from block production beyond the standard block reward and gas fees. It does this by including and excluding certain transactions from a block and changing the order of transactions in a block.

The term was originally coined for PoW blockchain networks as Miner Extractable Value. However, it also exists in PoS networks like post-Merge Ethereum, hence changing Miner to Maximal.

At SafeStake we have adopted a novel approach called VEV, or Validator Extracted Value (VEV), but we’re getting ahead of ourselves. Back to MEV.

With MEV, the validator proposing the block has the power to order transactions in a way that maximizes their earning potential by ensuring that the transactions they include capture all available arbitrage opportunities.

This is where the lucrative potential of validators enters the picture. According to MEV-Explore, MEV has amounted to roughly $675 million in ETH over the past two years alone.

But why is MEV allowed to happen?

To understand why MEV is a ‘thing,’ it’s important to know that every transaction in Ethereum has a value associated with it. In general, there are two potential sources of value associated with transactions:

  • Priority Fees: the additional gas fee users can pay to get their transaction included as soon as possible.
  • MEV: second-tier happenings on Ethereum that produce arbitrage opportunities.

In most cases, the order in which a transaction becomes part of the Ethereum blockchain depends on both the size of the priority fee and all associated MEVs for the transaction.

To put this into perspective, everytime a transaction is made, for example, on Uniswap, an arbitrage opportunity is created and exploited by MEV ‘seekers’ to get a piece of this growing billion dollar industry.

Understanding how MEV works

To continue down the rabbit hole, to fully understand how MEV works, you must know the order of and how transactions are processed on Ethereum.

Transaction ordering on Ethereum

Let’s explore each step to understand how soft (or hard) censorship happens on Ethereum.

  1. Everything begins when a user initiates a transaction. Let’s continue with the Uniswap example. You connect your wallet to make a swap and the transaction (TX) is sent out via a remote procedure call (RPC). This is the first ‘stop’ a transaction makes.
A sample Uniswap screen

Now, a centralization problem occurs, and centralization can be synonymous with censorship. The RPC default endpoint is a Consensys product called Infura. Infura is an intermediary between you and the Ethereum network, and is the first potential point of failure.

2. Next, your transaction is routed to the Ethereum mempool before being correctly channeled to the blockchain network.

The mempool is a public pool of transactions that hang around until they’re included in a block. Normally, these transactions (TXs) are ordered in the block based on the priority fees users paid.

A screenshot from the Ethereum mempool

Now, MEV comes into play thanks to the arbitrage opportunities present in each transaction that MEV seekers try to capture.

To explain further, when you use a service like Uniswap to sell ETH on-chain, AMMs ‘slip’ a bit on every transaction and every dollar of ETH sold pushes the new price down a little bit more.

When selling a lot of a single asset ETH, the new price of the asset may be lower than the current market price. In this case, it makes sense for an MEV seeker to buy up ETH at the new price and sell it back at the market price, as it’s a risk-free arbitrage.

AMM-slippage arbitrages are some of the most common MEV transactions, although there are other forms such as backrunning, long-tail MEV, and others that are a bit beyond the scope of this article.

MEV seekers are highly optimized arbitrage bots. There are thousands upon thousands of MEV seeker bots scouring the mempool at any given time, competing with other bots over micro-pennies.

MEV seekers rely on the specific order of transactions in an Ethereum block to earn a profit. They must compete with other MEV seekers to get their transaction included ‘immediately after’, in order to take advantage of arbitrage.

How Back Running a transaction creates MEV opportunities

It all comes down to a kind of race where the finish line for an MEV seeker is getting their transaction included in a block. As previously discussed, most transactions are included in a block based on the size of the tip or gas users have paid, also making MEV a competition to see who is willing to pay the most for the next transaction slot.

Here is another place where issues can arise.

Suppose certain MEV seekers and MEV relays decide to form an alliance allowing them to take unfair advantage of users by forcing them to pay higher fees to have their transaction included in a block. This will translate into a less-than-optimal user experience and starts to expose how ‘soft’ censorship can happen.

The process continues along and each MEV seeker bot submits a bid with each transaction bundle they create. And here’s where MEV relays like Flashbots come into play. Flashbots is a giant auction providing a way for MEV seekers to bid on blockspace slots.

It works like this — MEV Seeker A says ‘If you want the transaction immediately after mine, you are going to have to pay for it. And if you win the auction, you get to backrun my transactions.’ MEV Seeker B says ‘Yes, I want my transaction included immediately after yours and I’m willing to pay for it.’ Now, the MEV seeker that wins the auction for the next slot sends its ‘bundle’ of transactions composed of its transactions plus the transaction backlog of MEV Seeker A (aka ‘backrunning’).

3. Once the MEV seekers create ‘’bundles’’ of transactions, they need all the transactions to be included in a specific order for their operations to work. For this, they require the next actor in the transaction chain: Block Builders.

Block builders make money by collecting all the bids from all the transaction bundles submitted by MEV seekers and all of the priority fees from individual transactions.

Thus, block builders will include the transactions of the winning MEV seekers along with the ones that paid the highest gas fees to be included. Just like MEV seekers, block builders are highly competitive.

4. Now, the block builder passes the block to a service called a PBS (Proposer Builder Separator) relay, which ‘escrows’ the block on their behalf. In addition to MEV relays, Flashbots also runs PBS relays that receive blocks from builders and show the block payouts to the validators.

And this brings us to the point where the censorship that is the subject of the current debate occurs.

Flashbots’ PBS relays have been applying a delay to transactions coming from Tornado Cash, enforcing OFAC regulations, and resulting in the soft censorship we are seeing.

How MEV Seekers, Block Builders, and PBS Relays Interact

A significant percentage of validators (~60%) run Flashbots’ ‘MEV-Boost’ software and most of the MEV-Boost blocks (~80%) run through the Flashbots relay that delays/excludes Tornado Cash transactions. And as mentioned, many validators use middleware software like MEV-Boost to make their work more profitable, making this issue a top-priority for the Ethereum community to address.

5. To complete the process, first, the PBS relay only delivers the header information. It does not deliver the complete block information until it receives confirmation from the attestors that the block is actually proposed and on-chain.

Only after the validator selects the block it wants to propose does the relay transmit the entire contents for the validator to transmit to the network. The relay ‘escrows’ the content of the block for security, preventing the validator from stealing the MEV for itself.

Now, the MEV transaction is successfully executed and distributed among the different actors that make this whole process possible in just a few seconds.

Conclusion

As you can see, there’s a lot to digest and think about when it comes to Ethereum’s future regarding MEV and censorship. If you enjoyed learning about the Ethereum transaction process, how MEV works, and how censorship happens on Ethereum, stay tuned for Part 2. We’ll explore how SafeStake’s cutting-edge infrastructure can help PBS relays be more decentralized and less prone to censorship.

About ParaState

ParaState takes Ethereum chain support to the next level by utilizing WasmEdge. We develop and execute high-speed smart contracts with built-in Ethereum compatibility (EVM and EWASM) and interoperability in next-level programming languages like Rust, C ++, and Golang.

ParaState is contributing to Ethereum Proof-of-Stake with a new tech stack called SafeStake, a trust-minimized, middle layer that promotes decentralized ETH 2.0 staking. SafeStake is the first staking pool to implement distributed validator technology (DVT). It is written in Rust and uses HotStuff consensus and Threshold Signature architecture to provide robust security and reliability for validators securing the Ethereum network.

Website | Blog | Twitter | Telegram | Discord | Github

--

--