Flashback: Enhancing Proposer-Builder Design with Future-Block Auctions in Proof-of-Stake Ethereum (2025)

2.1 Ethereum

Ethereum[12] is a decentralized, public blockchain platform that is currently the second-largest after Bitcoin[33].

Proof-of-Stake (PoS).Ethereum has switched to Proof-of-Stake (PoS) since September 15, 2022 from its previous consensus mechanism, Proof-of-Work (PoW)[1].In PoS Ethereum, time is organized into epochscomprising 32 slots.Each slot has one block proposer.At the onset of each epoch, proposers are assigned for all 32 slots in the epoch through shuffling.A key reason for assigning proposers in advance is that an advance notificationfacilitates proposers in participating in the correct peer-to-peer network subnets and enables them to prepare for assigned tasks, such as attestation.However, this necessity for advance notification also poses a potential security challenge, as it compromises the inherent unpredictability that is vital to Ethereum’s consensus mechanism[16].

2.2 MEV, Builders, and Proposers

MEV.Maximal extractable value (MEV) refers to the profits unfairly gained by attackers by executing transaction reordering attacks[14].Token swaps, arbitrage and loan liquidations are some examples of transactions from which MEV can be extracted.E.g., in a token swap a user wishes to swap one ERC-20 token $X$ for another token $Y$ at a decentralized exchange for a competitive price.By observing the user’s transaction in the mempool (set of outstanding transactions), an attacker can issue its own transaction purchasing token $Y$ that frontruns the user’s transaction, and later sell those tokens for a profit.Similarly, in an arbitrage a user exploits price difference of an asset at different exchanges and performs a sequence of buy-sell operations to gain a profit.However, an adversary observing the user’s transaction in the mempool can copy the arbitrage and issue its own transaction that frontruns the user’s transaction, thus gaining the profits for itself.It is reported that the monthly MEV collected on lending platforms and decentralized exchanges exceeds $100M[20].

Proposer-builder separation.To mitigate the negative effects of MEV on proposer centralization, Ethereum has favored a proposer-builder separation architecture[19, 39].We explain the pipeline of how transactions are confirmed in Ethereum’s proposer-builder architecture below.

3.1 System Model

User model.We model our system as a game involving 3 types of entities: users, builders and proposers.We do not distinguish between users and searchers in our model.Time is segmented into discrete rounds, with a single block proposed by a designated proposer during each round.We assume there are $n>0$ users.We consider two builders in the system: the primary and secondary builder.The primary builder refers to a builder running Flashback auction, while the secondary builder models today’s builders without future block auction capability.The words primary and secondary are used only for nomenclature and do not indicate any inherent user or validator preference of one builder over the other.

Without loss of generality we assume at each round, an independent proposer publishes the block.Each round, each user generates a private transaction with a probability of $0<q<1$ (randomness independent across users).When a user creates a private transaction, its transaction value is randomly sampled from a distribution $p_{\mathrm{private}}$.This value represents the total fees paid by the user for that specific transaction.

When a user generates a private transaction within a round, it randomly selects one of the two builders for submission.The probability of sending to the primary builder is $S_{\mathrm{primary}}/(S_{\mathrm{primary}}+S_{\mathrm{secondary}})$, while the probability of choosing the secondary builder is $S_{\mathrm{secondary}}/(S_{\mathrm{primary}}+S_{\mathrm{secondary}})$.Here, $S_{\mathrm{primary}}$ and $S_{\mathrm{secondary}}$ are scores indicating the performance of the primary and secondary builder respectively.The scores reflect various aspects such as the likelihood of a builder getting a block accepted based on past performance.The formal definition of the score function will be provided later.A private transaction is assumed to expire if it remains unincorporated into the blockchain within $\tau>0$ rounds.

Additionally, each round involves the generation of $k$ public transactions, all of which are transmitted to both builders.The value of each generated public transaction is randomly sampled from the distribution $p_{\mathrm{public}}$. Public transactions are considered expired within the same round they are generated.

Builder model.In each time slot, a builder receives private and public transactions from users, as described previously.Additionally, the builder maintains a repository of unexpired transactions that have yet to be confirmed.Alongside this, during each slot, the secondary builder (also referred to as the default builder) selects the most profitable $K$ unconfirmed transactions available to it.Here, we consider $K$ as the block size. Once the secondary builder has compiled a block for round $t$, it sends the block to the proposer assigned to that particular round.Upon successful inclusion of the block, the secondary builder receives a fraction $0<r_{2}<1$ of the total transaction fees contained within the block.The remaining fraction, $1-r_{2}$, is received by the proposer who proposes this particular block.It is important to note that during round $t$, the secondary builder interacts only with the proposer assigned to that round.

In each round, the primary builder, also known as the policy builder, employs a specific policy denoted as $\pi_{\mathrm{build}}$ to construct the block.During round $t$, the primary builder possesses information about identities of all validators from rounds $t$ to $t+c$, where $c>0$ is a positive integer.To advertise blocks and submit bids to proposers, the primary builder adheres to a bidding policy denoted as $\pi_{\mathrm{bid}}$.It is important to note that the fraction of transaction fees retained by the primary builder hinges on the interplay between the building policy $\pi_{\mathrm{build}}$ and the bidding policy $\pi_{\mathrm{bid}}$.

Proposer model.We assume that proposers evaluate bids presented by both the primary and secondary builders.Each proposer’s aim is to accept a block that maximizes its profits.We use the words proposer and validator interchangeably.

Reward model.Users adhere to the policy described above, and thus, we do not assign any specific rewards to the users.For a builder, its reward is represented by the average fees obtained from the blocks it constructs that are confirmed.Similarly, a proposer’s reward is determined by the amount of fees earned from the blocks it proposes.

In general, the processing delay experienced by a transaction, or its failure status, is not public knowledge and may not be available to all users.However, we assume users share and rate their personal experiences of using different builders on various public forums from which estimates for $F_{d}$ and $F_{m}$ may be derived.

3.2 Problem statement

We aim to design a block building policy $\pi_{\mathrm{build}}$ and a bidding strategy $\pi_{\mathrm{bid}}$ for the primary builder such that, the total rewards earned by the primary builder surpasses that of the secondary builder at equilibrium.Our objective in this work is to only show the existence of an equilibrium where the primary builder wins (vs. the secondary builder).We leave the problem of determining the optimal building and bidding policies for maximizing the primary builder’s reward for future work.

4.1 Private transaction bidding

Consider round $t$ in the system.Let $Q_{t}$ denote the set of unconfirmed private transactions available to the Flashback builder at time $t$ such that (1) transactions in $Q_{t}$ expire only after time $t+1$, and (2) a transaction in $Q_{t}$ has not been previously auctioned off to proposer $t$.Let $\rho>0$ be an estimate of the average reward expected to be earned by a proposer (we discuss how to compute this estimate in §4.2).For a parameter $k<K$ (recall, $K$ is the block size) let $Q_{t}^{1:k}$ be the set of $k$ transactions in $Q_{t}$ that have the highest transaction fees.The Flashback builder advertises the transaction fees of the transactions in $Q_{t}^{1:k}$ and a parameter $0<r_{1}<1$ to the proposer at time $t+1$ (§4.2 discusses how to choose $r_{1}$).If the $(t+1)$-th proposer accepts the offered transactions, the Flashback builder reserves the transactions in $Q_{t}^{1:k}$ to the proposer.During the next round, $t+1$, the Flashback builder includes the reserved transactions in the block it builds and sends the block to the proposer of that round.While building the block, any remaining space in the block after adding the reserved private transactions is filled up by unconfirmed public transactions.For transactions that have been reserved ahead of time, the proposer at $t+1$ receives a fraction $(1-r_{1})$ of the fees of those transactions;while the Flashback builder receives the remaining $r_{1}$ fraction of the fees.For the public transactions, or for private transactions that have not been previously reserved by the $(t+1)$-th proposer, a fraction $r_{2}$ of the fees is received by the proposer while the builder receives the remaining $(1-r_{2})$ fraction.If the $(t+1)$-th proposer accepts the Flashback builder’s bid at time $t$, the $(t+1)$-th proposer commits to publishing the Flashback builder’s block at time $t+1$.This is the main advantage of offering transactions to the future proposer—if the $(t+1)$-th proposer has committed to receiving a Flashback block at time $t$, then during time $t+1$ even if the secondary builder’s block is more profitable the proposer must accept only the Flashback block.In exchange for reducing risk (of receiving a poor payout in the future) at proposer $t+1$, the Flashback builder gains an upfront commitment from the proposer to accepting a Flashback block.If any party deviates from protocol violating the other party’s trust, the affected party can choose to stop interacting with the deviant party in the subsequent rounds.

During time $t$, if the $(t+1)$-th proposer is rational, it accepts the offered transactions from the Flashback builder as long as the profits earned from the transactions exceed (or, significantly exceed) the average profit expected by the proposer.Otherwise, the proposer rejects the bid.If the bid is rejected, the Flashback builder can still advertise a block to the proposer in the next round $(t+1)$.To do this, the Flashback builder resorts to the default block-building policy in which it compiles the $K$ highest value (unreserved, unexpired) private and public transactions known to it and forms a block.All transactions in this block are offered at the default rate of $r_{2}$ (i.e., proposer receives fraction $(1-r_{2})$ of reward).Figure2 illustrates a timeline depicting the actions of the primary builder and proposers.

The $(t+1)$-th proposer is likely to accept the bid if the threshold $\rho$ is chosen large enough.We discuss how to choose $\rho$ next.

4.2 Threshold $\rho$ and rate $r_{1}$

5.1 Validator and Builder Rewards

The expected rewards earned by the primary builder is given in AppendixC.

5.2 Equilibrium Analysis

For a validator to follow our proposed policy and not deviate back to the default policy, we must have $\mathbf{E}[V_{p}^{\mathrm{policy}}[t]]>\mathbf{E}[V_{p}^{\mathrm{default}}[t]]$.The following proposition shows a sufficient condition for this.

(Proof in AppendixE)

(Proof in AppendixF)

Next, we show there exists a $\mu_{2}<1/2$ where $\mathbf{E}[V_{\mathrm{primary}}[t]]\mu_{2}-\mathbf{E}[V_{\mathrm{secondary}}[t$ is positive for sufficiently large $\rho$.

(Proof in AppendixG)

Combining Lemma5.1 and Theorem5.3 we conclude there exists a $\rho<\infty$ and $r_{1}=0$ where the primary builder and validators are at equilibrium and do not have an incentive to deviate from protocol.An $r_{1}$ value of $0$ means the primary builder does not earn any reward from private transactions bid to future proposers.Despite this, the analysis above shows that the overall rewards earned by the primary builder exceed that of the secondary builder.By bidding high-value transactions at a discounted rate to (future) proposers and obtaining upfront commitments, we increase the chance of proposers publishing blocks built by the primary builder.This in turn has the effect of increasing the score of the primary builder, and consequently attracts more high-value private attractions to be sent to the primary builder.While some of the private transactions are reserved for future proposers, the ones that are not reserved earn a reward at a rate of $r_{2}$ for the primary builder resulting in a net-positive effect for the builder.The analysis highlights the complex interplay between various factors affecting total rewards earned, and shows how policies can be counter-intuitive yet beneficial.

6.1 Experiment Setup

To align our simulation on Flashback with real-world data distribution, we compiled a dataset comprising 10,000 blocks spanning from block number 15,570,981 to 15,580,985. These blocks collectively contain 157,946 transactions. Our dataset consists of a 7-part set for each transaction, including details such as transaction hash, sender and receiver addresses, direct payment fee, transaction fee, gas price, and gas used.Additionally, for each block, we generated a 3-part dataset comprising the block number, the list of transactions within the block, and the base fee. These data points were meticulously extracted from a credible source—specifically, Etherscan[17]. Transactions within each block represent successfully mined transactions, accompanied by their unique hash and index within the block.To distinctly identify private and public transactions, we carefully considered 2,740 instances of private transactions, constituting 1.73% of the overall transaction count. This differentiation was achieved through cross-referencing another reputable source, Zeromev[35].

Figure3 illustrates the fee distributions among blocks in the dataset, which fits well to an exponential distribution with around 3% being private transactions among all the transaction and around 10% of the profits come from direct payments, constituting a proportion of all profits derived from both direct payments and transaction fees.Although private transactions represent only 3% of the total transaction volume, they contribute to over 10% of the overall profits.This observation suggests that private transactions tend to yield higher profitability compared to public transactions.

Flashback provides the primary builder with two actions.The first action involves sending bid messages to the proposer in the subsequent round if the primary builder identifies that the current private transactions meet a high standard of quality, denoted as $\rho$.Initially, we conduct experiments without placing bids and record the distribution of private transaction fees.Subsequently, based on the bidding strategy for private transactions, we estimate the fees using recorded data.During this process, we document the distribution of private transaction values for proposers who do not accept bids.The bid rate $r_{1}$ is determined by the threshold $\rho$ in such a way that for bids valued at $\rho$, the proposer can still attain profits higher than their expectations.

At the user’s end, we employ a scoring function model to evaluate builders based on historical performance.Builders with higher scores are preferred by users, increasing the likelihood to be chosen.However, we acknowledge that some users might not be as sensitive to scores and could select poorly performing builders despite their scores.In the initial phase of the experiment, users possess an initial score for the builders, which influences their selection in the first round.We’ve set the initial knowledge length to 1 for easy overwriting.In Section6.2.2, we extend the duration of initial knowledge, setting to 200 rounds.

Private transactions hold time sensitivity, as users anticipate prompt processing. Hence, we introduce a Time-to-Live (TTL) parameter for all private transactions. These transactions are set to expire if they remain in the private pool for TTL rounds.Builders can retain private transactions for a maximum of TTL rounds, providing them an incentive to process these transactions promptly to extract transaction fees.The average waiting time plays a pivotal role in how users assess builders. Users tend to favor builders capable of processing their transactions promptly or, at the very least, preventing their private transactions from expiring.Initially, we’ve set TTL to 10 rounds. Later in Section6.2.3, we will explore varying TTL to analyze its impact on the game.

The processing delay and missing rate of transactions remain private, as these transactions are sent through private channels.We make an assumption that users can share their experiences with these builders and assess their performance based on community reviews.These experiences are publicly accessible within the community, allowing users to factor them into their scoring process.For example, in a block containing 100 transactions, if 10% of users are willing to provide feedback, they can broadcast their waiting times or whether their transactions became outdated to the community.

6.2 Experiment Result

We first conduct the simulations as in Figure4(a), where the primary builder is allowed to bid their top 3 most valuable private transactions to the proposer in the subsequent round. Additionally, all transactions have a TTL of 10 rounds, after which they expire.The builder’s design and policy strategy are outlined in Section4.We execute the experiments over 10,000 rounds, observing the network state convergence at approximately 1000 rounds.

In Figure4(a), we present the builder’s block ratio and reward distributions for builder, user and proposer.In the first subfigure, we illustrate the block ratio attributed to the primary builder and the secondary builder. After 500 rounds, the primary builder gains an advantage, with approximately 55% of the blocks attributed to them, while the secondary builder holds 45% of the blocks.The second subfigure depicts the builder’s reward distribution according to the score function.As builders receive fixed-rate rewards for packaging blocks, their rewards are closely correlated with the percentile of blocks they construct.Notably, the primary builder’s rewards surpass those of the secondary builder by 20%, , calculated as 55% compared to 45%.The third subplot plots the CDF of users’ rewards.Primary builder gets $r_{1}$ through $\pi_{\mathrm{build}}$.Around 40% of the users who send their private transactions to the primary builder get part of the cost back.Conversely, the secondary builder adheres to the default strategy where users cover all transaction fees and direct payments, resulting in a constant curve at 0 (orange curve).The forth subplot plots the CDF of proposers’ rewards, proposer who select primary builder’s block gets a greater rewards distribution.In conclusion, all the primary builders, user and proposers all experience enhanced rewards through $\pi_{\mathrm{build}}$.The state of convergence after 1000 rounds demonstrates a more favorable equilibrium among these three players.

Figure4(b) illustrates the reward distributions for the primary builder, influenced by 3 simple bidding acceptance policies adopted by the target proposers.When the proposer prioritizes offers with greater rewards, which is applied in Flashback, the primary builder stands to receive increased rewards.In cases where the proposer accepts bids randomly, such as with a probability of 50%, the proposer’s rewards tend to approach the 50% mark.When employing a bidding acceptance policy that involves randomness based on reward comparisons, the primary builder’s rewards fall between the two aforementioned scenarios.

6.2.1 Initial state

The aforementioned experiment initializes equal scores for both builders, where users initially lack preferences and treat the builders impartially.Currently, Flashbot contributes approximately 70% of blocks on the Ethereum network, indicating significant user attraction to their services.We also explore a scenario of challenging initiation, where we introduce a primary builder to the existing network.Initially, users exhibit a strong preference for the established secondary builder, resulting in the primary builder having a substantially lower initial score in comparison.We proceed with experiments involving primary builder scores set at 1, 1/2, 1/4, 1/8, and 1/16 times the initial score of the secondary builder.The length of the score period spans 200 rounds, ensuring the initial score’s lasting influence over an extended duration.

In Figure5(a), We observed that primary builders with lower initial preference states take a longer time to reach the convergence state. Notably, the blue line, representing a primary builder with only 1/16 of the score, has not fully converged even after 10,000 rounds.

In contrast to the aforementioned scenario, we explore another case where a new primary builder experiences a surge in popularity, with users exhibiting significantly greater preference for them.In these experiments, we initiate scenarios with primary builder scores set at 1, 2, 4, 8, and 16 times the initial score of the secondary builder. The results, depicting the percentile of blocks or rewards for both builders, are illustrated in Figure5(b).

Higher initial scores yield higher percentiles, especially in the initial 4000 rounds. However, they eventually converge to around 60%, as the fix point proofed in full paper[7].While the initial state can influence the early rounds, it’s evident that the settings of $\rho$ and $r_{1}$ ultimately guide the system towards a comparable convergence state, highlighting the robustness of the observed dynamics.

Setting a substantial difference in initial scores, leading all private transactions to a single builder, prevents the other from updating its performance.These cases might represent additional fixed points, but their realization in reality is challenging.

6.2.2 Different bid strategy

In previous sections, we examine a scenario where all transactions expire after 10 rounds, and the primary builder exclusively bids on the top 3 private transactions.In this section, we delve into various bid strategies, focusing on the number of transactions to bid and the timing of private transaction expiration. These bid strategies have the potential to influence users’ score functions, thereby inducing significant changes in each player’s rewards.We begin by investigating bid strategies that involve bidding on 1, 2, 3, up to 20 private transactions, with the bid threshold being linked to the length of the bid transactions.All other network settings remain consistent with those outlined in Section6.2.

Figure6 presents plots depicting the percentile of blocks built by the primary builder, the total rewards for the primary builder, the average rewards for users, and the average rewards for proposers.A lower bid number simplifies the bidding process, resulting in peaks at $bid_{number}=1$ in the first and second subfigures.The third and fourth subfigures demonstrate that a bid strategy involving around 3 transactions yields the highest rewards for users and proposers, with trade-of between the probability to bid and profits per successful bid.

6.2.3 Different valid time

In the previous experiments, we assume the TTL for private transaction is 10 rounds that private transactions can be kept for at most 10 rounds to be processed.In this section, we vary the TTL to investigate how the policy performs under different levels of time sensitivity, while keeping other settings the same as outlined in Section6.2.

Figure7 illustrates that as the TTL increases, the likelihood of the primary builder’s blocks being selected diminishes. Additionally, the average rewards for primary builders, users, and proposers collaborating with the primary builder experience a decline.For $TTL=1$, which is reflects analysis section, primary builder has the greatest advantage that it can used the best of the private transaction’s expire time to insure them to be process in the next round, where users can have more confidence in the primary builder, and primary builder can be competitive compared with the secondary builder.As TTL increases, the primary builder’s advantage from pre-communicating with the proposer in the next round diminishes.However, there remains an advantage in the bidding process, with the advantages converging when TTL exceeds 10.

6.2.4 Policy with 0 profit in bid

We discovered a viable range for the threshold $\rho$—greater than the default rate $r_{2}$ but less than an upper bound—enabling equilibrium among the three players.Further exploration revealed an intriguing possibility: a bid rate lower than the builder’s default rate can still yield greater rewards for the builder.In this scenario, we set the bid rate to 0 while retaining the default rate at the value detailed in Section6.2 (2%).However, as a consequence of the primary builder receiving lower rewards compared to previous cases.This lack of distinction for users in their builder selection leads to equal probabilities for users to choose builders, maintaining consistency with other settings outlined in Section6.2.

With an optimal threshold in place, proposers show a distinct preference for the primary builder’s candidate block, with greater probability to select primary builder’s block as shown in the first plot.Due to the 0 rate in the bids, primary builder has a lower rewards cdf compared with the secondary builder in the second plot.Finally, as we combine the probability to be selected and the profits in each selection, primary builder could still achieve a greater accumulate rearwards as plot in the third plot.

7.1 Game theory in blockchain

In decentralized blockchain networks, users have the opportunity to engage in various roles within the transaction processing and block generation processes.These diverse roles can be likened to players in a game, with participants applying game theory to maximize their rewards.

In the context of POW networks, extensive game theory research has been conducted on block mining.This research encompasses games related to transaction queues[27], miner mining[25], and mining pool selections[28].The insights gained from these game studies provide players with strategies from learning the networks[15] to optimize their rewards. Strategy design can be applied to various facets, including neighbor selection[30, 42], neighbor degree management[31], direct miner connection[38] and data storage[43].

With Ethereum’s transition from POW to POS, there has been some recent work measuring the adoption and behavior of proposer-builder separation.Some work finds that proposer may not receive the optimized value as expected[19], which fits Flashback’s equilibrium.Another work also points that the conflicts may benefit particular parties due to the implicit trust assumptions[39].

Proof-of-stake introduces a novel consensus mechanism to the network, characterized by distinct roles in generating new blocks.Pos network does not need miners any more, but the stake based validator decision also brings a game[37, 21] on how to select the validators based on stakes.[11] studies the extortion attacks with game among attacker, victim and validators.Price of MEV[32] formalizes a game on transaction ordering mechanism based on priority gas auction and measures its Nash equilibrium, but they don’t consider future block auctions.

7.2 MEV auction platform/flashbots related work

This paper studies MEV auction platform by applying a greedy strategy in selecting transactions on the validator side.Flashback’s private channel design is based on Flashbot[2] and Flashback’s validator’s selection on candidate block is based on MEV-boost[3] with connections to multiple relays to search for maximum MEV.But compared with them, we have simplifications on the block space ordering and functions of relay.

Multi-block MEV[22] secures MEV in k-consecutive blocks.Aequitas[24], Themis[23] arise an ordering strategy with consideration of the received timestamps, which focus more on fairness in transaction ordering.

7.3 Private transaction

Prior research[36, 13, 34, 41, 29] has delved into the realm of private transactions, centering on the assessment of Miner Extractable Value (MEV) and blockchain extractable value (BEV) within the context of private transactions. Notably, Lyu et al.[29] compiled a year-long dataset of private transactions within PoW Ethereum, conducting an empirical analysis of their characteristics, economic implications (e.g., transaction costs and miner earnings), and security effects. In contrast to these efforts, our study endeavors to introduce a game-theoretic model aimed at redistributing profits among various parties (e.g., builders and validators) in PoS Ethereum.

There are some work researching to order the transactions by the other rules.For example, order-fairness[24] introduces a method to process the transaction based on their received timestamp, Wendy[26] presents a method to order based on the transaction’s observation time by honest nodes,However, validators directly get rewards from the fees, there are less incentives for validators to apply the other rules.