PROF: Fair Transaction-Ordering in a Profit-Seeking World
by Kushal Babel, Yan Ji, Ari Juels, and Mahimna Kelkar
26 April 2023
v1.2
In today’s blockchain landscape, the life of a transaction is nasty, brutish, and short. Or, as some put it, a blockchain like Ethereum is a “dark forest” — a reference to a popular sci-fi novel in which the universe is filled with predatory civilizations.
Most users’ transactions run the gauntlet through an infrastructure involving what are called MEV auctions (we explain MEV and MEV auctions below). This infrastructure enables arbitrageurs to modify the order in which transactions appear in blocks. Arbitrageurs can use this power to extract profit for themselves — much or most of it from users’ pockets. By creating competition among arbitrageurs, MEV auctions maximize MEV extraction — and MEV’s detrimental impact on users.
It doesn’t have to be this way. In this post, we propose a remedy called protected order flow (PROF). PROF is a way to sequence transactions fairly and yet ensure their uptake by profit-maximizing, a.k.a. greedy, block validators.
“Fairly” here can mean whatever you like: decentralized first-come, first-serve ordering, blind ordering, payment schemes for priority placement, a blend of approaches like this or this, or something altogether different. The point is that PROF supports a policy for ordering transactions that doesn’t involve intentional extraction of MEV. Despite this, PROF works in a way such that rational validators, i.e., those seeking purely to maximize their profits, will keep PROF transaction orderings intact.
The idea behind PROF is simple. A PROF Sequencer ingests private transaction flow, i.e., transactions sent exclusively to it and not to the public mempool or elsewhere. The PROF Sequencer orders transactions according to a predetermined, transparent policy. The result is an ordered set of transactions generally known as a bundle. Skipping over details for the moment, PROF offers the bundle to validators on the following condition:
A validator may only include a PROF bundle if the bundle is left intact, i.e., there is no tampering with its transaction ordering.
Mechanically, this condition is enforced by requiring the validator to commit to a block containing the PROF bundle — sign the block — before learning the transactions in the PROF bundle.¹ In this way, a validator can’t observe, copy, and reorder PROF-sequenced transactions. For reasons we explain below, we favor a variant in which PROF enforces bundle placement at the end of a block, i.e., appending to a builder’s block.
At the end of the day, PROF gives a validator a choice: Take the bundle as is, or don’t take it at all. Suppose a bundle contains payment to the validator and the validator’s current block isn’t otherwise full. Then a validator, if rational — i.e., profit-seeking or greedy — is always better off taking the PROF bundle.
PROF in essence creates a private mempool in which transactions are protected from MEV auctions. It offers end-to-end protected sequencing, meaning a guarantee that transactions submitted to a PROF Sequencer can only be processed according to an PROF Sequencer’s policy. In this way, it enables transactions to bypass exposure to MEV extraction.
The approach of forcing a validator to commit to a block before seeing it is already broadly adopted in today’s infrastructure (through a system called MEV-Boost, although it aims to maximize MEV-Extraction). More generally, PROF is related to ideas such as Flashbots Protect and order-flow auctions (OFAs) (discussed below). It doesn’t require any fundamentally new ideas or systems-building. The PROF Sequencer can present an interface and use tools similar to that of MEV-Boost. As we explain below, the main change to existing MEV infrastructure would be a supplemental PROF Bundle-Merger run by relayers, the entities that offer blocks to validators. No change is necessary elsewhere in MEV infrastructure or to the wallets of users that want to benefit from PROF.²
PROF is best implemented using a trusted execution environment (TEE), such as Intel SGX.³ A TEE can help ensure both transaction privacy and correct implementation of a predetermined ordering policy by the PROF Sequencer and correct behavior and execution integrity in the PROF Bundle-Merger when it’s run by a relayer. Conveniently, MEV infrastructure is already on a path toward TEE adoption. For example, the SUAVE system proposed by Flashbots, the largest provider of MEV-extraction infrastructure, is meant to use a TEE. Flashbots has released a block-builder that runs in a TEE. The details of SUAVE are still forthcoming, and the system aims to be quite flexible, so it’s possible that SUAVE itself could support PROF. We hope it will.
PROF is so simple, however, that it can be implemented well before SUAVE is likely to materialize. After giving a primer on MEV and explaining the fundamental challenge in enforcing fair transaction-ordering, we’ll explain how PROF can be deployed today.
An MEV primer
Miner / Maximal Extractable Value (MEV), a term coined in this 2019 / 2020 paper, denotes value obtained through deliberate manipulation of transaction order in blocks. Arbitrageurs today use proprietary, often sophisticated strategies to extract MEV from public and private transaction flows. The most common, basic strategy is a sandwich attack.
Suppose an arbitrageur observes a transaction T from Alice placing a buy order for Bob’s Bubble Token (BBT) on a decentralized exchange (DEX) such as Uniswap. The arbitrageur can sequence its own transaction Tᵇᵉᶠᵒʳᵉ before Alice’s transaction T and another transaction Tᵃᶠᵗᵉʳafter T. The transaction Tᵇᵉᶠᵒʳᵉ buys, say, 1000 BBT, while Tᵃᶠᵗᵉʳ sells those 1000 BBT. These two transactions are the bread in the sandwich. Alice’s is the meat.
The three transactions execute as follows. The arbitrageur first accumulates 1000 BBT in Tᵇᵉᶠᵒʳᵉ. Alice’s buy transaction T then causes the BBT price to rise. Finally, the arbitrageur sells its BBT Tᵃᶠᵗᵉʳ in at a profit. If Alice has caused the price to rise by, say, $0.05, then the arbitrageur earns a gross profit of 1000 X 0.05 = $50.00.
Where does this profit come from? From Alice. Tᵇᵉᶠᵒʳᵉ causes the price of BBT to rise, bumping up the price Alice has to pay for BBT.
MEV extraction today
Arbitrageurs today operate within a multi-stage, multi-entity infrastructure (“supply chain”) designed specifically to optimize and streamline MEV extraction.
Briefly, an arbitrageur implements an MEV-extraction strategy by ordering transactions it has obtained from the public mempool or from private order flow. The ordered transactions form what’s called a bundle.
The arbitrageur sends its bundle to a block-builder (or just “builder”), which assembles a collection of bundles from different arbitrageurs into a complete block. The builder submits its block to a relayer. The relayer receives blocks from a number of competing builders. It selects the block B* with the highest payment to the current validator, i.e., the one that gets to add the next block to the blockchain. That is, it conducts an implicit MEV auction. The builder sends B* to the validator for inclusion on the blockchain. Implicit in this selection among blocks is an MEV auction: The more MEV extracted from a block by arbitrageurs, the higher the payment that trickles up to the validator.
To prevent a validator from observing the ordering of transactions in B* and duplicating or otherwise exploiting them — essentially stealing from arbitrageurs⁴ — a relayer uses the trick we described above. It requires a validator to sign B* (specifically, its header) before revealing the transactions in B*.
This general structure is referred to as proposer-builder separation (PBS). (Validators are “proposers” in this terminology.) PBS is today deployed in the form of MEV-Boost, the infrastructure mentioned above. There are plans to integrate relayers natively into Ethereum.
The builders and relayers in PBS need to be trusted by other entities in the system not to abuse their knowledge of transactions. The goal of incorporating TEEs into PBS is to reduce the need for this trust.⁵
The fair-ordering challenge
Researchers and developers have proposed a multiplicity of approaches to ordering transactions fairly, as enumerated above. Why don’t builders use them?
The reason that PBS as realized today, with MEV auctions, is designed to maximize MEV extraction.
Given a choice between a block B that offers a smaller reward and a block B’ that offers a larger one, a rational validator will always choose B’. Among all the blocks it receives, therefore, a relayer only offers to a validator the one that pays the validator the highest reward. A validator connected to multiple relays will accept the highest-reward block from among them.
How does a block B’ come to include a higher validator reward than B? The validator reward typically comes from extracted MEV. A builder can therefore employ two approaches to boosting rewards for validators in its blocks: (1) Extract more MEV than other builders by including bundles from the best arbitrageurs and (2) Offer the nearly all extracted MEV to the validator — today, typically 90%+ .⁶
Suppose a builder constructs a block B fairly, i.e., in any way that doesn’t maximize MEV extraction. Then won’t adopt approach (1) above, so its block won’t offer a competitive reward and won’t be taken up by a validator. It would seem as though, in a world of profit-seeking validators, fair ordering doesn’t stand a chance.
The key insight in PROF is this: By sequencing only private order flow and isolating it from arbitrageurs in a PROF bundle, it’s possible to sidestep the competitive dynamics of MEV auctions. A PROF bundle is attractive as an addition to a block with a high reward for a validator. Given only PBS infrastructure, only sophisticated arbitrageurs can create bundles that will find their way into successfully validated blocks. In contrast, PROF allows anyone with a private mempool to create successful bundles.
PROF architecture
Figure 1: PROF architecture
The PROF architecture, shown in Figure 1 above, introduces two new software modules into the MEV supply chain: a PROF Sequencer and a PROF Bundle-Merger.⁷ A PROF Sequencer receives transactions from users and orders them into a PROF bundle according to a published policy, i.e., one made transparent to users. This policy, as noted above, may achieve some notion of fairness. Ideally, the PROF Sequencer executes in a TEE. The TEE can ingest encrypted transactions and keep them confidential. (Shading shows the confidentiality of the PROF bundle from the relayer and validator.) It can also demonstrate adherence to the published policy by means of attestation, a capability of certain TEEs (such as Intel SGX) that allows third parties to verify that the TEE is running a particular application.
A PROF bundle is forwarded from a PROF Sequencer to a PROF Bundle-Merger hosted by a relayer (or multiple PROF Bundle-Mergers hosted by multiple relayers). A PROF Bundle-Merger merges the PROF bundle with a winning block from the MEV auction performed in the relayer. The transaction fees paid by the users in the PROF bundle (specifically, tips in Ethereum) go to the validator. As a technical detail, note that builders today usually set their own address as the coinbase, which receives the transaction fees instead of the validator (although they are not required to do so under the MEV-Boost architecture). Given this situation, the PROF Bundle-Merger may have to collect transaction fees from users (again, tips) by setting its own address as the coinbase and add an explicit transaction that appropriately pays the winning builder and validator. Alternatively, for those builders that switch back to the traditional notion of setting coinbase to the validator’s address, PROF users’ fees can be seamlessly credited to the validator.
As in current practice, PROF Bundle-Merger reveals the merged block once it receives a signed commitment from the validator, i.e., a signature on the block header. The PROF Bundle-Merger too is run inside a TEE to ensure the confidentiality of the PROF bundle and — again by means of attestation — to ensure the integrity of the merging process. PROF Sequencers can be hosted by any entity, but PROF Bundle-Mergers should be hosted by relayers for two reasons: (1) the relayer (and as a result, the validator) does not need to rely on another party to ensure the availability of the PROF Bundle-Merger, e.g., in cases of network failures, etc. and (2) this approach may be necessary to ensure that relayers are willing to entrust their blocks to PROF Bundle-Mergers, in part because of (1), but also because the vulnerability of TEEs to side-channel attacks would mean potential leakage of those blocks if PROF Bundle-Mergers are hosted elsewhere.⁸
The merging of a PROF bundle with a relayer block can happen in a variety of ways. One simple way, as shown in Figure 1, is to simply take the winning block from the MEV auction and append the PROF bundle to it. (Although transactions shouldn’t be duplicated across the block and bundle, any duplicate transactions can be removed from the PROF bundle.) In contrast to other merging rules like prepending the PROF bundle to the block, or inserting it somewhere in the middle, appending allows relayers to conduct their MEV auctions outside the PROF Bundle-Merger TEE, as they do today, and thus doesn’t alter existing infrastructure.
While our PROF architecture fits well in the current landscape of MEV extraction, it can be supported by the future developments in this landscape. For instance, SUAVE claims to allow for expression of “preferences” by users. If a user can express a preference for transaction inclusion in a PROF bundle, that would directly support PROF. The PROF architecture can also be extended to allow for multiple, independent PROF instances, which would be helpful in enforcing decentralization.⁹ Finally, we’re exploring the potential of combining PROF with an architecture that bloXroute is devising. That architecture enables validators to profit by providing real-time trading services and will be detailed in a future bloXroute blog post.
Alternative architecture: It is also possible to deploy PROF with a builder, provided that the builder uses relays that do not peek at the block. One such relaying mechanism is called optimistic relaying. Optimistic relaying eliminates block-checking by relayers, reducing latency between building and validation — a desirable feature in the latency sensitive MEV supply chain. (Optimistic relaying uses, e.g., slashable deposits from builders to enforce their submission of valid blocks and release of block contents.) Since the relayer doesn’t check blocks, it need not have access to the payload of a block until a validator signs a block header. Thus it would be possible for a PROF Bundle-Merger in this case to release a block header from the builder for transmission through a relayer to validators.¹⁰ PROF would then benefit from the latency reduction brought about by optimistic relaying.
At this point, optimistic relaying is supported by some relayers (e.g., the Ultra Sound Relay), but hasn’t yet emerged as a universal approach. This is the reason for our emphasis on relayers, in addition to the fact that deployment with a single relayer enables PROF service for all builders interacting with the relay. That said, it’s also possible to deploy PROF in a hybrid mode, i.e., with builders, where optimistic relaying is supported, and otherwise with relayers.
Incentives
PROF offers additive benefits to all players in the MEV supply chain. A player profits more from including a PROF bundle than not. The result is a compelling business model for PROF with low-cost protection for end users.
In the architecture we have described above, validators’ revenue increases from any tips paid by the PROF transactions (over and above the base gas fees). The view for builders remains unchanged.
The PROF architecture is flexible enough, however, so that the PROF Bundle-Merger can in fact redirect fees from the PROF bundle to the builders in a flexible fashion. For instance, in order to bootstrap the network for a new relayer implementing PROF, the Bundle-Merger can pay part of the fees from PROF bundle to the builders and the rest to the validators, thereby increasing the revenue of both the builders and validators when a PROF bundle is included.
In this case, because of PROF’s additive benefits, a rational builder or validator will favor inclusion of a given PROF bundle even if the result is only a tiny payment. Better to earn an extra penny than not!
Because PROF payments can be small, a PROF Sequencer can charge a user minimally for inclusion of a transaction, e.g., a few cents, and operate profitably. A simple business model results for would-be PROF operators: (1) Offer protected, low-commission processing of transactions and (2) Attract exclusive order flow because of (1). Our hope is that eventually, most or all order flow eventually finds its way to PROF-based systems and that competition among PROF sequencers will drive down user fees.
Note that the dynamic fee mechanism in EIP-1559 has the effect that blocks are rarely too full to include PROF bundles. When they are too full, EIP-1559 helps ensure that block space becomes available in a short period of time.
Related Ideas
Similar in spirit to PROF, Flashbots Protect is a product which offers frontrunning protection to users. However, it relies on Flashbots’ unique position in the MEV supply chain and does not offer transparency of execution. It also imposes a delay on validation, as it only enables transaction validation in Flashbots-generated blocks. PROF on the other hand, can be run by any relayer and offers transparency as well as flexibility of the policies around protected order flow.
PROF is a dark pool of sorts, of which examples in TEEs have already been explored. PROF may be viewed as a way of organizing dark pools and integrating them into the MEV supply chain.
Also similar is the concept of order-flow auctions (OFA), in which users’ transactions are auctioned off for validation rights. The result is an MEV refund for users. OFA is perhaps better for users, but still has some drawbacks. Among these are the trust models they embody, which are often centralized and may involve the auctioneer exposing users’ transactions to a network of searchers (e.g., arbitrage bots). Additionally OFA may still result in poor execution for users — in large part because of trust model issues. OFA often involves only partial exposure of transactions to prevent abuse of users’ transactions, with an accompanying degradation in the accuracy of the system’s valuation of a transaction. Finally, OFA results in increased latency for users, as well as considerable system-design complexity.
Conclusion
There is a folklore idea that in a world of rational, i.e., profit-seeking validators, maximal MEV extraction is inevitable. When all transactions are sent to a public mempool and thus exposed to exploitation, this notion may be true. But as some have eloquently argued, rampant MEV exploitation isn’t fundamental or inevitable. We agree, and hope that PROF illuminates a bright path through the dark forest to fairness and safety.
Acknowledgements
Thanks to Sarah Allen, Lorenz Breidenbach, Davide Crapis, Chris Hager, Uri Klarman, Julian Ma, Dahlia Malkhi, P. McGoohan, Barnabé Monnot, Pawel Szalachowski, and Kosala Yapa for valuable comments and questions about PROF. Thanks to the Flashbots team for informative discussions about the MEV supply chain and the evolution of SUAVE.
¹ In a proof-of-stake (PoS) system, validators can’t commit to more than one block without risk of “slashing” — a financial penalty.
² Users just need to configure their wallets to use the PROF RPC.
³ TEEs — Intel SGX in particular — have exhibited a number of vulnerabilities, mainly side-channel attacks, e.g., Spectre, Meltdown, Foreshadow, and AEPIC, but also deployment mistakes, like those uncovered by the sgx.fail team in Secret Network. As the MEV industry already seems to be on a path to adopting TEEs, we punt on this issue in this blog post. We’ll be addressing it in a blog post slated for release in the near future.
⁴ An attack that has already happened.
⁵ TEEs have exhibited a series of serious vulnerabilities. We’ll discuss ways to address the problem in an upcoming blog post.
⁶ To confirm this figure, which is anecdotal, we computed validator profit on a single day (24 March 2023) according to https://explore.flashbots.net/leaderboard. On that day, about 94.7% of extracted MEV was paid to validators.
⁷ This figure assumes that the relayer is trusted by builders not to abuse knowledge of their blocks. Plans for MEV supply chain evolution by Flashbots et al. include use of TEEs to minimize such trust assumptions. While the relayer is a trusted entity in the current MEV supply chain, it may not be appropriate to regard it as such for PROF bundles, because they reduce MEV made available to players in the supply chain and hence might be treated adversarially.
⁸ The relayer and validator can collude to leak the PROF Bundle by having the validator sign a block header and then discarding the signature. The PROF Bundle can then be broken, front-run, etc. This type of attack can be detected by the operator of the PROF sequencer by having the PROF Bundle-Merger send the hash of an ingested builder’s block B to the PROF service with confirmed receipt before outputting the header of the block it’s constructing (exclusively on B). The PROF service can then detect leakage of a PROF bundle if its transactions appear in a block other than B, and can then, e.g., terminate a validator’s PROF access. (This approach also has the benefit of increasing resistance to side-channel attacks: The PROF Bundle-Merger can process the PROF bundle only after sending B to the PROF service.)
⁹ For example, a system of endorsements could support co-existing PROF instances. if PROF instance A endorses PROF instance B, then either instance will allow its bundle to be sequenced just before that of the other instance.
¹⁰ A mechanism like that in footnote 8 is needed to limit builder instances to legitimate entities in order to prevent brute force probing attacks that involve building test blocks and then inspecting and throwing away headers.
Editor: Bria Han (IC3, jh2584@cornell.edu)
Stay ahead of the curve with the latest IC3 research! Subscribe now to our mailing list!
