Transaction Shuffling and MEV on Aptos
Transaction lifecycle on Aptos
edited 2025-02-21
On Aptos, transactions follow a structured lifecycle to achieve finality. Initially, transactions are submitted to full nodes, which propagate them to validator nodes. Within the consensus layer—powered by AptosBFT—transactions are collected into a proposed block and reordered using a pre-execution shuffling mechanism to balance the load and enhance fairness. Once consensus is reached among validators, the agreed-upon block, containing the shuffled transaction order and cryptographic proofs, is finalized. The execution engine then processes these transactions, leveraging Block-STM for parallel execution, and updates the ledger, achieving rapid finality with robust security. This design integrates shuffling within consensus to determine the transaction order, followed by efficient execution and ledger confirmation.
Pre-Execution Shuffling
In between consensus and execution, Aptos uses a pre-execution shuffling mechanism to order transactions. This mechanism is used to:
- Balance the Load: Prevent a burst of transactions from the same sender or of the same type.
As noted in AIP-68:
"...This (Long block latency) is expected to happen in this particular situation where spikes of conflicting/sequential transactions from a popular module (smart contract) dominates the traffic"
How transaction shuffling works on Aptos
Example 1
The diagram above illustrates how transaction shuffling works in practice. Let's break it down:
-
Original Transaction Order:
- The top row shows transactions in their original order (0-9)
- Transactions of the same sender have the same letter
- Transactions of the same use case (smart contract) have the same color
- Each circle represents a transaction, with numbers indicating their original position
-
Shuffled Transaction Order:
- The bottom row shows transactions after shuffling
- The numbers below show their new positions
- With
sender_spread_factor = 1, transactions from the same sender are spread apart - Notice how green "A" transactions that were originally clustered are now distributed
-
Shuffling Parameters:
sender_spread_factor = 1: Spreads transactions from the same senderplatform_use_case_spread_factor = 0: No additional delay for platform transactionsuser_use_case_spread_factor = 0: No additional delay for user transactions
-
Result:
- Transactions from sender A (green) are spread out evenly
- Transactions from sender B (blue) and C (orange) maintain relative ordering
- Each transaction is shifted by 1 slot relative to others from the same sender
Example 2
Let's analyze this diagram which shows a more complex shuffling scenario:
-
Original Transaction Order:
- Similar to Example 1, transactions are shown with sender (letter) and use case (color)
-
Shuffling Parameters:
sender_spread_factor = 2: Spreads transactions from the same sender further apartplatform_use_case_spread_factor = 0: No additional delay for platform transactionsuser_use_case_spread_factor = 1: Slight delay for user transactions
-
Key Effects:
- "Same context transactions are spaced by 1" - Transactions with the same use case maintain a minimum spacing
- "Same sender transactions are spread by at least 2 slots" - Due to
sender_spread_factor - "Both spreads are applied independently" - The transaction will be delayed by whichever spread factor results in a longer delay
- Some sender spreads "could not be fulfilled" due to competing constraints
This example demonstrates how multiple spread factors interact and sometimes compete, leading to a complex but deterministic reordering that balances various constraints.
More examples can be found in test cases in the Aptos codebase
Live Parameters
The current live parameters for the transaction shuffler are:
| Parameter | Value | Effect |
|---|---|---|
| sender_spread_factor | 32 | Spreads transactions from the same sender, with potential saturation |
| platform_use_case_spread_factor | 0 | No delay for platform transactions, prioritizing system operations |
| user_use_case_spread_factor | 4 | Spaces out user transactions to prevent dominance in order |
pub fn default_for_genesis() -> Self {
TransactionShufflerType::UseCaseAware {
sender_spread_factor: 32,
platform_use_case_spread_factor: 0,
user_use_case_spread_factor: 4,
}
}
Implications for MEV Strategies
Aptos's transaction shuffling mechanism fundamentally alters the landscape for Maximum Extractable Value (MEV) strategies by introducing dynamic, consensus-driven reordering before execution, building on an initial gas-based queue. This design imposes significant challenges for MEV extractors:
-
Reduced Predictability in Ordering: Transactions enter the consensus phase with an initial order based on gas prices, reflecting submitter priority. However, the
UseCaseAwareshuffler, with parameters like sender_spread_factor (32) anduser_use_case_spread_factor(4), then disperses these transactions across the block based on sender and use-case constraints. This interplay transforms the predictable gas-based sequence into a complex, volume-dependent order, making it harder for MEV actors to anticipate final positions. -
Disrupted Concentration and Fairness: While gas offers a starting advantage, shuffling prevents bursts of related transactions (e.g., multiple trades from one sender), diluting opportunities for MEV tactics like front-running or arbitrage. This fosters a more equitable market by reducing the dominance of high-gas bidders who might otherwise cluster transactions for profit.
The shuffling process—integrated into the AptosBFT consensus layer—begins with a gas-prioritized queue, then applies use-case prioritization (e.g., spacing user transactions by 4 slots) and sender-specific spreads (e.g., up to 32 slots). This layered approach, backed by a priority queue system, evolves transaction ordering beyond simple gas auctions. For instance, a bot attempting to front-run a large decentralized exchange trade with a high gas bid might still lose its edge if shuffling spreads its transaction apart from the target. While this enhances fairness and load balancing, it may slightly delay time-sensitive trades initially favored by gas, a trade-off for resilience.
MEV strategies must now adapt, potentially shifting from exploiting gas-driven order to analyzing shuffle patterns across blocks. As MEV techniques advance, Aptos's tunable shuffling parameters, layered atop gas prioritization, will be key to sustaining an equitable ecosystem, indirectly bolstering network integrity by curbing manipulative reorderings.