The era of parallel execution is coming, and the MEV pattern on Monad is explained in detail

Auteur original : APRIORI ⌘

Traduction originale : TechFlow

introduce

In the process of improving blockchain performance for large-scale applications, Monad effectively optimizes the Ethereum Virtual Machine (EVM) model through a series of underlying optimization measures, such as asynchronous I/O, optimized Patricia Trie, delayed execution, and optimistic concurrency control. These improvements solve the execution bottlenecks and inefficient state access problems on platforms such as Ethereum without sacrificing decentralization.

This article explores the possibility of building a powerful Miner Extractable Value Auction infrastructure (MEVA) on Monad, drawing on valuable experience from Flashbots on Ethereum and Jito Network on Solana.

We would like to emphasize a few key points:

• MEV is an inherent feature of any blockchain network. A strong MEVA infrastructure is critical to avoid negative externalities and incentive misalignment in the block production process.

• The design of MEVA is closely tied to the underlying mechanisms of the blockchain, especially the consensus execution phase. Future improvements will depend on the evolution of these factors and how the network performs under different stresses.

• The historical trends of block production on Ethereum and Solana can provide reference for the design of MEVA on Monad.

• On a high-performance, delayed-execution blockchain like Monad, MEVA may require a probabilistic block construction and search strategy similar to high-frequency trading to cope with time constraints.

By exploring these questions, we hope to provide insights for designing a MEVA infrastructure that accommodates the unique architectural and performance requirements of Monads.

MEVA Background in Ethereum

MEVA in the Ethereum consensus execution phase

In Ethereum, consensus requires execution first. When nodes agree on a block, they agree not only on the list of transactions in the block, but also on the Merkle root that is summarized after the block is executed. Therefore, the proposer must execute all transactions in the block before propagating the proposal. At the same time, the validating nodes also need to execute these transactions before voting.

Figure 1: Builder workflow of proposer-builder separation (PBS) in MEV-Boost

Figure 1 shows a typical builder workflow for Proposer-Builder Separation (PBS) in MEV-Boost. After the builder completes the block construction, it submits it to the relayer, which then forwards the block to the Execution Layer (EL) client for simulation and validity checking.

Since execution is a prerequisite for consensus, when a builder builds a block, it needs to forward the block to the Execution Layer (EL) client and simulate the block to check its validity. In addition to its necessary role in the consensus-execution phase, the simulation phase also brings benefits to builders and searchers.

From the builders perspective: By simulating every transaction, the builder can accurately estimate the value of the block to themselves and the validators. They can also try to reorder transactions to minimize rollbacks and maximize the gas fees or base tips extracted from the memory pool and bundled transactions. Accurate estimates allow them to bid higher prglaces to validators.

From the perspective of the searcher: Since the builders screen out the bundled transactions that may be rolled back before the transaction is put on the chain, the searcher can ensure the execution of the strategy, which increases certainty. In addition, the searcher can also access the latest block status. When the consensus layer (CL) propagates a new block, the searcher can use the state of the block as the starting point for building a profitable bundled transaction. At the same time, there are signs that builders now provide more off-protocol transactions or functions that enable searchers to obtain the state information of the block to be built so that the run-back strategy can be added to the block to be put on the chain.

However, the développement of PBS has led to increased centralization of block building, similar to how firms compete for dedicated microwave network channels in traditional trading to prioritize the execution of arbitrage strategies.

As the network matures, products are iterating

We now explore how MEVA has evolved as Ethereum has grown, as shown in Figure 2.

Figure 2: A chronological view of MEVA’s development along with the Ethereum network

The Priority Gas Auction (PGA) Era

Seekers identify profitable MEV opportunities and submit smart contract transactions to the public mempool, as shown in Figure 3. This public visibility leads to open bidding and first-price auctions on-chain, where even failed transactions incur gas fees.

This period saw highly competitive and expensive unstructured MEV activity, such as transactions with identical (account, announcement) pairs and increasing bids, leading to network congestion or consensus instability.

Figure 3: Simple Priority Gas Auction Diagram

Flashbots and EIP-1559

To address these issues, Flashbots introduced relayers as intermediary auction houses between searchers and block producers (miners in the PoW era). This move transformed the MEV market from an open bidding one-price auction to a sealed bid. As shown in Figure 4, relayers help prevent bidding escalation in the public memory pool and establish a more orderly and secure block production process.

The fee structure of EIP-1559 also comes into play here. It simplifies bidding via a base fee, but does not solve the issue of transaction ordering within a block, which still drives MEV via priority fees. In fact, many searchers previously bid directly to miners via coinbase transfers. They ended up having more complaints about the coinbase fee because they could no longer submit 0-gas bundled transactions.

Figure 4: MEVA with relay

Proposer-Builder Separation (PBS)

After Ethereum completed the merger and moved to Proof of Stake (PoS), the separation of proposers and builders (PBS) was implemented to further optimize the separation of roles in the block production pipeline. As mentioned earlier, relayers now act as intermediaries between block builders and proposers, responsible for ensuring data availability and block validity. Since proposers can connect multiple builders for different private transactions, builders must compete by paying fees to proposers. This dynamic is illustrated in Figure 5.

Figure 5: MEVA in the PBS era

Concentration Risk

Despite these historic advances, the growing concentration risk in the builder market must be highlighted. Over the past year, the top 9 builders have consistently accounted for more than 50% of the market, demonstrating a high degree of market concentration, as shown in Figure 6. The current state of concentration is even more pronounced, with the top three builders covering more than 90% of blocks.

Figure 6: Market share of builders, showing the high concentration prevalent in the builder market (Image source )

Jito on Solana

Jitos system architecture

As the standard MEVA on Solana, Jito was created to address Solana’s high level of spam due to low transaction costs. As long as the fees for failed transactions (approximately 0.000005 SOL) do not exceed the expected profit, spam is effectively incentivized.

According to a 2022 report by Jito Labs, more than 96% of arbitrage and liquidation attempts failed that year, and more than 50% of MEV-related transactions were included in the blocks. The report also pointed out that the liquidation bots sent millions of duplicate packets to the network just to complete a few thousand successful liquidations, resulting in a failure rate of more than 99%.

Figure 7: Jito’s MEVA on Solana

The severity of the MEV externality problem on Solana prompted Jito to develop a MEVA layer designed to bring order and certainty to the block production process. Let’s review the original MEVA architecture proposed by Jito, as shown in Figure 7.

Jito has the following components:

Relay – Acts as a proxy to receive transactions and forward them to the Block Engine (or MEVA Supply Chain) and Validators.

Block Engine – Receives transactions from relayers, coordinates searchers, accepts bundles, performs bundle simulation, and forwards the best transactions and bundles to validators for processing. Notably, Jito conducts partial block auctions for inclusion in bundles, rather than full block auctions, and has historically processed over 80% of bundles within two slots.

Pseudo memory pool – Creates a ~200ms window of operation through the Jito-Solana client, triggering a discretized auction of order flow. Jito closed this memory pool on March 9, 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 only supports partial block auctions, not full block construction, likely due to Solana’s multi-threaded execution model’s lack of global scheduling. Specifically, Figure 8 shows parallel threads executing transactions, with each thread maintaining its own queue of transactions waiting to be executed. Transactions are randomly assigned to threads and sorted locally by priority fee and time. Without global sorting on the scheduler side (before the 1.18.x update), Solana’s transactions are inherently subject to non-determinism due to scheduler jitter. Therefore, in MEVA, there is no way for a searcher or validator to reliably determine the current state.

Figure 8: Solana client’s multithreaded execution model. Note that MEVA’s bundling phase is appended to the multithreaded queue as a separate thread.

From an engineering perspective, running Jito’s block engine in parallel as an additional thread fits in nicely with Solana’s multi-threaded architecture. While bundle auctions ensure priority fee-based ordering within the Jito block engine thread, there is no guarantee that bundles will always be globally prioritized over user transactions.

To address this issue, Jito pre-allocates a portion of block space to the bundle thread, guaranteeing that the bundle has space in the block. While uncertainty still exists, this approach increases the probability of successful strategy execution. It also incentivizes searchers to participate in the auction instead of spamming the network. By reserving block space for bundles, Jito is able to strike a balance between promoting orderly auctions and mitigating the disruptive effects of transaction spam.

Remove fake memory pool

Jito’s widespread adoption has yielded positive results in alleviating the spam problem on Solana. According to p2p research and the data shown in Figure 9, the relative block productivity has increased significantly after adopting the Jito client. This suggests that transaction processing has become more efficient due to the optimized block engine introduced by Jito in 2023.

Figure 9: Evidence that Jito effectively mitigates spam issues on Solana. This figure is taken from a study conducted by the p2p team

While significant progress has been made, many challenges remain. Since Jito bundles only partially fill blocks, MEV-induced transactions are still able to bypass the Jito auction channel. Some evidence of this can be found in the Dune Dashboard in Figure 10, showing that since 2024, the network still has an average of over 50% transaction failures due to bot spam.

Figure 10: Dune Dashboard of bot spam activity on Solana since May 2022 (see Dune for details)

On March 9, 2024, Jito decided to suspend its flagship memory pool. This decision was due to a surge in memecoin transaction growth and the subsequent sandwich attacks (seekers placing transactions before and after a target transaction), which ultimately affected the user experience. Similar to MEVA private order flow channels on Ethereum, the closure of the public memory pool may promote the growth of private order flow through cooperation with front-end services such as wallet providers and Telegram bots. Seekers may establish direct partnerships with validators to obtain priority execution, inclusion, or exclusion rights.

In fact, Figure 11 shows the hourly Sandwichbot profits of the largest private mempool searchers after the mempool shutdown.

Largest private mempool searcher:

3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81

(Translators note: Sandwich robot is a common front-running attack tool, mainly used to make profits in blockchain transactions).

Figure 11: Hourly Sandwich Bot Profits Using Private Mempools for the Searcher “3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81”

Jito’s decision to shut down the mempool demonstrates the team’s commitment to addressing fundamental issues in the Solana ecosystem. In addition to iterating on MEVA or adjusting Solana’s gas fee mechanism, Jito is also helping the protocol reduce the risk of attacks through UI product design choices such as limiting default slippage parameters. Whether through fee structure adjustments that make spam transactions more expensive or through modifications to communication protocols, Jito’s infrastructure will continue to play a key role in maintaining the health and stability of the Solana network.

MEVA Design on Monad

Delayed execution and its impact on MEVA

Unlike Ethereum, where agreeing on a block requires a list of transactions (with ordering) and a Merkle root summarizing all post-facto state, Monad decouples prior execution from consensus. Node agreement only needs to solve the official ordering problem. As shown in Figure 12, each node independently executes the transactions in block N when it begins consensus on block N+1. This arrangement allows for a gas budget corresponding to a full block time, since execution only needs to keep pace with consensus. Since there is no need for a leader node to compute a factual state root, execution can use the entire consensus period to process the next block.

Figure 12: Comparison of Monad delayed execution and Ethereum’s execution-consensus phase. The operation time window is also shown from the perspective of MEVA design.

We define the operation time window as the time frame that allows MEVA to complete a block construction proposal on the Monad that is viable and profitable compared to the default block construction method. The delayed execution model has two direct consequences:

• When MEVA is built for the Nth block within the operation time window, the validators are simultaneously reaching consensus on the transaction list of the Nth block while trying to complete the execution of the N-1th block. Therefore, within the Nth operation time window, the available state may still be in the N-2th. This means that under this delayed execution architecture, there is no guarantee that the relay or builder has the latest state. Therefore, it is impossible to simulate against the latest block before the next block is generated, resulting in uncertainty.

• Given Monads 1 second block time, MEVAs operating time window is extremely limited. This means that builders may not have enough time to simulate a full block of transactions and bundles in sequence, as is typically done on Ethereum. Many variables can affect the time required to simulate a transaction on the EVM. However, assuming that simulating a transaction takes 10^1 to 10^2 microseconds (a rough estimate), and Monad is targeting 10^4 transactions per second, simulating a full block within the operating time window alone may take about 1 second. Given Monads 1 second block time, it would be challenging for a builder or relay to complete multiple full block simulations to optimize building a block.

Probability Builder and Seeker Strategies

Given these constraints, it is impractical to complete full block simulations within the operational time window and simulate against the latest state. Since builders now lack both the time and the latest state to know the exact tip of each transaction, they must infer the seeker tip based on the likelihood of transaction rollback, rely on reputation or by (probably at best) simulating against the N-2th state. This makes block valuations less certain.

Due to the lack of theoretical guarantees on transaction rollbacks, searchers face greater execution uncertainty once validators accept a block built by a builder. This contrasts with Ethereum, where searchers compete in dedicated private order flow-to-builder channels to execute with relatively deterministic strategies. In this relatively probabilistic setting on Monad, searchers now face a higher risk of bundle rollback, resulting in a more uncertain execution PnL profile. This is similar to high-frequency traders who execute trades based on probabilistic signals and earn slightly higher expected returns over time.

Figure 13: A conceptual spectrum showing different MEVA design paradigms, categorized according to the degree to which the proposed blocks are checked or simulated.

As shown in Figure 13, the degree of prior bundle/block checking on the builder’s part creates a spectrum of uncertainty in the pricing or valuation of proposed blocks. At one end is the Ethereum-style PBS model with accurate pricing, where builders must simulate transactions in proposed blocks using an Execution Layer (EL) client. They must navigate a wide range of combinations in the bundles they submit. At the other end is the optimistic builder model [16] with asynchronous block checking. In this model, builders bypass the time required for any simulation within the operating time window and honor the tips shown to validators or relayers by depositing collateral (which may be slashed). The probabilistic checking or partial simulation approach proposed here on Monad lies in the middle, increasing the probability that the searcher will successfully execute their strategy despite some uncertainty.

For example, a market maker on an on-chain order book DEX might pre-emptively move their positions via MEVA upon spotting major unidirectional price moves to avoid adverse selection. This probabilistic strategy allows them to act quickly, even without the latest state information, balancing risk and reward in a dynamic trading environment.

Conclusion

MEVA plays a key role in optimizing block production, mitigating external influences, and improving system stability. With the continuous development of the MEVA framework, such as Jito on Solana and various implementations on Ethereum, it has greatly contributed to solving scalability problems and making the incentive mechanism of network participants more consistent.

Monad is a promising network in its infancy that provides the community with a unique opportunity to design the best possible MEVA. Given Monads unique separation of execution and consensus, we invite researchers, developers, and validators to collaborate and share insights. This collaboration will help create a robust and efficient block production process, helping Monad realize its promise as a high-throughput blockchain network.

This article is sourced from the internet: The era of parallel execution is coming, and the MEV pattern on Monad is explained in detail

Related: EMC Bitcoin Weekly Observation (June 10-June 16): The waiting period for interest rate cuts may be extended, and there i

Written by: Shang2046 The information, opinions and judgments on markets, projects, currencies, etc. mentioned in this report are for reference only and do not constitute any investment advice. Market supply and demand are fragile, and BTC is facing miner liquidation Market summary: The Fed’s interest rate meeting on June 12 and the US CPI data for May have indeed become the dominant factors in BTC’s trend last week. Stimulated by the downward trend of CPI data, BTC once again hit the $70,000 mark, but then fell rapidly due to the Fed’s hawkish remarks. BTC fell 4.32% for the whole week, with an amplitude of 7.44%. The interest rate cut dot plot shows that most market expectations are that the interest rate cut will be postponed to the end of the…