mempool-asymmetric-dos

Injectable Skill: Mempool Asymmetric DoS

L1 trigger: L1_PATTERN=true AND (txpool/ OR mempool/ OR tx_pool OR blob_pool OR reth-transaction-pool detected in recon subsystem map) Inject Into: depth-network-surface or depth-state-trace Language: Go and Rust Finding prefix: [MP-N] Status: v0.1 draft, Round 4 exemplars pending

Orchestrator Decomposition Guide

• Section 1, 2: depth-network-surface (entry cost vs eviction cost)
• Section 3: depth-state-trace (mempool state consistency)
• Section 4: depth-edge-case (boundaries of the pool)

When This Skill Activates

Recon identifies a mempool module. Mempools are uniquely exposed: every RPC client and every peer can insert transactions. The DETER paper (USENIX CCS '21) and MemPurge follow-ups showed that most production mempools had asymmetric cost models exploitable at near-zero attacker cost.

1. The Core Asymmetry Check

The DETER insight: if an attacker can insert transactions with lower cost than it takes to evict them, they can fill the pool faster than honest transactions can reclaim space.

For each mempool:

1. Identify the insert cost in (gas, fee, stake, or other resource): what does the attacker pay per byte of pool space occupied?
2. Identify the eviction threshold: when does a new higher-fee transaction kick out a lower-fee one?
3. Identify the eviction cost to the attacker: to evict an honest transaction, what must the attacker's replacement pay?
4. Compute the ratio: insert_cost / eviction_cost. If this is much less than 1, the pool is asymmetric.

Specific patterns:

1a. Invalid-but-accepted transactions

Transactions that are initially accepted into the pool but will later fail validation (nonce gap, insufficient balance, invalid signature for a new state root). These cost the attacker 0 but occupy space until the validator reprocesses them.

Check: Look for a "pending" vs "valid" split. When is validity re-checked? Can an attacker keep an invalid tx in "pending" indefinitely?