---
title: MEV-Boost using EigenLayer
description: Use `{%hackmd theme-dark %}` syntax to include this theme.
---

<style>

html, body, .ui-content {
background-color: #333;
color: #ddd;
}

.markdown-body h1,
.markdown-body h2,
.markdown-body h3,
.markdown-body h4,
.markdown-body h5,
.markdown-body h6 {
color: #ddd;
}

.markdown-body h1,
.markdown-body h2 {
border-bottom-color: #ffffff69;
}

.markdown-body h1 .octicon-link,
.markdown-body h2 .octicon-link,
.markdown-body h3 .octicon-link,
.markdown-body h4 .octicon-link,
.markdown-body h5 .octicon-link,
.markdown-body h6 .octicon-link {
color: #fff;
}

.markdown-body img {
background-color: transparent;
}

.ui-toc-dropdown .nav>.active:focus>a, .ui-toc-dropdown .nav>.active:hover>a, .ui-toc-dropdown .nav>.active>a {
color: white;
border-left: 2px solid white;
}

.expand-toggle:hover,
.expand-toggle:focus,
.back-to-top:hover,
.back-to-top:focus,
.go-to-bottom:hover,
.go-to-bottom:focus {
color: white;
}

.ui-toc-dropdown {
background-color: #333;
}

.ui-toc-label.btn {
background-color: #191919;
color: white;
}

.ui-toc-dropdown .nav>li>a:focus,
.ui-toc-dropdown .nav>li>a:hover {
color: white;
border-left: 1px solid white;
}

.markdown-body blockquote {
color: #bcbcbc;
}

.markdown-body table tr {
background-color: #5f5f5f;
}

.markdown-body table tr:nth-child(2n) {
background-color: rgb(113, 121, 126);
}

.markdown-body code,
.markdown-body tt {
color: #eee;
background-color: rgba(230, 230, 230, 0.36);
}

a,
.open-files-container li.selected a {
color: #5EB7E0;
}

</style>

<style>
.heatMap {
width: 70%;
text-align: center;
}
.heatMap th {
background: rgb(81, 65, 79);
word-wrap: break-word;
text-align: center;
}
.heatMap tr:nth-child(1) { background: rgb(113, 121, 126); }
.heatMap tr:nth-child(2) { background: rgb(113, 121, 126); }
.heatMap tr:nth-child(3) { background: rgb(113, 121, 126); }
.heatMap tr:nth-child(4) { background: rgb(113, 121, 126); }
.wrapper {
width: 100%;
max-width: 1000px;
margin: 1em auto;
padding: 1em;
}
</style>

<style>
.button1 {
display: inline-block;
padding: 3px 10px;
text-align: center;
text-decoration: none;
color: #ffffff;
background-color: steelblue;
border-radius: 6px;
outline: none;
}
</style>
<style>
.button2 {
display: inline-block;
padding: 3px 10px;
text-align: center;
text-decoration: none;
color: #ffffff;
background-color: #18606A;
border-radius: 6px;
outline: none;
}
</style>
<style>
.button3 {
display: inline-block;
padding: 3px 10px;
text-align: center;
text-decoration: none;
color: #ffffff;
background-color: #FF5733;
border-radius: 6px;
outline: none;
}
</style>
<style>
.button4 {
display: inline-block;
padding: 3px 10px;
text-align: center;
text-decoration: none;
color: #ffffff;
background-color: #6923E3;
border-radius: 6px;
outline: none;
}
</style>

# Preserving Block Proposer Agency with MEV-Boost using EigenLayer

### TL;DR
* MEV-Boost only allows for full-block MEV, thus removing any agency for expressing preferance on inclusion of transactions from block proposers.
* We re-introduce this agency by enabling partial-block MEV via restaking through EigenLayer. By also allowing proposers to commit to a backup block, the trust on relay for validity check is also removed.
<!-- * As a second idea, we propose a mechanism to decentralize the relay. By using EigenDA for data availability, block proposers don't have to trust centralized relay for getting DA and privacy guarantees anymore. -->

## Introduction

In MEV-Boost's current design, block proposers who want to participate in MEV-Boost have to auction off the right to make the entire block in order to capture any MEV. The key reason for this is that MEV-Boost only allows full-block building in the MEV market. This limitation stems from the fact that, with the current architecture of MEV-Boost, block proposers can only attest to the block headers while selecting the highest bid.

Having MEV-Boost provision for only full-block building leads to a restriction on the set of features it can guarantee:
1. **No freewill for block proposers.** With MEV-Boost, the contents of blocks are completely determined by block builders and relays who are likely to be centralized organizations whose incentives are very different from decentralized collectives of block proposers. One way for the block proposers to exercise freewill in construction of the block involves not participating in MEV-Boost and instead constructing blocks locally. Unfortunately, this pits the economic incentives of block producers against their agency to participate in decentralized block production. As a concrete example, suppose all block builders collude to operate a censorship market, then some transactions can be censored for extortion. Whereas if the block producers were highly decentralized, such collusion attacks become very difficult to coordinate.
2. **Limited slashing capability.** With full-block building, MEV-Boost features only one slashing capability -- specifically when a block proposer proposes a different block than the commited one. This slashing is piggybacked on ETH$2.0$'s slashing for equivocation. However, with our proposed upgrade for decentralization of MEV-Boost, there is necessity for a much richer trapestry of slashing capabilities.

We propose an incremental upgrade on MEV-Boost that employs EigenLayer for increased decentralization in block production while using a broader set of slashing primitives to secure the system.

## Upgrade: Partial-block MEV-Boost via EigenLayer

MEV-Boost, in its current format, features only full-block building. The reason behind having that restriction is that MEV-Boost piggybacks on slashing in ETH$2.0$. More explicitly, when the block proposer signs the header provided to them by the relay, the proposer binds themselves to it (indicated by Step [6] in following figure). If they ever sign the header of a different block at the same height, they are slashed according to Ethereum's slashing conditions for equivocation. This binding gives the relay the assurance that the builder's block will be either proposed or the proposer must forfeit their slot entirely or the proposer will propose a a different block in which case it will be slashed according to ETH $2.0$'s slashing primitve. Since Ethereum only slashes block proposers for signing two block headers at the same height, MEV-Boost only features builders having build the entire block in order to provide a header to the proposer.

<!-- The reason that the block proposer must delegate the production of the entire block to block builders can be seen in step [6] in the figure below. -->

***Fig1. An overview of MEV-Boost.***

However, this full-block building removes any power from the block proposers (a highly decentralized set) to express any opinion on the composition of the block. To remedy this situation, we propose **partial block MEV-Boost using EigenLayer**.

### Protocol description
See Fig. 2 for an illustration. The primary steps involved in this upgrade are:
1. **Staking with EigenLayer.** Block proposers must have restaked their ETH with EigenLayer in order to participate in this upgraded protocol for MEV-Boost. Block proposers can either restake their stake on the beacon chain by pointing their withdrawal credentials to the EigenLayer contracts or they can have people delegate to them on Ethereum's execution layer in exchange for MEV rewards.
2. **Block builder assembling partial block.** In partial block MEV-boost, block builders assemble the portion of the block they are intereseted in creating. This could be the entire-block or could be a portion of the block. We note that due to EIP-1555 it is not possible for the builders to continually build full blocks (as price escalates exponentially). This ensures that even when given full freedom, blocks will always have excess space. For the purpose of explanation, we assume block builders assemble half of a block `builder_part` (we note again this will not be half of a block each time but due to 1559, this will be on an average half a block) and compute a `merkle_root` of the transactions contained in this half. The builders then send these transactions along with the associated `merkle_root` and `bid` to the relay.
6. **Centralized relay provisioning DA only.** The relay provisions data availability (DA) by storing the transactions and communicates the (`merkle_root`, `bid`) to the block proposer.
7. **Commitments by block proposer.** The MEV-Boost protocol continues as before with the block proposer selecting the highest bid. The proposer also assembles an alternative block `B_alt` of their own. The block builder then sends an attestation to the winning bid's merkle root `merkle_root` concatenated to a commitment `commit_B_alt` (not the header, but perhaps the transaction root) to their own block `B_alt`.
8. **Revealing the data.** The relay then releases the underlying transactions `builder_part` of the winning bid's merkle root to the block proposer. The block proposer then assembles a new block with the released transactions in the first half and fills the last half with whatever transactions `proposer_part` they desire. If the relay does not release the underlying transactions, the block proposer proposes the alternative block `B_alt` they assembled.

***Fig2. An overview of MEV-Boost + EigenLayer.***

### Analysis
Because the block proposer is not signing the block header in the above protocol description, a natural question that may arise is whether the proposer could steal the transactions released from the relay and assemble a new block that steals all the builder's MEV for themselves. This is a genuine concern as the block propser is not signing on the block header and hence the protocol can't piggyback on ETH $2.0$'s slashing primitive if block proposer sign a block that steals the builder's transactions. However, as the block proposers are staked in EigenLayer, they would get slashed if they ever propose a block that did not include the transactions in `builder_part` released to them by the relay (this can be proven on chain via proofs against a block's transactionRoot and the `merkle_root` for `builder_part`) or if they didn't propose the alternate block `B_alt` they attested to in step [8] as shown in Fig. 2.

With EigenLayer, we can now impose a cryptoeconomic cost on the block propser for stealing the block builder's trasactions, thus, allowing block builders to feel comfortable. Just as before, builders can still extract MEV while following whatever regulations their jurisdictions require. More importantly, this system dissolves all economic and political tradeoffs mentioned in the introduction. Now, block proposers can still include MEV-extraction transactions from builders so they do not lose out on economic returns from MEV extraction and, since they can include the second half of their block with whatever transactions they desire, **they can contribute to the censorship resistance of Ethereum**.

We note that as a side-effect, the aforementioned system completely mitigates any liveness issues that arise from MEV-Boost: for example, a) the relay may sign an invalid block or b) the relay may not make the block available to the block proposer. This has been a well-documented concern (https://writings.flashbots.net/writings/understanding-mev-boost-liveness-risks/). This problem is completely solved with the proposed approach as the block proposer can just release the block `B_alt` in either of the above situations.

Due to the use of alternative block `B_alt`, our proposed upgrade requires the relay to serve only data availability for `Builder_half` but doesn't require them to check the validity of transactions included in `Builder_half`.

We finally note that a downside of the proposed approach (the inclusion of an alternative block) is that the block proposer may fraudulently try to take-over the MEV of the builder in the next block. While we think protecting Ethereum liveness is a better tradeoff, removing the alternative block is an option in this design as well.
<!--
## Upgrade-2: Decentralizing the relay via a DA layer

A caveat with MEV-Boost and by extension with above Upgrade-1 is that both the block builder and proposer rely on the MEV-Boost relay to do the following:
* **For builder's privacy.** Make transactions private to the proposer before signing,
* **For data availability to proposer.** Make transactions available to the proposer after signing.

With an incremental modification to the above protocol, block builders can instead send their transactions to a decentralized Data Availability service such as EigenDA. The protocol is as follows:
1. **Data availability from EigenDA.** Builders encode their bundle of transactions `first_half` and disperse the encoded chunks `enc_first_half` to EigenDA along with the polynomial commitment `poly_com` and their associated proofs `proof`. In return, the builder recieve signatures from a quorum of EigenDA validators on the polynomial commitment `poly_com` . Note that since this happens off-chain, they can do it at network latency. The builders then send the `merkle_root` for `first_half`, polynomial commitment `poly_com`, the aggregated attestation `aggregate_sign` of availability from EigenDA, and their `bid` to the proposer who is staked with EigenLayer.
2. **Commitments by block proposer.** As before, the block proposer assembles an alternative block `B_alt` privately to act as a backstop in case of safety failure as EigenDA provisions only conditional data availability (otherwise, which would translate to liveness failure on Ethereum). The proposer then sends its attestation to the winning bid's transaction commitment (represented by the `merkle_root`) concatenated with the transaction commitment `commit_B_alt` of its proposed alternative block `B_alt`.
3. **Retrieving from EigenDA.** Upon receiving a valid attestation from the block proposer, EigenDA validators make the builder's transactions `first_half` available to the block proposer. Just as before, the proposer includes the builder's transactions in the first half of their block and includes the `second_half` with whatever transactions they desire. If EigenDA is corrupted, and doesn't reveal the transactions to the block proposer, the proposer proposes its alternative block `B_alt`.

Fig. 3 illustrate this proposed upgrade to data availability using EigenDA.

**Fig. 3. An overview of MEV-Boost-EigenLayer-EigenDA.**

### Analysis
With the above proposed upgrade, instead of both the builder and the proposer having to trust the centralized MEV-Boost relay, they both have to trust that the super-majority of ETH quorum of EigenDA is honest. More formally, the security guarantees obtained from EigenDA is captured by the following theorem:
> **Theorem 1.** EigenDA is conditionally safe as long as at least $\frac{1}{c}$ of stake in ETH quorum is honest. In such a case, all malacious EigenDA nodes who might have signed on unavailable datablob (here this would be `first_half`) are slashed.

In EigenDA, $\frac{1}{c}$ denotes the fraction of stake that is required for activating the bomb associated with proof-of-custody.

Finally, one may observe that EigenDA does not make sure that the transactions are valid. Fortunately, since block builders erode their reputation if their transactions are invalid, not only can proposers propose their alternate block, but all future proposers will cut connections with the builder and can even refuse any future bids from them. This makes assembling invalid transactions a very unprofitable move for block builders.

Hence, not only are we able to preserve decentralization of Etherum stakers, but we are able to also reduce single, centralized party trust assumptions with MEV-Boost+EigenLayer+EigenDA!
-->
<!-- Cons: 1) Efficiency, 2) Fraud-proofs via optimism type system (complexity). 3) Delay = 6x vs 5x (questions on latency optimization)
-->

<!-- ## Threshold Encryption add-on
On top of the above series of upgrades, we can incorporate threshold encryption for providing MEV protection. This upgrade, inaddition to Upgrade $2$, works as follows:
1. **Threshold encryption task in EigenLayer.** A new task in EigenLayer is specified which requires the nodes who have subscribed to this task to generate threshold key pairs for each slot and reveal their public encryption keys immediately while keeping the associated decryption keys secret unil a later time. We denote these group of nodes as $\mathcal{G}$.
2. **Using threshold encryption for frontrunning.** Anyone wishing to use threshold encryption to protect their transactions from frontrunning, can have their transactions encrypted using the above active threshold encryption keys and send it (denoted by `enc_tx`s) to the block proposer.
3. **Commitment by block proposer.** The block proposer sends back a commitment `commit_enc_tx` to include the decrypted version of these encrypted transactions later in their block (both partial version and alternative version).
4. **Revealing decrypted transactions.** Once the commitment `commit_enc_tx` for all encrypted is received back, the decryption key for the threshold keypairs for that slot are revealed by the nodes in $\mathcal{G}$.

The block proposer includes the transactions received via threshold encryption after the transactions received from the block builder as part of MEV-Boost. After the transctions received via threshold encryption, the block proposer can include transactions of its own choice, which enables censorship resistance.


This combination of MEV-Boost, EigenLayer, EigenDA and threshold encryption has threefold benefits: enables capture of stochastic MEV by block builders, censorship resistance and MEV-protection.

Need to add: Sanitization mechanics, Alternative Block structure.

-->

## Discussion
<!-- Cons: 1) Efficiency, 2) Fraud-proofs via optimism type system (complexity). 3) Delay = 6x vs 5x (questions on latency optimization)
-->
### Latency
Observe that, with MEV-Boost and by extension to all the proposed upgrade in this work, latency $\ell$ from when a builder makes its bid to when the block proposer releases the proposed block to rest of the network is an important quantity. Given that this whole process of block building and proposing should wrap up within the heat of the consensus, it is imperative that the latency $\ell$ is as minimal as possible.

Assume that the network latency is given by $\Delta$. Suppose that there is negligible latency from intermediate computations in relay and block proposers.

Referring to Fig. 1, for MEV-Boost, latency $\ell_{MEV-Boost}$ is given by
\begin{align}
\ell_{MEV-Boost} = \overbrace{\Delta}^{[1]} + \overbrace{\Delta}^{[3]} + \overbrace{\Delta}^{[6]} + \overbrace{\Delta}^{[7]} +
\overbrace{\Delta}^{[8]} = 5\Delta
\end{align}
The numbers in [.] at the top of each term indicate the step number in Fig. 1.

Referring to Fig. 2, for MEV-Boost + EigenLayer, latency $\ell_{MEV-Boost + EigenLayer}$ is given by
\begin{align}
\ell_{MEV-Boost + EigenLayer} = \overbrace{\Delta}^{[1]} + \overbrace{\Delta}^{[4]} + \overbrace{\Delta}^{[8]} + \overbrace{\Delta}^{[9]} +
\overbrace{\Delta}^{[11]} = 5\Delta
\end{align}
The numbers in [.] at the top of each term indicate the step number in Fig. 2. Observe that the latency incurred in MEV-Boost + EigenLayer is same as that in MEV-Boost.

<!-- Referring to Fig. 3, for MEV-Boost + EigenLayer + EigenDA, latency $\ell_{MEV-Boost + EigenLayer + EigenDA}$ is given by
\begin{align}
\ell_{MEV-Boost + EigenLayer + EigenDA} = \overbrace{\Delta}^{[1]} + \overbrace{\Delta}^{[2]} + \overbrace{\Delta}^{[3]} + \overbrace{\Delta}^{[4]} +
\overbrace{\Delta}^{[5]} +
\overbrace{\Delta}^{[6]} = 6\Delta
\end{align}
The numbers in [.] at the top of each term indicate the step number in Fig. 3. -->

<!-- With MEV-Boost + EigenLayer + EigenDA, there is an extra $\Delta$ latency. However, typical values of $\Delta$ ranges in 100s of milliseconds. On the other hand, length of the slots in ETH $2.0$ is [12 seconds](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#time-parameters-1). That implies, MEV-Boost + EigenLayer + EigenDA puts negligible externality on the consensus of ETH $2.0$ in terms of latency. -->

### Penalty for building invalid blocks

In above upgrade, the block builder cannot affect Ethereum's liveness by proposing invalid transactions. However, the block builder doesn't get penalized from attempting to do such malicious action.

Ideally, as a system designer, one would expect the block builder to get penalized for doing so. One way to accomplish that is by having following two additional modifications:
1. **Re-staked block builders.** Block builders must have restaked their ETH with EigenLayer in order for it to participate in the upgraded MEV-Boost.
2. **Fraudproofs.** Raising disputes on invalid transaction bundles via fraudproofs in interactive challenges, as done in optimistic rollups, should be in place. With this capability, if a block builder proposes an invalid bundle in `Builder_part`, then the block proposer can raise a fraudproof once it retrieves `Builder_part` and get the block builder penalized.

With these modifications one can achieve a completely cryptoeconomic block production without any surgery on the consensus. The only caveat with this approach is that having interactive challenge mechanism using fraudproofs lend to complexity.

## Acknowledgements
We thank Dankrad Feist for suggesting the idea that the builder can build an arbitrary size of the block and the proposer can fill up the rest. This rests on the observation that 1559 ensures that builder will be unable to take up the whole block continually and there will be residual space for proposers.