# MEV Catalyst and Prysm

## Objective

To define what an MEV (Miner Extractable Value) client could look like after the Ethereum proof of stake merge and what changes need to be done now to make this happen.

## Background

Ethereum is migrating to proof of stake by early next year. The transition is a complex process referred to as "The Merge". Today, we have Ethereum proof of work clients such as go-ethereum, nethermind, erigon, and more. Additionally, we have a running proof of stake chain called the beacon chain which runs in parallel to Ethereum today, but does not process transactions or EVM execution such as the proof of work chain does today. The beacon chain is running in production, however, with real capital at stake. At the time of "The Merge", proof of work clients will stop running consensus and will defer to proof of stake clients for that work. That is, at the time of "The Merge", operators need to be running EthPoW and EthPoS nodes in parallel, and at the transition point, an operator's PoW node will connect to their PoS node to defer consensus.

**Pre-Merge (Today)**

<geth> <---devp2p for everything---> <geth>

**Post-Merge**

<beacon node (prysm)> <---libp2p---> <beacon node (prysm)>
      |                                  |
    <geth>  <--devp2p for eth1 txs-->  <geth>

The name of the changes required in geth to make this happen at the point of a merge transition is known as **catalyst**. Back in May 2021, the different Ethereum implementation teams were able to prototype a public testnet known as ["Nocturne"](https://twitter.com/vdwijden/status/1392458035340193796?lang=en) which ran this architecture of Ethereum using proof of stake and go-ethereum for EVM and transaction execution.

### What is MEV and MEV-Geth

Miner Extractable Value, or MEV for short, is the general term used to describe the amount of value that consensus participants, such as miners and validators, can extract from a blockchain. Ethereum is very rich in MEV, as miners have asymmetric power in how they can order transactions compared to other entities in the network. That is, miners can capture value for themselves for ordering transactions in an arbitrage scheme, for example. Although a full discussion of MEV is out of scope, an entire explanation can be found in the excellent post by Paradigm [here](https://research.paradigm.xyz/MEV).

One of the biggest risks with MEV is that current incentives and code encourage MEV to occur off-chain or by coordinated actors, such as mining pools, defeating the permissionless nature of Ethereum. [Flashbots](https://github.com/flashbots/pm) is an organization that aims to democratize MEV by creating a patched version of go-ethereum known as [MEV geth](https://github.com/flashbots/mev-geth). With MEV geth, users can submit **transactions bundles** directly to miners running the software. This offloads the searching of MEV to users in a permissionless manner. The changes in MEV geth do not need a hard fork, as they are simply a patch to how go-ethereum organizes transactions when packing into blocks to optionally accept a bundle from users instead.

More details on the goals of MEV geth and why it matters can be found in Flashbots' excellent post [here](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752).

### MEV and Eth2

A latest summary on MEV and Eth2 can be found [here](https://hackmd.io/@flashbots/mev-in-eth2), once again, written by the Flashbots team. In general, MEV bundle submissions will still happen at the go-ethereum layer, and the role of beacon nodes is minimal.

**The Flashbots team wants a way to experiment with MEV on Eth2 in a testnet environment**. To do this, we need to help them setup Prysm <> Geth catalyst first. Given there doesn't need to be much done on the Prysm side to support MEV Geth, this should be fairly simple. However, there is an important point to note regarding MEV on Eth2, and that comes down to the **timing of block proposals**.

## Block Proposals and MEV

In a call with the Flashbots team on July 26th, 2021, we discussed how MEV will work in a Prysm <> Geth Catalyst testnet or mainnet environment. Currently, block proposals in Eth2 have an important lifecycle that goes as follows:

We have a slot, which is a period of **12 seconds** in which a few things happen:

1. Within the first 4 seconds, a validator is expected to propose a block and propagate it to the network
2. Within the next 4 seconds, attesters are supposed to vote on the block they believe is the head, which is hopefully the block from the previous step
3. In the last 4 seconds, aggregators aggregate the attestations from the last step

Currently, there is a small time-tolerance for this, and right now, all clients are optimized to propose as fast as possible, attest as soon as possible, and aggregate as soon as possible. In MEV, however, you want to propose a block _as late as possible_ in case you find a profitable opportunity as a set of transactions in the mempool you wish to include. Given Eth2 works like clockwork in this predetermined lifecycle, messing around with and pushing these thresholds to the max can result in network instability and some risks. Given there is value to be extracted, validators _will_ push these limits as much as they can.

It is important to note this lifecycle and the time-tolerance thresholds are not enforced strictly in the spec but are more of an implementation consensus between the different Eth2 clients on mainnet today. Parameters like these can very heavily influenced by MEV and could be something to think about over the coming months.

### Changes Needed in Prysm and Geth

In order to support MEV, we need to allow Prysm to be able to propose as late as possible, and perhaps wait on geth to provide it an execution payload right at the end of the threshold. Additionally, Geth catalyst today prepares the execution payload right away on demand. Instead, we would want it to constantly be preparing a template in the background based on txs in the mempool and be ready to provide the best possible block to Prysm once Prysm asks for it.

## Action Items

- Provide the Flashbots team the latest information on how to run a Prysm <> Catalyst devnet
- Customize Prysm to be able to propose late or wait until Geth gives it an execution payload at the end of the 1/3rds threshold
- Allow the ability to programmatically change these time tolerance parameters perhaps via flags