Before deep-diving into the technical inner-workings of Flashbots, we first need to understand the general Ethereum transaction system and the flaws that exist within it. During a high profile NFT drop, say you are attempting to mint an NFT through the website of a new and upcoming project. The process would be as follows:
1. You call the minting function of a smart contract which creates a transaction that is placed into the public transaction mempool while pending.
2. Assuming EIP-1559, your pending transaction is prioritized based on your provided max priority fee and max fee.
From this point, your transaction can go one of two ways.
3. Your max fee is high enough to accommodate for a surge in network traffic.
a. This protects you from the rapid increase of the base max fee, keeping your transaction valuable, and your max priority fee has incentivized miners enough to include your transaction in the next available block.
4. Your max fee fails to stay above the baseline of the networks max fee.
a. Your transaction has lost value to miners and runs the risk of either becoming stuck, failing, or being dropped altogether.
In the event of a successful transaction, you exchange your hard-earned Ether for an NFT (ERC-721/ERC-1155) and are refunded the difference between your mentioned max fee minus the networks calculated base max fee + max priority fee. This concept can be explained in greater detail in article found here.
Understanding this system helps us to identify potential issues within the general Ethereum transaction process and understand ways in which it can be leveraged for one’s personal gain. These are:
1. The transparent nature of the public mempool enables the ability for malicious actors to front-run transactions by simply duplicating them with a higher max priority fee and max fee to ensure that their transactions have a greater chance of being processed before yours.
2. Dependence on the gas price (max fee) makes it difficult for bidders to express granular order preference. i.e. Determining which transactions should be processed in what order.
3. The all-pay nature of auctions (in the sense that users are essentially bidding to have their transactions processed first) causes failed bids to revert on chain, which consumes unnecessary block space and results in bidders under-pricing their bids due to execution risk.
Flashbots works towards mitigating these issues and uses an interesting architecture to do so. The Flashbots architecture consists of three main components, these are:
1. Searchers — Users who monitor the state of the chain and are responsible for sending transaction bundles to relayers.
2. Relayers — A bundle propagation service which receives bundles from searchers, validates them, and then forwards them to miners.
3. Miners — The party responsible for accepting bundles to then process and produce a block.
The role of a searcher is to ultimately condense either a single transaction or multiple transactions into a specific order known as a transaction bundle. Searchers send bundles to a Flashbots relayer (ideally) and achieve pre-trade privacy by doing so. This ensures that the bundled transactions are never publicly broadcasted into the public transaction mempool where malicious actors have the capability to front-run a user’s transactions. Searchers also have the opportunity to “bribe” miners through either a set gas price or a direct ETH transfer to the miners coinbase address. Bribes ultimately negate any transaction fees as this is a conditional that is only paid if the bundled transactions are successfully processed.
Once the bundled transaction has been sent from the searcher to the Flasbots relay, the relayer is in charge of validating and routing Flashbot bundles to miners. Relayers may also provide additional services such as bundle merging and execution services which allows searchers to specialize in the type of transactions they wish to bundle. It is important to use trusted relayers as they have the capability to view the inners of a transaction bundle. When a transaction bundled has been validated, the bundle is then forwarded to a miner.
Assuming that an appropriate bribe has been provided and the transaction bundle is deemed valuable, the miner will then attempt to mine the transactions into the next available block. As the traditional geth client typically orders transactions by gas price, all Flashbot miners run a modified mev-geth client which is maintained by Flashbots themselves.
There we have it! Asimple look into the innerworkings of Flashbots and my attempt into understanding it.
Sources:
