Potential EIP: MEV Decrease Deterministic Transaction Ordering via Block-Level Randomness
Simple Summary
Fix the execution order of transactions in every Ethereum block to an objective yet unpredictable key H(tx) ⊕ R, thereby removing reorder‑based MEV (e.g., sandwich and generalized front‑running). Randomness R is sourced from the beacon chain; builders may still curate a profitable subset of the mempool, but once selected they must execute transactions in canonical order. Deterministic tie‑breaking, explicit bundle mechanics, robust randomness analysis, and practical grinding limits are specified.
Abstract
Proposers and builders can currently permute pending transactions arbitrarily, enabling reorder‑driven MEV. This EIP introduces a consensus rule that sorts all transactions inside a block by XOR‑ing each transaction hash with fresh slot randomness. The randomness is unknown until the slot starts, so the order is deterministic once known but unpredictable beforehand. The mechanism significantly reduces reorder‑based MEV; latency‑driven back‑running, censorship, and other classes of MEV remain and should be mitigated through complementary techniques (encrypted mempools, reputation, PBS marketplaces, etc.).
Motivation
Unrestricted ordering is the key enabler of sandwich and classic front‑running attacks. Deterministic ordering collapses these vectors to latency racing and information asymmetry. Clear candidate‑set and bundle semantics preserve fee markets while removing the need for trusted sequencers. Academic work (Qian et al., 2024) shows deterministic ordering drives sandwich profits toward zero.
Specification
Slot Randomness R
Consensus‑layer prerequisite — Companion EIP “EL‑VRF‑exposure” is needed to add the RANDAO’s per‑slot VRF output to the execution layer.
randao_mix_slot : bytes32
vrf_output_proposer : bytes32
R = (randao_mix_slot XOR vrf_output_proposer)[0:16] # low 128 bits
Execution payloads include randomness: bytes16 that MUST equal R; execution clients verify via EIP‑4788.
Builder Flow
- Candidate‑set selection – Builders MAY choose any subset of the mempool based on priority fees, side agreements, or policy. Transactions not chosen are ignored.
- Canonical sorting – Sort the chosen set by primary key
H(tx) ⊕ Rascending, then secondary keyH(tx)ascending, in case of collision on the primary key. - Gas‑limit packing – Append items in order until adding the next would exceed the block gas limit.
- Bundles (optional cross‑address atomicity)
-
Definition – A bundle is a user‑signed list of fully‑signed transactions. Each
child_tx_rlpis the canonical signed RLP encoding, including signature fields(v, r, s). The bundle begins with a fee‑payment transaction that covers gas and builder tip for the entire bundle. -
Hashing / sort key – Treat the bundle as a virtual transaction with key
H(concat(child_tx_rlps)), where:child_tx_rlps[i]MUST be the exact bytes that will later appear in the block body for that transaction, i.e. the canonical RLP of the fully‑signed transaction per EIP‑2718 / EIP‑155 rules (for typed transactions the leading type byte and length prefix are included).- Implementations MUST NOT strip or normalise the signature fields
(v,r,s); those 65 bytes are hashed as‑is so every participant derives an identical bundle key. - The concatenation order is the author‑declared execution order of the child transactions.
-
Gas accounting – Bundle gas is the sum of the
gasLimitfields of all child transactions. Builders use that sum when evaluating step 3. -
Fit‑or‑skip rule – If the bundle (fee‑payment + children) would exceed the remaining gas limit, the bundle is skipped atomically.
- Fee dynamics – Priority fees influence membership in the candidate set (step 1) but never override the canonical order once a tx or bundle is selected.
Consensus Rule
A block is invalid if the executed list deviates from the canonical order derived from its randomness and the included transactions/bundles. Verification is objective; fork‑choice remains unchanged.
Security Analysis
Randomness Bias & RANDAO Manipulation
-
Single‑validator bias – A block proposer can influence only its own VRF output; XOR with the slot‑level RANDAO limits unilateral bias to 1‑in‑2¹²⁸.
-
Coalition bias – Multiple consecutive‑slot proposers could attempt to influence RANDAO by withholding signatures, but the protocol already slashes equivocation and missed attestations. The cost rises exponentially with coalition size, and the added VRF entropy further randomizes
R. -
Forkable bias – Re‑org attempts longer than depth 1 must overcome the usual consensus finality thresholds. Because
Ris embedded in the execution payload, any fork conflicts are objectively detectable by all nodes.
Conclusion: Collusion attacks are economically unattractive; the mixed entropy from RANDAO and VRF provides strong unpredictability guarantees.
Hash Grinding
New signatures are required only when calldata changes, but attacks must begin after R is known (≤ 12 s). Propagation delays and inclusion fees sharply limit profitable grinding to high‑value trades.
Tie Collisions
Secondary key H(tx) guarantees total order; collision probability (2^{-256}) is negligible.
Bundle Gas Consistency
Explicit summation rule ensures every client computes identical gas usage for bundles, preventing divergent validation.
Residual MEV Vectors
-
Back‑running & latency – Persist.
-
Builder discretion – Builders may censor or selectively include transactions while forming the candidate set; exactly like the current status of Ethereum.
Performance
Sorting ≤ 1 500 transactions remains O(n log n) (< 1 ms), on today’s hardware.
Deployment
txOrderingVersion = 1 flag + ORDERING_TRANSITION_EPOCHS window activate the rule.
Backwards Compatibility
- Old nodes — Execution clients that ignore the new fields will treat version‑1 blocks as malformed and fork away. The short transition window gives operators time to upgrade.
- Light clients — No additional work; they track headers chosen by upgraded full nodes.