# Flashbots POS Proposals

*This document is currently a draft - please sign in and comment to provide feedback*
## design goals

- **Pending block submission**
Instead of sending partial blocks (bundles) to the validators for them to merge and include, the solution should allow submission of full unsigned blocks. This is necessary for the introduction of privacy and avoiding excessive resource consumption on the ethereum clients.
- **Permissionless submission**
Anyone should be able to submit pending blocks to any validator running the necessary client. This is necessary to avoid centralization in mev extraction to a subset of relayers / validators.
- **Upstreamable**
In order to avoid replicating the client centralization currently present in
with 85% of miners using mev-geth, it is necessary for the design to be simple enough to be upstreamed and maintained by core client teams instead of being maintained as a fork. This would allow all clients to be MEV compatible out of the box.
- **ETH for payments**
The solution should enshrine eth as the payment token used to tip validators for inclusion. A solution which enables using an alternative currency for prioritization enshrines large holders of that currency as priviledged actors in the system as well as reduces the relevance of block rewards for security.

## summary of solutions

Comparing the solutions vs the design goals, we obtain the following matrix.

| Design Goal | Consensus based | Hacky solution | Trust based |
| ------------------------- |:---------------:|:--------------:|:-----------:|
| Pending block submission | ✅ | ✅ | ✅ |
| Permissionless submission | ✅ | ✅ | ❌ |
| Upstreamable | ✅ | ❌ | ✅ |
| ETH for payments | ❓ | ❌ | ❌ |

We can also compare the solutions vs the [original flashbots design goals](https://ethresear.ch/t/flashbots-frontrunning-the-mev-crisis/8251).

| Guarantee | Consensus based | Hacky solution | Trust based |
| ----------------- |:---------------:|:--------------:|:-----------:|
| Permissionless | ✅ | ✅ | ❌ |
| Efficient | ✅ | ✅ | ✅ |
| Pre-trade privacy | ✅ | ✅ | ✅ |
| Complete privacy | ✅ | ✅ | ❌ |
| Finality | ❓ | ❓ | ❓ |

The remainder of this document describes the solutions and how they achieve these properties. Notably, finality is not discussed by this proposal.

## common components

All three proposals have in common a profit switcher within the execution client which is able to process a number of pending block submissions and provide the most profitable one (measured by ETH paid to the block proposer) when requested by the consensus client.

Title: Block Proposal
network->consensus: votes, attestations & new blocks
Note over consensus: wait for allocated slot
consensus->execution: `consensus_assembleBlock`
Note over execution: proxy request to profit switcher
execution->profit switcher: `consensus_assembleBlock`
profit switcher->consensus: return unsigned block
Note over consensus: sign the block
consensus->network: propose block

This profit switcher is currently implemented in mev-geth as a [multi-worker](https://github.com/flashbots/mev-geth/blob/master/miner/multi_worker.go).

Pending blocks are defined as unsigned block headers and block contents which comply to the [`consensus_assembleBlock` specification](https://github.com/ethereum/rayonism/blob/master/specs/merge.md#assemble-block).

## option 1: consensus based block builder / proposer separation

This most closely resembles vitalik's [block builder / proposer separation design](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725).

The key to this design is the introduction of a new transaction type to the beacon chain which allows a new kind of account called a block builder to create and submit pending block commitment which includes the blockhash and payment requesting this blockhash to be signed and proposed by the block proposer. The block proposer would select the highest value submission it received and sign the associated blockhash, thus claiming the payment. It would then be up to the block builder to reveal the content of the block to the network within the allowed timeframe.

This proposal has the following enticing characteristics:
- pending block submissions can be be permissionlessly submitted over p2p and use existing DOS mitigation techniques
- no more need to maintain a core client fork - pos validators can run any client out of the box and get access to the most profitable blocks
- execution clients run by validators no longer need to listen to txpool network traffic
- achieves trustless privacy for block builders

With further research, this proposal might be able to achieve the following properties:
- enforce block is revealed by adding slashing condition for block builders who fail to reveal
- enforce highest value block (in ETH) is selected by adding slashing condition for block proposers who submit a block which does not match the winning pending block observed by the rest of the network
- enforce mev payments are burned (similar to 1559)

## option 2: hacky block builder separation

This most closely resembles the [current miningdao design](https://medium.com/mining-dao/introducing-miningdao-1e469626f7ad).

This design attempts to replicate the desireable property from option 1 of having an unconditional payment tied to the inclusion of a block, without necessitating a consensus change.

It works as follows:
1. block builder deposits sufficient ETH in a smart contract to cover his block payment budget
2. block builder finds a block they would like to get included
3. block builder signs a message which allows a payment to the block builder if the correct blockhash is signed.
4. block builder submits the signed message over p2p to the block proposer by hijaking the transaction data field. (see [carrier transactions](https://flashbots.notion.site/public-Carrier-Transactions-Spec-a79ecbbeaa774a5da8673965be7d9cbe))
5. block builder reveals the block content to the network

In theory, this mechanism is implementable without requiring a modification to the chain consensus. However, it requires the execution engine clients to enable monitoring of txpool for carrier transactions, verification of commitment, submission of claim transactions, and coordination between builder and proposer on revealing block content.

As a whole, it is successful at achieving the permissionless and privacy objectives, but comes with significantly more complexity which is nearly impossible to upstream. Additionally, it is trivial for ETH to be replaced by any token for payment purposes.

The exact implementation of the system needs additional research as there exist the following outstanding issues:
- block builder being able to grief block proposer by withholding the block proposal or frontrunning the payment claim
- unclear what is the best way for block proposer to propose blocks without having block body

Example payment escrow contract:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.6;

import {ECDSA} from "@openzeppelin/contracts/cryptography/ECDSA.sol";

contract BlockEscrow {
    using ECDSA for bytes32;

    mapping(address => uint256) deposits;

    function deposit() public payable {
        deposits[msg.sender] += msg.value;
    }

    /// warning: the block builder can greif the block proposer by frontrunning a claim with a self-withdrawl
    function claim(
        address recipient,
        uint256 blockPointer,
        uint256 value,
        bytes memory commitment
    ) external {
        bytes32 blockHash = blockhash(block.number - blockPointer);
        bytes32 commitHash = keccak256(abi.encodePacked(blockHash, recipient, value));
        address blockBuilder = commitHash.toEthSignedMessageHash().recover(commitment);
        require(blockBuilder != address(0));
        deposits[blockBuilder] -= value;
        payable(recipient).transfer(value);
    }
}

## option 3: trust based block builder separation

This most closely resembles the [current flashbots auction design](https://docs.flashbots.net/flashbots-auction/overview).

This design replicates the current trusted communication channel between block builders and miners with validators. This system is permissioned for two reasons:
- it requires validators to open a DOS sensitive rpc to block builders for block submission as it bypasses the p2p communication layer.
- it requires sending the block content in cleartext to the validator which means only whitelisted validators can receive blocks

This approach is suboptimal because it requires a centralized party like flashbots to monitor and regulate the behavior of validators. This also means that it cannot support all 200k validators on pos ethereum and can only support large staking pools. Having mev revenues accrue solely to large mining pools creates a significant centralization vector to the network.