In an earlier article, I covered the basics of MEV (Maximal Extractable Value), the most common ways it is extracted, and the (mostly negative) impact it has on the Ethereum network as a whole.

The problems caused by MEV are quite serious. The competition between and amongst searchers/validators to extract as much value as possible from transactions leads to:

• A terrible user experience due to the proliferation of frontrunning attacks and the like.

• High transaction fees and network overload.

• A heightened risk of the blockchain becoming centralized and non-secure.

Ethereum has plans to implement Proposer Builder Separation (PBS) to solve these issues. But Flashbots has already beaten them to it with their own version of PBS called MEV-Boost.

Flashbots is an organization that has been working to solve the MEV problems since 2020. Their efforts are divided into 3 categories: product, research and coordination.

With the goals of bringing transparency to MEV activity, democratizing access to MEV revenue and enabling fair redistribution of MEV revenue, Flashbots has rolled out products like MEV-Inspect, MEV-Explore, Flashbots Relay and more.

They implemented MEV-Geth as a solution to the MEV problem in pre-merge Ethereum, and at the merge rolled out a PoS-compatible iteration called MEV-Boost, which is an audited open-source software.

To understand the impact of MEV-Boost, it’s important to know the basics of how new blocks are added to Etheruem. In case you don’t already know, here’s the briefest breakdown:

• All transactions go into a public mempool

• Validators pick Txns from the mempool, include them in blocks (building), and send blocks to other validators (proposing) for attestation.

In the block building stage of this process, a validator has the ability to include, exclude, and re-order transactions to maximize the MEV they can capture through front-running, DEX arbitrage, Liquidations and more.

Also, the largest share of MEV is extracted not by validators, but by independent users called searchers, who use algorithms to scour the mempool and the dark forest of Ethereum for profitable MEV opportunities and then use bots to capitalize on them.

This competitive system of searchers versus searchers and validators versus validators results in the critical problems mentioned earlier, ones which MEV-Boost exists to solve.

PBS and MEV-Boost function on one key rule:

The entity who builds a block cannot be the same entity who proposes it.

While Ethereum’s native PBS will involve validators themselves functioning as both builders and proposers, Flashbots’ MEV-Boost outsources block building to non-validating entities called builders.

Before we break down the entire process, you should know that nodes on Ethereum run 2 clients: Execution layer clients to execute transactions, and Consensus layer clients to reach consensus on newly produced blocks.

The Engine API allows consensus layer clients to request execution payloads from execution layer clients. A modified version of this is the Builder API, which enables validators to source blocks from an external network of block builders (who aren’t using execution layer clients).

Now that this is clear, it’s time to break down the block production process with MEV-Boost implemented.

1. While users send individual transactions, searchers create bundles of profitable transactions and send them at once (kind of like rollups) to a network of builders.

To express their preferred position in a block, searchers submit sealed- price bids as opposed to a priority gas auction, thus encouraging transaction privacy.

2. The block builders gather transactions and bundles to build the most profitable blocks, the value of which comes from both MEV and transaction fees.

3. Builders then send their blocks to a relay—an entity responsible for checking the validity of the blocks and calculating the total value of the execution payload.

Relays are capable of malicious behaviour since they have the ability to censor or frontrun blocks distributed by builders.

4. Relays then do 2 things: send the entire payload to an escrow, and only the payload header to validators.

5. An escrow is an entity that provides data availability to validators, i.e., they guarantee the veracity of transactions without revealing the transactions themselves.

6. Validators identify the most profitable header, sign the block, and send it back to the relay and escrow to be propagated to the network.

If at this moment the validator decides to propose a different block, they will have signed two blocks and will be slashed.

Block builders set their own address as the recipient of the fees accumulated in the proposed block, and they also include a transaction which pays ETH to the validator at the end of the block.

This prevents builders and proposers from colluding to form private dark mempools, and ensures that the MEV is distributed fairly between both entities.

And that’s how Flashbots is solving the MEV problem with MEV-Boost.

An important thing to know is that validators can choose if they want to participate in this process. The Flashbots Relay doesn’t automatically send blocks to validators; they have to request blocks from the relay using MEV-Boost, and the relay in turn requests them from an open network of block builders.

Also, validators can use MEV-Boost to connect to multiple relays, and thus have more options to maximize their profit. Now some of you may be wondering if this system is permissionless and trustless. Bad news: it’s not.

Since relays are capable of malicious actions, they operate under the trust of their users. The same goes for escrows, which are trusted by relays to not broadcast payload details to validators before the header is signed.

Ethereum’s core tenet of trustlessness is violated by the use of permissioned and centralized parties like relays and, in the case of optimistic rollups, sequencers.

Taking cognizance of this issue, Flashbots is working towards decentralizing its relay. In the meantime, it remains the most trustworthy relay due to the company’s past performance and its long-standing policy of transparency and neutrality.

They have even set up a transparency dashboard, where you can see the amount of ETH being paid to validators from the MEV-Boost relay, the number of included blocks proposed by the relay, the daily average block reward, and more.

In the future, a permissionless PBS design at the consensus level will remove the need for relays and escrows. Perhaps keeping in mind that Ethereum’s core updates tend to take (way) longer than expected, Flashbots revealed a new project called SUAVE, which stands for ‘Single Unifying Auctions for Value Expression’.

At the recently concluded Devon Bogota, Flashbots steward Philip Daian stated that SUAVE will be an “open-source MEV-aware, privacy-focused, encrypted mempool for users and wallets.”

The fact that Flashbots plans to decentralize and democratize MEV-Boost by making it widely available, even to their competitors, shows that while they may be a centralized entity, they can be trusted…for now at least.

In an earlier article, I covered the basics of MEV (Maximal Extractable Value), the most common ways it is extracted, and the (mostly negative) impact it has on the Ethereum network as a whole.

The problems caused by MEV are quite serious. The competition between and amongst searchers/validators to extract as much value as possible from transactions leads to:

• A terrible user experience due to the proliferation of frontrunning attacks and the like.

• High transaction fees and network overload.

• A heightened risk of the blockchain becoming centralized and non-secure.

Ethereum has plans to implement Proposer Builder Separation (PBS) to solve these issues. But Flashbots has already beaten them to it with their own version of PBS called MEV-Boost.

Flashbots is an organization that has been working to solve the MEV problems since 2020. Their efforts are divided into 3 categories: product, research and coordination.

With the goals of bringing transparency to MEV activity, democratizing access to MEV revenue and enabling fair redistribution of MEV revenue, Flashbots has rolled out products like MEV-Inspect, MEV-Explore, Flashbots Relay and more.

They implemented MEV-Geth as a solution to the MEV problem in pre-merge Ethereum, and at the merge rolled out a PoS-compatible iteration called MEV-Boost, which is an audited open-source software.

To understand the impact of MEV-Boost, it’s important to know the basics of how new blocks are added to Etheruem. In case you don’t already know, here’s the briefest breakdown:

• All transactions go into a public mempool

• Validators pick Txns from the mempool, include them in blocks (building), and send blocks to other validators (proposing) for attestation.

In the block building stage of this process, a validator has the ability to include, exclude, and re-order transactions to maximize the MEV they can capture through front-running, DEX arbitrage, Liquidations and more.

Also, the largest share of MEV is extracted not by validators, but by independent users called searchers, who use algorithms to scour the mempool and the dark forest of Ethereum for profitable MEV opportunities and then use bots to capitalize on them.

This competitive system of searchers versus searchers and validators versus validators results in the critical problems mentioned earlier, ones which MEV-Boost exists to solve.

PBS and MEV-Boost function on one key rule:

The entity who builds a block cannot be the same entity who proposes it.

While Ethereum’s native PBS will involve validators themselves functioning as both builders and proposers, Flashbots’ MEV-Boost outsources block building to non-validating entities called builders.

Before we break down the entire process, you should know that nodes on Ethereum run 2 clients: Execution layer clients to execute transactions, and Consensus layer clients to reach consensus on newly produced blocks.

The Engine API allows consensus layer clients to request execution payloads from execution layer clients. A modified version of this is the Builder API, which enables validators to source blocks from an external network of block builders (who aren’t using execution layer clients).

Now that this is clear, it’s time to break down the block production process with MEV-Boost implemented.

1. While users send individual transactions, searchers create bundles of profitable transactions and send them at once (kind of like rollups) to a network of builders.

To express their preferred position in a block, searchers submit sealed- price bids as opposed to a priority gas auction, thus encouraging transaction privacy.

2. The block builders gather transactions and bundles to build the most profitable blocks, the value of which comes from both MEV and transaction fees.

3. Builders then send their blocks to a relay—an entity responsible for checking the validity of the blocks and calculating the total value of the execution payload.

Relays are capable of malicious behaviour since they have the ability to censor or frontrun blocks distributed by builders.

4. Relays then do 2 things: send the entire payload to an escrow, and only the payload header to validators.

5. An escrow is an entity that provides data availability to validators, i.e., they guarantee the veracity of transactions without revealing the transactions themselves.

6. Validators identify the most profitable header, sign the block, and send it back to the relay and escrow to be propagated to the network.

If at this moment the validator decides to propose a different block, they will have signed two blocks and will be slashed.

Block builders set their own address as the recipient of the fees accumulated in the proposed block, and they also include a transaction which pays ETH to the validator at the end of the block.

This prevents builders and proposers from colluding to form private dark mempools, and ensures that the MEV is distributed fairly between both entities.

And that’s how Flashbots is solving the MEV problem with MEV-Boost.

An important thing to know is that validators can choose if they want to participate in this process. The Flashbots Relay doesn’t automatically send blocks to validators; they have to request blocks from the relay using MEV-Boost, and the relay in turn requests them from an open network of block builders.

Also, validators can use MEV-Boost to connect to multiple relays, and thus have more options to maximize their profit. Now some of you may be wondering if this system is permissionless and trustless. Bad news: it’s not.

Since relays are capable of malicious actions, they operate under the trust of their users. The same goes for escrows, which are trusted by relays to not broadcast payload details to validators before the header is signed.

Ethereum’s core tenet of trustlessness is violated by the use of permissioned and centralized parties like relays and, in the case of optimistic rollups, sequencers.

Taking cognizance of this issue, Flashbots is working towards decentralizing its relay. In the meantime, it remains the most trustworthy relay due to the company’s past performance and its long-standing policy of transparency and neutrality.

They have even set up a transparency dashboard, where you can see the amount of ETH being paid to validators from the MEV-Boost relay, the number of included blocks proposed by the relay, the daily average block reward, and more.

In the future, a permissionless PBS design at the consensus level will remove the need for relays and escrows. Perhaps keeping in mind that Ethereum’s core updates tend to take (way) longer than expected, Flashbots revealed a new project called SUAVE, which stands for ‘Single Unifying Auctions for Value Expression’.

At the recently concluded Devon Bogota, Flashbots steward Philip Daian stated that SUAVE will be an “open-source MEV-aware, privacy-focused, encrypted mempool for users and wallets.”

The fact that Flashbots plans to decentralize and democratize MEV-Boost by making it widely available, even to their competitors, shows that while they may be a centralized entity, they can be trusted…for now at least.