EIP-7956: Tx Ordering via Block-Level Randomness

EIPs EIPs core
,
6

One aspect that could be interesting to explore further is how this EIP handles scenarios requiring explicit execution dependencies within the same block, particularly when transactions might originate from different actors. For example, ensuring an oracle price update transaction is definitely executed before another transaction that consumes that price in a DeFi operation, all within the same block. While the EIP mentions bundles for atomicity, these are typically user-signed lists from a single originator.

A potential augmentation could be to introduce optional execution tiers.

  • Users could specify a tier (e.g., Tier 0, Tier 1, Tier 2…) for their transaction, perhaps via a small field in the transaction data. Regular transactions could default to Tier 0.
  • The block construction logic would first sort transactions by tier (Tier 0 executes first, then Tier 1, etc.).
  • Within each tier, the EIP’s proposed canonical sorting mechanism (H(tx) ⊕ R primary key, H(tx) secondary) would be applied.

Benefits of such a tiered approach could include:

  1. Explicit Dependency Management: Provides a protocol-level way for transactions from different origins to ensure a sequence (e.g., OracleCo’s price update in Tier 0, Alice’s DEX trade based on that oracle in Tier 1, Bob’s lending platform adjustment also in Tier 1).
  2. Preservation of EIP’s MEV Reduction: Within each tier, the randomness-based sorting still protects against reordering attacks among transactions that don’t have a strict dependency or are in the same dependency group.
  3. Clarity: Makes the intended execution flow more explicit for critical dependent transactions.

Potential Considerations:

  • Added Complexity: This would introduce a new transaction field and require builders to perform a multi-stage sorting process (sort by tier, then sort by key within each tier).
  • Tier Dynamics: It might lead to discussions around optimal tier usage, potential competition or new (albeit more constrained) MEV strategies related to accessing specific tiers if they become highly valued.

This isn’t to detract from the core proposal, which is strong for generalized MEV reduction. Rather, it’s a thought on how to layer explicit, user-defined sequencing for critical dependent operations on top of the randomized ordering foundation for the general case.

Great work on this EIP – it’s a valuable direction for mitigating a significant MEV vector! Curious to hear your thoughts on handling such explicit inter-transaction dependencies.

2 Likes