Mempool Design Under Adversarial Load: Admission, Fees, and Spam

Monthly research note. Theme: Blockchain Protocols.

TL;DR

A focused memo on Mempool Design Under Adversarial Load: Admission, Fees, and Spam: define the model, state the properties, then design the system so those properties remain true under failure and adversaries.

Key takeaways

• Finality guarantees are user security guarantees—document and enforce them.
• Consensus safety is meaningless if execution is nondeterministic across nodes.
• Topology attacks (eclipse/partition) change security outcomes; harden peer selection.
• Prefer protocols and APIs that make invalid states hard to express.
• Make failure modes explicit and observable.

Why this matters

• Finality guarantees are user security guarantees; ambiguity is a UX vulnerability.
• State growth is a security problem: it impacts decentralization and verification.
• Mempools are an attack surface: spam, pinning, and incentive manipulation.
• MEV turns protocol details into adversarial strategy.

Key questions

• How do upgrades change security assumptions (fork choice, state transition rules)?
• What is the reorg budget for applications and how do you communicate it?
• Where do you enforce resource limits (gas, bandwidth, storage, signature checks)?
• Which invariants need proofs (supply, balances, ordering, slashing)?
• What is the finality guarantee users can rely on (and when does it break)?
• What is the determinism story (byte-for-byte re-execution across platforms)?

Assumptions

• Nodes are heterogeneous; determinism must survive platform differences.
• Upgrades happen under partial adoption; mixed-version is inevitable.
• Attackers can buy bandwidth and compute; they can also bribe and censor.
• Users and apps rely on probabilistic finality until proven otherwise.

Non-goals

• Assuming honest majority without defining the adversary’s budget.
• Treating mempool policy as “local preference” when it affects security.

Model & invariants

State commitments bind execution to succinct proofs:

Separate consensus safety from execution safety; both must hold.

Explicitly model upgrade boundaries: old rules vs new rules during transition.

Security properties

• Authenticity: actions are bound to identity and purpose.
• Integrity: invalid transitions are rejected (and detectable).
• Least authority: privileges are scoped by purpose and time.
• Replay resistance: duplicated inputs do not change outcomes.

Failure modes

• Config drift that weakens security posture over time.
• Timeout ambiguity causing double-apply or partial state transitions.
• Mixed-version behavior that violates assumptions silently.
• Recovery paths that only work when nothing is broken.

Design sketch

flowchart TD
  tx["Transaction"] --> mp["Mempool (admission + prioritization)"]
  mp --> prop["Block Proposal"]
  prop --> cons["Consensus / Finality"]
  cons --> exec["Deterministic Execution"]
  exec --> root["State Root Commitment"]

Implementation notes

Treat mempool policy as part of the protocol if it changes security outcomes.

Mempool hardening checklist:
- Per-peer rate limits + global admission budget
- Duplicate detection and eviction policy
- Signature verification batching with caps
- Anti-DoS: bounded decode/parse cost
- Fairness: per-sender quotas (avoid hot-account starvation)

Verification strategy

• Fork/reorg simulations: application-facing invariants under reorgs.
• Determinism tests across architectures (x86/ARM) and OSes.
• Cross-implementation tests when multiple clients exist.
• Adversarial mempool tests: spam, pinning, worst-case signature patterns.
• Fuzzing transaction decoding and state transition edge cases.

Operational notes

• Rehearse upgrades with mixed versions and rollback paths.
• Monitor reorg depth and frequency; treat increases as incidents.
• Measure invalid tx rejection reasons and rates (spam signature).
• Protect peer tables against eclipse attempts (diversity, scoring, rotation).
• Keep execution resource limits explicit and enforced.

What to monitor

• Retry/timeout rates by endpoint and client cohort.
• Error budget burn + tail latency under load.
• Rollback events and the conditions that triggered them.
• Admission-control / rate-limit rejections (by reason).
• Authz failures and policy denials (unexpected spikes).

Rollback plan

• Preserve evidence (configs, artifacts, audit logs) to reconstruct what changed.
• Keep dual-write / dual-verify windows where appropriate.
• Define an explicit rollback trigger (metrics + thresholds).
• Prefer backward-compatible changes; avoid “flag day” upgrades.
• Use canaries and staged rollout; stop early when signals degrade.

Evidence

• Learn TLA+ (1) — Practical entry point for specification and model checking.
  • Evidence: Model the smallest thing that can break; use model checking to validate invariants before optimizing.
• Jepsen (2) — Fault injection and correctness testing for distributed systems.
  • Evidence: Turn faults into test cases; prioritize partition and clock-skew scenarios that violate user-visible guarantees.

Open questions

• How do you communicate finality uncertainty to users without lying?
• Where does your implementation accidentally depend on local wall-clock time?
• Which invariants should be proven vs tested vs monitored?
• What is the worst-case work a single transaction can force?

Checklist

• Safety properties stated as invariants.
• Failure modes enumerated with mitigations.
• Costs bounded (CPU/memory/bandwidth) under adversarial inputs.
• Rollback plan rehearsed and automated.
• Assumptions listed and reviewed.
• Telemetry captures correctness signals.

Further reading

• EIP-1559 — Fee market mechanics and incentive surfaces.
• Ethereum Yellow Paper — A formal-ish specification for execution and state transitions.
• Bitcoin: A Peer-to-Peer Electronic Cash System — The original replicated-ledger model and threat assumptions.
• Learn TLA+ — Practical entry point for specification and model checking.
• Jepsen — Fault injection and correctness testing for distributed systems.
• Site Reliability Engineering (Google) — Error budgets, incident response, and reliability as an engineering discipline.