This document is currently a draft - please sign in and comment to provide feedback
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.
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.
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.
This profit switcher is currently implemented in mev-geth as a multi-worker.
Pending blocks are defined as unsigned block headers and block contents which comply to the consensus_assembleBlock
specification.
This most closely resembles vitalik's block builder / proposer separation design.
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:
With further research, this proposal might be able to achieve the following properties:
This most closely resembles the current miningdao design.
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:
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:
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);
}
}
This most closely resembles the current flashbots auction design.
This design replicates the current trusted communication channel between block builders and miners with validators. This system is permissioned for two reasons:
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.