Monthly research note. Theme: Blockchain Protocols.

TL;DR

A focused memo on Fee Markets and MEV: Incentives as an Adversary: define the model, state the properties, then design the system so those properties remain true under failure and adversaries.

Key insight

Treat “timeouts” as a third outcome: not success, not failure—ambiguity you must model.

Key takeaways

  • Upgrades must be compatibility-aware: mixed rulesets are a threat model.
  • Consensus safety is meaningless if execution is nondeterministic across nodes.
  • Topology attacks (eclipse/partition) change security outcomes; harden peer selection.
  • Treat retries, reordering, and partial failure as default conditions.
  • Prefer protocols and APIs that make invalid states hard to express.

Why this matters

  • Bridges reintroduce trust; you must model it explicitly.
  • MEV turns protocol details into adversarial strategy.
  • State growth is a security problem: it impacts decentralization and verification.
  • Mempools are an attack surface: spam, pinning, and incentive manipulation.

Key questions

  • How do upgrades change security assumptions (fork choice, state transition rules)?
  • Where is the economic/DoS pressure applied (mempool, gossip, execution, storage)?
  • What is the finality guarantee users can rely on (and when does it break)?
  • Which invariants need proofs (supply, balances, ordering, slashing)?
  • Where do you enforce resource limits (gas, bandwidth, storage, signature checks)?
  • What is the reorg budget for applications and how do you communicate it?

Assumptions

  • Peers are untrusted; gossip can be manipulated for delay or isolation.
  • Nodes are heterogeneous; determinism must survive platform differences.
  • Attackers can buy bandwidth and compute; they can also bribe and censor.
  • Upgrades happen under partial adoption; mixed-version is inevitable.

Non-goals

  • Relying on client-side heuristics to paper over protocol ambiguity.
  • Allowing execution nondeterminism for performance convenience.
Attack surface

Observability pipelines can be attacked (cardinality explosions, log injection). Protect them.

Model & invariants

A simple resource-admission constraint:

∑tx∈Bcost(tx)≤budget(B)(gas/bytes/sigchecks).\sum_{tx \in B} \mathrm{cost}(tx) \le \mathrm{budget}(B)\qquad\text{(gas/bytes/sigchecks)}.

Model the mempool as an adversarial scheduler: it chooses which work gets executed.

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

Invariant

Make the “impossible state” observable: a metric or alert that fires when invariants drift.

Security properties

  • Evidence: critical actions emit verifiable audit events.
  • Integrity: invalid transitions are rejected (and detectable).
  • Least authority: privileges are scoped by purpose and time.
  • Downgrade resistance: negotiation can’t silently weaken security posture.

Failure modes

  • Timeout ambiguity causing double-apply or partial state transitions.
  • Observability gaps during incidents (missing evidence).
  • Mixed-version behavior that violates assumptions silently.
  • Config drift that weakens security posture over time.
Pitfall

Sampling hides the rare schedule that breaks your invariants.

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.

Rule of thumb

If you can’t explain a timeout outcome, you can’t make retries safe.

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

  • Fuzzing transaction decoding and state transition edge cases.
  • Determinism tests across architectures (x86/ARM) and OSes.
  • Fork/reorg simulations: application-facing invariants under reorgs.
  • Adversarial mempool tests: spam, pinning, worst-case signature patterns.
  • Formal invariants for supply/balance conservation where appropriate.

Operational notes

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

Attach explicit rollout/rollback triggers to changes that touch security or correctness.

What to monitor

  • Retry/timeout rates by endpoint and client cohort.
  • Error budget burn + tail latency under load.
  • Invariant violation rate (should be ~0).
  • Authz failures and policy denials (unexpected spikes).
  • Rollback events and the conditions that triggered them.

Rollback plan

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

Evidence

  • Jepsen (1) — 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.
  • Designing Data-Intensive Applications (Kleppmann) (2) — The systems-engineering baseline for correctness, replication, and failure.
    • Evidence: Replication and consistency tradeoffs as engineering constraints; use as reference when naming guarantees.

Open questions

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

Checklist

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

Further reading

1.
Jepsen. Jepsen: Distributed Systems Safety Analysis [Internet]. Web; Available from: https://jepsen.io/
2.
Kleppmann M. Designing Data-Intensive Applications [Internet]. O’Reilly Media; 2017. Available from: https://dataintensive.net/