Grant Application - Zebra Mempool Adversarial Resilience Suite

[deucali0n10]

Hi everyone. I just submitted a ZCG application and I’m posting here for
feedback as required. GitHub issue:

Grant Application - Zebra Mempool Adversarial Resilience Suite

Short version: I want to build a test harness that attacks Zebra’s mempool with
valid but malicious transaction patterns, and leave it behind as permanent CI
coverage.

Why I think it’s worth doing. Now that zcashd is end of support, the network runs
on Zebra and Zakura, so a mempool policy weakness shows up across most nodes at
once and gets inherited by forks. Ironwood is also adding new transaction types
to the admission path.

I want to be upfront about what already exists, because I’m not claiming a gap
that isn’t there. Zebra already lands regression tests for disclosed mempool
issues (there’s one literally labelled “Regression test for GHSA-m9xx-8rcj-vmgp”
in mempool/downloads/tests.rs), ZIP 401 is implemented, and there’s clearly an
active stream of researchers filing PoC backed reports (GHSA-4fc2, -m9xx, -84j3,
-65jj). I’m not proposing to replace any of that.

What I think is missing is the layer above those one off fixes. The async timeout
and cancellation paths are hard to reproduce reliably, so bugs in that class are
awkward to test. A PoC written for one report is single vector and stops being
run once the fix lands. And ZIP 401 says eviction shouldn’t be gameable by an
adversary, but nothing exercises that under actual attack.

Issue #10684 is my main evidence. It’s a regression of the GHSA-65jj fix on the
verification timeout path, in a subsystem that already had a regression test for
a neighbouring path.

What I’d deliver: a standalone Rust crate with a deterministic mempool simulation
harness, a library of composed multi peer attack scenarios, ZIP 401 conformance
checks, standing regression coverage starting with a deterministic repro of
#10684, CI integration, and a public threat model. Anything I find goes through
coordinated disclosure.

What I’m not doing, so there’s no confusion: no input parsing or crash fuzzing
(that’s #234), no batch verification soundness (that’s #332), no external
synthetic node network testing (that’s Ziggurat, and this sits at a different
layer). I’m not touching consensus or rewriting the mempool, just testing policy
behaviour.

On impact I’d rather be straight than oversell. A mempool DoS can’t cause
counterfeiting or a chain split. What it can do is exhaust node resources,
degrade or stall transaction admission, and give a censorship vector. GHSA-4fc2
was a single peer denying mempool admission to honest peers. That’s the level
we’re at.

Budget is $18,000 for eight weeks, solo. $3,000 startup plus three milestones of
$5,000. Part of the last milestone is conditional on Ironwood APIs being stable
enough to work against.

The feedback I most want is from the Zebra maintainers. Would an external harness
like this actually be useful to you, or is it something you’d rather keep inside
your own disclosure and CI process? Either answer is fine, and it’s the main
thing I’m trying to find out before anyone spends time on it.

Thanks.

[ZCG]

Thank you for submitting your proposal. Following a thorough review by the ZCG and a period for community feedback on the forum, the committee has decided not to move forward with this proposal.

We sincerely appreciate the time and effort you invested in your application and encourage you to stay involved and continue contributing to the Zcash community.

Meeting Minutes