Introduction

In the ongoing quest to enhance blockchain performance to handle mass adoption, Monad stands out as a pioneering force for optimizing the Ethereum Virtual Machine (EVM) model with a series of low-level enhancements: asynchronous I/O, an optimized Patricia Trie, deferred execution, and Optimistic Concurrency Control for parallel processing [2]. These improvements effectively tackle execution bottlenecks and inefficient state access seen on platforms like Ethereum without sacrificing decentralization.

In this post, we explore possible implementations of a robust Miner Extractable Value Auction Infrastructure (MEVA) on Monad. We also describe some transferrable, valuable lessons from existing approaches like Flashbots on Ethereum and Jito Network on Solana.

We want to highlight a few key considerations:

1. MEV is inherent to any blockchain network. A robust MEVA infrastructure is crucial to avoid a messy block production process with negative externalities and misaligned incentives.
2. MEVA design is deeply integrated with a chain’s underlying mechanics, specially its consensus-execution staging. Future enhancements will depend on the evolution of these factors and the performance of the network under different levels of stress.
3. Historical trends in block production evolution, as seen on Ethereum and Solana can inform MEVA design on Monad.
4. MEVA on high-performance, deferred execution blockchains like Monad will likely require probabilistic block building and searching strategies, akin to high-frequency trading, due to its time constraints.

By addressing these points, we hope to provide insight into the challenges and considerations involved in designing a MEVA infrastructure tailored to Monad’s unique architecture and performance requirements.

MEVA Landscape in Ethereum

MEVA under Ethereum’s Consensus-Execution Staging

In Ethereum, consensus requires prior execution. When nodes agree on a block, they are agreeing on both the list of transactions in the block and the Merkle root summarizing the post-facto state after the block has been executed. Hence, leaders must execute all the transactions in the proposed block before propagating the proposal. Meanwhile, validating nodes need to execute the transactions before voting.

Figure 1: The Builder Workflow in MEV-Boost under the EL-CL separation.

Figure 1 illustrates a typical builder workflow in MEV-Boost for Proposer-Builder Separation (PBS). Builders finish building the blocks and submit them to a relay, which forwards the blocks to an Execution Layer (EL) client for simulation and validity checks.

Since execution is a pre-requisite to consensus, when a builder builds a block it needs to forward the build block to an Execution Layer (EL) client and simulate the block to check its validity. Beyond its necessary role in consensus-execution staging, the simulation stage also brings benefits for both builders and searchers.

Builder’s perspective: Builders can accurately estimate the block’s value to both themselves and the validators by simulating every transaction. They can also experiment with reordering transactions to minimize reverts and maximize the extraction of gas fees or base tips from both mempool and bundle transactions. Their precise estimate allows for higher bids to validators.

Searcher’s perspective: As a result of builders screening out potentially reverting bundles before they landing on-chain, searchers also see guaranteed strategy execution, adding determinism. Furthermore, searchers also gain access to the most recent block state. When the consensus layer (CL) propagates a new block, searchers can use the state from that block as a starting point to construct profitable bundles. Meanwhile, there’re indications for more off-protocol deals or features offered by builders right now, which allow searchers to get state information for even the current block-to-be-built for adding backrun strategies to their to-be-landed blocks.

However, the PBS development has seen a rise in centralization in block building, mirroring traditional trading in which firms compete for dedicated microwave network channels to gain priority for executing arbitrage strategies.

Product Iteration as Network Matures

We now explore how MEVA has evolved as Ethereum progressed, illustrated chronologically in Figure 2.

Figure 2: A chronological view of how MEVA iterates as the Ethereum Network progresses forward. The figure is slightly adapted from [4].

Priority Gas Auction (PGA) Era

As shown in Figure 3, searchers identified profitable MEV opportunities and submitted their smart-contract-enabled transactions to the public mempool. This public visibility led to an open-bid, first-price auction format on-chain, where even failed transactions incurred gas costs.

This period saw competitive and costly unstructured MEV activities such as transactions with the same (account, nounce) pair and increasing bids [6], adding to the congestion of the network or consensus instability.

Figure 3: Simple Priority Gas Auction. The figure is slightly adapted from [6].

Flashbots and EIP-1559

To address these issues, Flashbots introduced relays, intermediary auction houses between searchers and block producers (miners in the PoW era). This initiative transforms the MEV marketplace from an open-bid first-price auction to a sealed-bid one. Figure 4 shows how the relays help prevent bid escalation in the public mempool and establish a more orderly and secure block production process.

EIP-1559’s fee structure also plays a role here [7]. It simplified bidding by introducing partially posted prices through base fees but didn’t address transaction order within blocks, which still drives MEV through priority fees. In reality, many searchers were previously expressing bids to miners directly through coinbase transfer. They ended up have more complaints about coinbase fees, because they were no longer able to submit 0-gas bundles.

Figure 4: MEVA with Relays. The figure is slightly adapted from [6].

Proposer-Builder Separation (PBS)

Following Ethereum’s transition to Proof of Stake (PoS) after the merge, Proposer-Builder Separation (PBS) was implemented to further refine the separation of roles in the block production pipeline. As described earlier, relays now act as intermediaries between block builders and proposers, acting as custodians that ensure data availability and block validity. Because a proposer can connect to multiple builders for different private transactions, builders must compete by offering payments to the proposer. This dynamic is illustrated in Figure 5.

Figure 5: MEVA in the PBS Era. This figure is slightly adapted from [6].

Concentration Risks

Despite these historical advancements, it’s important to highlight the growing concerns of concentration risks in the builders’ market. In the past year, an oligarchy of the top 9 builders have consistently held >50% of the market pointing to a high degree of market concentration, as indicated in Figure 6. The state of the concentration is even more pronounced currently with top three builders covering over >90% of the blocks.

Figure 6: Market share of builders. The graph indicates the high concentration prevalent in the builder’s market. The graph is adopted from https://arxiv.org/pdf/2405.01329

Jito on Solana

Jito’s Architecture

As the canonical MEVA on Solana, Jito was created to address Solana’s high spamming rate due to low transaction costs. Spamming trades are effectively incentivized as long as the cost of a failed transaction (approximately 0.000005 SOL) does not exceed the expected profit.

According to a report by Jito Labs in 2022 [8], over 96% of arbitrage and liquidation attempts failed that year, with blocks containing more than 50% MEV-related transactions. The report also highlights that liquidation bots have spammed the network with millions of duplicate packets only to accomplish several thousand successful liquidations, resulting in a failure rate higher than 99% [8].

Figure 7: A bird’s-eye view of Jito’s MEVA on Solana.

The severity of the MEV externalities on Solana led Jito to develop a MEVA layer aimed at bringing order and determinism to the block production process. Let’s review the original MEVA architecture proposed by Jito, as illustrated in Figure 7.

Jito has the following components:

Relay - acts as a proxy to receive transactions and forwards them to both the Block Engine (or the MEVA supply chain) and validators.

Block Engine - ingests transactions from the relayer, coordinates with searchers, accepts bundles, performs bundle simulations, and forwards the best transactions and bundles to the validator for processing. Notably, Jito conducts a partial block auction for bundle inclusion instead of a full block auction, historically processing over 80% of bundles within two slots [9].

Pseudo Mempool - creates an operational time window of roughly 200 milliseconds via the Jito-Solana client, inducing a discretized auction for the orderflow [10]. Jito shut down this mempool on March 9th, 2024.

Jito’s Design Choices

Let’s explore the specific components of Jito’s system design and consider how these design choices stem from Solana’s block production process.

Jito supports only partial block auctions rather than full block building, likely due to Solana’s multi-threaded execution model, which lacks global scheduling. Specifically, Figure 8 shows parallel threads that execute transactions, each maintaining its own queue of transactions waiting to be executed. Transactions are randomly assigned to threads and ordered locally by priority fee and time. Without global ordering on the scheduler side (prior to 1.18.x update), Solana’s transactions inherently experience non-determinism from the scheduler jitter [11]. Consequently in the MEVA, searchers or validators can not reliability determine the current state.

Figure 8: The Multi-Threaded execution model for Solana Client. Notice that the the MEVA’s Bundle Stage is appended as a separate thread within the multi threaded queue.

From an engineering perspective, integrating Jito’s block engine feed as an additional thread running parallel to existing ones fits well with Solana’s multi-threaded architecture. While bundle auctions ensure priority-fee-based ordering within the Jito block engine thread, there’s no guarantee that bundles will always be placed before user transactions globally.

To address this, Jito preallocates part of the blockspace for the bundle thread, guaranteeing bundles with space in the block. Although indeterminism remains, this approach increases the probability for successful strategy execution. It also incentivizes searchers to participate in the auction rather than spamming the network. By reserving blockspace for bundles, Jito is able to strike a balance, promoting orderly auctions and mitigating the chaotic effects of transaction spamming.

Removing the Pseudo-Mempool

The widespread adoption of Jito has yielded positive results in mitigating the spamming problem on Solana. Research by p2p [12] and data shown in Figure 9 reveal a statistically significant improvement in the relative block production rate after adopting the Jito client. This indicates that transaction processing has become more efficient, thanks to Jito’s optimized block engine introduced in 2023.

Figure 9: Evidence for Jito’s effectiveness at mitigating the spamming problem on Solana. The graph is extracted from a research piece in [12] conducted by the p2p team.

While significant progress has been made, many challenges remain. Since Jito bundles only partially fill the blocks, MEV-inducing transactions can still bypass the Jito auction channel. This issue is at least partially evidenced by the Dune Dashboard in Figure 10 [13], which shows that the network still experiences an average of more than 50% failed transactions due to bot spamming since 2024.

Figure 10: A Dune Dashboard (https://dune.com/queries/3537204/5951285) illustrating bot spamming activities on Solana since May 2022.

On March 9th, 2024, Jito made the decision to suspend its flagship mempool. This decision was prompted by the growth in memecoin transactions and a corresponding surge in sandwich attacks (a type of front-running where searchers place transactions before and after the target transaction), which ultimately degraded the user experience. Similar to trends observed on Ethereum with private order flow channels in MEVA, shutting down the public mempool may encourage the growth of private order flow through partnerships with front-end services such as wallet providers and Telegram bots. Searchers may form partnerships with validators directly for preferred execution, inclusion, exclusion. In fact, evidence of this can be seen in Figure 11, which illustrates the hourly sandwich bot profit profile for the largest private mempool searcher (3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81) following the mempool shutdown.

Figure 11: The Hourly Profit for Sandwich Bot with Private Mempool for Searcher “3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81”.

Jito’s decision to close the mempool underscores the team’s strong commitment to tackling fundamental issues within the Solana ecosystem. Beyond iterating on MEVA or adjusting Solana’s gas fee mechanism, Jito also helps educate protocols on mitigating attack vectors through UI product design choices such as limiting default slippage parameters. Whether through fee structure adjustments that make spamming more expensive or through modifying communication protocols, Jito’s infrastructure will remain essential for maintaining Solana’s network health and stability.

MEVA Design on Monad

Deferred Execution & Implications on MEVA

Unlike Ethereum, where agreeing on a block requires both the list of transactions (with ordering) and the merkle root summarizing all post facto states, Monad decouples prior execution from consensus. Node agreement only requires settling the official ordering. As illustrated in Figure 12, each node executes the transactions in block N independently while commencing consensus on block N+1. This arrangement allows for a gas budget corresponding to the full block time since execution only needs to keep pace with consensus. [15] Without the need for the lead node to compute the de facto state root, execution can utilize the entire consensus period for the next block.

Figure 12: Monad Deferred Execution comparing to Ethereum’s Execution-Consensus staging. The Operational Time Window also gets illustrated from the MEVA design perspective.

We define the Operational Time Window as the timeframe allowed for MEVA on Monad to complete a block building proposal that is both feasible and profitable compared to the default block building method. There’re two immediate consequences of the deferred execution model:

1. When MEVA builds for the Nth block within the operational time window, the validators are concurrently agreeing on the transaction list for the N th block while trying to complete the execution for the N-1th block. Hence, within the operational time window at N, it’s very possible the available state is still at N-2. This means that there’s no “most recent state” guaranteed for the relay or the builder under this deferred execution architecture. Hence, it is impossible to simulate against the latest block before the next one is produced, resulting in indeterminism.
2. Given Monad’s 1-second block time, the operational time window for MEVA is extremely limited. This means that builders may not have enough time to sequentially simulate full blocks of transactions and bundles as they typically do on Ethereum. Many variables can effect the time needed for transaction simulation on EVM. However, assuming that simulating a transaction takes between 10^1 to 10^2 microseconds (a rough ballpark assumption), and with Monad’s target of 10^4 transactions per second, it could take approximately 1 full second just to simulate the full block within the operational time window. Considering Monad’s 1-second block time, it would be challenging for builders or relays to complete multiple full-block simulations to optimize the built block.

Probabilistic Builder & Searcher Strategy

Given the constraints, completing a full block simulation within the operational time window and simulating against the most recent state is impractical. Since builders now lack both the time and the most recent state to know the exact tip from each transaction, they must infer the searcher tip based on the likelihood of transaction reversion by relying on reputation or by simulating against (possibly at best) N-2 state. This makes block valuation less deterministic.

Searchers face greater execution uncertainty due to the lack of theoretical guarantee against transaction reverts once the validator accepts the block built by the builder. This contrasts with Ethereum, where searchers compete for dedicated private orderflow-to-builder channels for relatively deterministic strategy executions. In this relatively probabilistic setting on Monad, searchers now face a higher risk of bundles reverting on-chain, leading to a more uncertain execution PnL profile. This mirrors high-frequency traders who execute on probabilistic signals with slightly positive expected returns over time.

Figure 13: A conceptual spectrum diagram illustrating different MEVA design paradigms categorized by the degree of proposed block checking or simulation.

As shown in Figure 13, the degree of prior bundle / block check on the builder’s side creates a spectrum of uncertainty regarding the proposed block’s pricing or valuation. On one end is the Ethereum-style PBS model with accurate pricing, where builders must use the Execution Layer (EL) Client to simulate transaction in the proposed the block. They have to navigate through a wide range of combinatorics among submitted bundles. On the other end is the Optimistic Builder Model [16] with asynchronous block checking. In this model, builders bypass the time required for any simulation during the operational time window and honor the tips shown to validators or the relay by depositing collateral subject to slashing. The probabilistic checking or partial simulation approach proposed here on Monad falls in between, enhancing the likelihood of successful strategy execution for searchers despite some indeterminism.

For example, a market maker on an onchain orderbook DEX might pay to pre-move their positions via the MEVA when they spot a major uni-directional price movement to avoid adverse selection. This probabilistic strategy allows them to act quickly, even without the most recent state information, balancing risk and reward in a dynamic trading environment.

Closing Remarks

MEVA plays a crucial role in optimizing block production by mitigating externalities and enhancing overall system stability. The continuous evolution of MEVA frameworks, exemplified by Jito on Solana and various implementations on Ethereum, is immensely helpful for addressing scalability challenges and aligning the incentives of network participants.

Monad is a promising network in its infancy, presenting a unique opportunity for the community to shape the optimal MEVA design. Considering Monad’s unique execution-consensus staging, we invite researchers, developers, and validators to collaborate and share insights. This collaboration will be instrumental in creating a robust and efficient block production process, enabling Monad to achieve its potential as a high-throughput blockchain network.

Disclaimer：

1. This article is reprinted from [0xapr]. All copyrights belong to the original author [APRIORI ⌘]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.