# Flashbot's architecture ## Flashbot Auction's life cycle ![](https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2Fethrig%2FlMqCTqV4LK.png?alt=media&token=b9a9f43d-2496-4bca-9a79-24e7d69dcc9b) - Flashbots Auction (will call it Flashbots from here on) provides a private communication channel between Ethereum users and miners for communicating preferred transaction order within a block. - Why? For MEV, the normal tx pool has drawbacks $\rightarrow$ gas war + wasted block space + no granular tx ordering possible - Flashbots provides a private transaction pool + a sealed bid blockspace auction mechanism which allows block producers to trustlessly outsource the work of finding optimal block construction + reducing negative externalities ## Architecture overview ![](https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2Fethrig%2FD_DB1ZOkQG.png?alt=media&token=1a05bdf3-d34d-4bdc-a78c-f611e60236c7) - They are sending Flashbots bundles around... - What's a bundle? - Flashbots introduces a new `eth_sendBundle` RPC which standardizes the message format in the communication channel. This message is called a "Flashbots Bundle". - An RPC (remote procedure call) is initiated by the client, which sends a request message to a known remote server to execute a specified procedure ... - A bundle is simply a message template: ``` { "jsonrpc": "2.0", "id": 1, "method": "eth_sendBundle", "params": [ { txs, // Array[String], A list of signed transactions to execute in an atomic bundle blockNumber, // String, a hex encoded block number for which this bundle is valid on minTimestamp, // (Optional) Number, min timestamp for which bundle is valid maxTimestamp, // (Optional) Number, the max timestamp for which this bundle is valid revertingTxHashes, // (Optional) Array[String], A list of tx hashes that are allowed to revert } ] } ``` ## Searcher - Typically searchers are of the following types: - The usual MEV bots - users looking for protection, e.g. uniswap traders - Dapps with use cases like account abstraction (someone else pays for your tx) or gasless tx (e.g. mistX) ![](https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2Fethrig%2F7eQTTYrCci.png?alt=media&token=3adf6c52-9306-4b82-bb34-0e70abd9a153) - By submitting bundles directly to relayers instead of through the p2p network, searchers obtain Pre-trade privacy as their transactions cannot be seen by the rest of the network. - Searchers express bid either via gas prices and/or direct eth transfer to coinbase address (direct payment to miner) - ETH transfer to coinbase allows to make payment conditional on tx succeeding $\rightarrow$ no payment in case of failed bids ## Relayers - A relayer is a bundle propagation service which receives bundles from searchers and forwards them to miners. ![](https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2Fethrig%2F-PMCCvLYQl.png?alt=media&token=ca6d7ec5-a4fb-4b16-8283-9937bf737386) - Since searchers don't have to pay for failed bids they could spam the network with invalid bundles $\rightarrow$ denial of service attack - What would that look like? - Create a bundle that's invalid - Send to miner - Miner computes the bundle only to realize it wouldn't pay him, since the payment is conditional on a tx that's invalid - Spam miner with such bundles - Since nodes are not equipped to deal with this level of load on their own, the role of relayers is mainly to mitigate this DoS threat! - At the moment, Flashbots (the organization) is running an open source relayer call mev-relay. DoS protection as a service by Flashbots - Relayers have full access to the contents of all bundles and could easily reorder or steal or censor them! **TRUST BASED** ## Miners ![](https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2Fethrig%2F71wlP4q3mI.png?alt=media&token=a5b4d3bf-8980-41d6-ba34-aaf08e934a62) - Traditionally a miner will simply run geth and order tx by gas price - Miners connected to Flashbots, however, run the mev-geth client - mev-geth nodes evaluate incoming bundles using the first-price sealed-bid auction and pick the most profitable ones to place at top of block. Node then compares flashbots block with vanilla block and starts mining on most profitable block - MEV-Geth miners select the most profitable bundle per unit of gas used and place it at the beginning of the list of transactions of the block template at a given block height. - ![](https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2Fethrig%2F8gSfD_DYa-.png?alt=media&token=0c896e10-069d-4a73-b615-0730e367922a) - Miners also have full access to the contents of all bundles and could easily reorder or steal or censor them! **TRUST BASED** - Flashbots monitors miners behavior and stop relaying to them, if they misbehave... ## Advanced topics ### Searcher reputation - Searchers could just DoS attack flashbots relayer... - Flashbots introduced a searcher reputation system that kicks in in periods of heavy load - Currently searchers are classified into high reputation and low reputation queues. - The high reputation queue is designed to filter out searchers who use an excessive amount of computation resources on the relay. - Reputation scoring ![](https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2Fethrig%2FyruZQUYK8W.png?alt=media&token=b6eeeb65-d55f-4bba-a3fd-046e69d6444f) - Basically, searchers who have landed lots of bundles onchain relative to their attempts to land bundles on chain, will be part of the high priority queue (+coinbase...) ### Bundle merging - Since v0.2 bundle merging is possible, allowing multiple bundles to be included in a block - The merging is done at the MEV-geth level ![](https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2Fethrig%2FMbN-3WFcRs.png?alt=media&token=97bb91b6-d800-482e-8427-91f5f4d69898) - In short: start with most profitable bundle, try adding more bundles (check they don't revert in combination with previous bundles). Repeat. ### Why use MEV-relay as miner? - Exposing your MEV-geth node's RPC endpoint without having taken the proper security measures opens you up to spam. - We (Flashbots) invest significant engineering resources into spam prevention, rate limiting, bundle simulation and queuing to ensure high reliability for the network. - In the future, Flashbots plans to iterate towards a decentralized approach to solving this problem through improving the design of MEV-relay. - Flashbots is responsible for keeping the uptime guarantee for the MEV searcher network. - Exposing endpoints directly will make your infrastructure susceptible to attack vectors such as DDoS and may put the entire Flashbots network at risk and breaks our obligations to the searchers, which may reduce the MEV revenue on the Flashbots network. ## Roadmap: MEV-SGX - Problem - ![](https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2Fethrig%2FMEzY0vAbRP.png?alt=media&token=05368fe6-bf08-4f87-b75d-4be6e3a1e853) - How to make Flashbots network permissionless and guarantee complete privacy? - Current proposal: To leverage secure enclaves, like Intel’s SGX or AMD’s SEV - Searchers would use an enclave to validate that their bundles are valid and profitable, thus mitigating DOS and enabling permissionless interactions between searchers and miners. - Miners would use an enclave to store encrypted blocks from searchers, and receive truncated header hashes they can use to perform proof-of-work. The miner’s enclave would unencrypt and seal the searcher’s block when provided a proof-of-work solution. - A drawback of this solution is that the searcher’s privacy guarantees are only as strong as the security of the miner’s enclave and it would be difficult for the searcher to determine if the miner has broken the enclave. - Furthermore, using enclaves may introduce latency into the system that make it infeasible to use. ## Some sources: - https://docs.flashbots.net/ - https://hackmd.io/@flashbots/core-v2-proposal - https://ethresear.ch/t/flashbots-frontrunning-the-mev-crisis/8251 - https://ethresear.ch/t/mev-sgx-a-sealed-bid-mev-auction-design/9677
Last changed by  
 
Caspar Robust Incentives Group @ Ethereum Foundation
1293

Read more

Ethereum resources

I put together a list of resources that I found helpful to dive into ethereum research. Most of the resources are actually sourced from yet another list by the fantastic Ben Edgington and can be found here. Once you're done here I'd recommend to head over there and find topics that you want to dive into further. Fundamental Papers At the end of the day there is no way around these two papers, they are the foundation of everything eth2. You may or may not prefer to read the high-level explainers first. Original Casper FFG paper by Vitalik Buterin and Virgil Griffith Combining GHOST and Casper paper by Vitalik Buterin, Danny Ryan, et al. High-level Explainers My favourite blog posts on Casper FFG and the beacon chain out there, definitely worth a read.

12/13/2022
Proposer Boost considerations

Joint document by Francesco and Caspar. We need to pick a proposer LMD score boost value, $W_{PB}$. Currently $W_{PB}$ is defined in the specs as PROPOSER_SCORE_BOOST: 70. General opinion is that this value is too high. On the one hand, you want the proposer boost to not be too high: The reason is that a high proposer boost enables an adversary to abuse it and do ex post reorgs or sandwich ex ante reorgs. Consider the following sandwich scenario: A 10%-adversary proposing block n and n+2 can reorg block n+1 despite the proposer boost, or in fact because of the proposer boost: 10% (adv. slot n votes) + 10% (adv. slot n+2 votes) + 70% ($W_{PB}$) = 90%, which is equal to honest weight voting for block n+1 (assuming all honest validators vote correctly etc.) On the other hand, you want proposer boost to be high enough to prevent "simple" ex ante reorgs and balancing attacks. So what is the right middle ground? Let's consider the trade off space.

9/21/2022
(Un-) Timeliness in PoS Ethereum

Special thanks to Barnabé and Francesco for discussion and input. Background info A slot is 12 seconds long. The proposer is supposed to release their block at the beginning of it. The spec forsees the following schedule within a slot for an honest validator that is selected to attest: A validator should create and broadcast the attestation to the associated attestation subnet when either (a) the validator has received a valid block from the expected block proposer for the assigned slot or (b) 1 / 3 of the slot has transpired (4s into the slot) -- whichever comes first. Further,

5/12/2022
Mitigation of ex ante reorgs

As discussed here and more formally here, the current specifications of Proof-of-Stake Ethereum allow for reorgs to happen relatively easily. A mitigation must be found before The Merge. There are several and open/closed PRs (#1, #2, #3, ...) floating around, but nothing definite yet. This note tries to keep track of various different ideas to mitigate these ex ante reorgs and also why some ideas have been discarded already. Idea 1 - (block, slot)-voting What is (block, slot)-voting? The core idea of (block, slot)-voting is to have honest committee members attest to an empty slot, if they do not see a timely proposal. Currently attestor would attest to the latest block as current head of the chain. It is specified here and described by Vitalik here. At its core this would allow validators to vote for empty slots (if they don't hear a proposal). Why would it help mitigate reorgs? This would prevent reorgs from working (or at least being practically feasible), because the adversary's blocks would not inherit the weight of honest attestations. They would instead accrue to the empty slot, which is in competition with the adversary's privately kept block. Hence, the adversary would compete with all honest committee members.

10/14/2021
Read more from Caspar
Published on HackMD