Spark Program | QUIC Transport Validation for CKB — Benchmarking & Security Review of PR #5295
1. Team Profile
-
Applicant: DAN
-
GitHub @danblo497u-ux
-
Contact: [email protected]
-
Team size: Working independently as the sole developer and project lead — this application has no co-applicants or collaborators
2. Background / Problem
Tentacle is the multiplexed P2P networking framework underlying CKB’s node-to-node communication. The core team’s own February-April 2026 development notes listed “QUIC support for tentacle” as under exploration (tentacle#428), and as of late July 2026 a draft implementation now exists: PR #5295 (“quic: initial integration for quic”), opened by collaborator Officeyutong, integrates Tentacle QUIC support for non-WASM CKB builds, QUIC address classification/discovery/peer selection, and a dual TCP/QUIC configuration example. It remains in Draft status and unmerged.
An automated security review on that PR already surfaced 6 confirmed findings — 2 medium severity (an unbounded logger channel and a removed relay tx-verification queue trim, both potential memory-exhaustion risks under sustained load) and 4 low severity, including QUIC-specific issues (an endpoint keepalive task that can panic on slow close, and an excessively long self-signed certificate lifetime). Critically, the reviewer noted that existing broad test suites were not run locally, and real-world performance under adverse network conditions (packet loss, high latency, multi-stream load) has not been benchmarked at all.
So the gap is no longer “does a QUIC transport exist” — it’s “has anyone rigorously tested it under real conditions and validated whether the flagged issues are actually reachable problems.” Nobody has done that yet.
3. Proposed Solution
Rather than building a parallel QUIC implementation, this project focuses entirely on independent benchmarking and validation of PR #5295: running it under realistic adverse network conditions, measuring real performance numbers against the current transport, and specifically attempting to reproduce the flagged security findings (particularly the two medium-severity memory-growth issues) under sustained load to determine whether they’re reachable in practice.
This is deliberately scoped as validation work that directly supports an in-flight core-team PR, coordinated with the PR author rather than duplicating their effort — testing and hardening work the reviewer’s own comment already flagged as missing.
4. Technical Approach
-
Build and run CKB from Officeyutong’s support-quic branch (PR #5295), coordinating with the author to avoid working against a stale or soon-to-change version
-
Build a benchmark/stress-test harness comparing the QUIC transport against the current transport under identical conditions:
-
Baseline: local, low-latency connection
-
Simulated packet loss (using tc netem or similar)
-
Simulated high latency (transcontinental-like RTT)
-
Multiple concurrent streams (to test multiplexing behavior)
-
Sustained load over extended duration (to specifically probe the two flagged memory-growth findings)
-
-
Attempt to reproduce each of the 6 flagged findings under realistic conditions; document whether each is reachable, and under what circumstances
-
Measure: connection establishment time, throughput, tail latency, behavior under packet loss, CPU/memory overhead over time
-
Produce a clear, reproducible report: numbers, methodology, findings validation results, and a plain-language recommendation for the PR’s readiness
5. Week-by-Week Plan
Week 1: Build and run CKB from the support-quic branch (PR #5295); coordinate with Officeyutong on branch stability; set up baseline test environment.
Week 2: Build benchmark harness scaffolding; implement network condition simulation (loss, latency).
Week 3: Run baseline comparisons (local, low-latency) for QUIC vs. current transport.
Week 4: Run benchmarks under simulated packet loss and high latency.
Week 5: Run multi-stream/multiplexing benchmarks; begin sustained-load runs targeting the flagged memory-growth findings.
Week 6: Complete sustained-load testing; attempt to reproduce each of the 6 flagged security findings under realistic conditions; document results.
Week 7: Write up findings — numbers, charts, methodology, per-finding validation results, plain-language recommendation on production readiness.
Week 8: Buffer week / polish repo for reusability, so the core team or Officeyutong can rerun the benchmarks independently.
6. Funding Breakdown
Requested: $1,000 (in CKB, or CKB + USDI per current 50% cap)
Cost breakdown:
-
~35% — benchmark harness development and network condition simulation setup
-
~30% — running benchmark and sustained-load campaigns
-
~20% — findings reproduction and validation (the 6 flagged security items)
-
~15% — write-up and documentation
Disbursement schedule (per Spark’s standard 20/80 model):
-
Grant start — 20% ($200) upfront, released once the project is approved and the multisig wallet is set up.
-
Milestone 1 — Environment ready (end of Week 2): 25% ($250), released once PR #5295 is running locally and the benchmark harness is functional against it.
-
Milestone 2 — Core benchmarks complete (end of Week 4): 25% ($250), released once baseline, packet-loss, and high-latency benchmarks are collected.
-
Milestone 3 — Findings validated (end of Week 6): 15% ($150), released once sustained-load testing is done and each of the 6 flagged findings has a documented reproduction result (confirmed reachable / not reachable / conditions required).
-
Milestone 4 — Final report + repo polish (end of Week 8): 15% ($150), released once the public write-up is published and the repo is reproducible by a third party.
Each milestone is checked at the weekly sync per Spark norms; payment for a milestone is released once its trigger condition is demonstrably met (e.g., a passing test run, a committed dataset), not on self-report alone.
7. Deliverables & Verification
-
Open-source repo: benchmark and stress-test harness built against PR #5295, plus all raw data collected
-
Findings report: reproducible benchmark numbers across all tested conditions, plus a per-finding validation writeup for each of the 6 security findings already flagged on the PR
-
Verification method (non-code-review): anyone can clone the repo, run the benchmark harness against the same branch, and get comparable numbers and reproduction results — a concrete, independently checkable result rather than a subjective writeup
8. Current State vs. Funded Scope
-
Current state: This proposal is at the idea/design stage — no benchmark code has been written yet. The scope above was worked out after discovering PR #5295 already exists in draft form; no repo, harness, or test results exist yet on my end.
-
Funded scope: the full benchmark/stress-test harness, all condition testing (baseline, packet loss, high latency, multi-stream, sustained load), per-finding validation of all 6 flagged security items, and a written report — everything in the technical approach and week-by-week plan above. Building or modifying the QUIC transport implementation itself is explicitly out of scope — that remains Officeyutong’s PR.
9. CKB Alignment
This project directly supports an in-flight core-team pull request rather than proposing new, unreviewed scope — the goal is producing the empirical evidence and security validation that PR #5295 itself is currently missing before it could be considered for merge. It’s grounded in CKB’s actual infrastructure (tentacle is the real networking layer every CKB node runs), and it’s exactly the kind of “small but real” contribution the Spark Program’s Web5 philosophy calls for: concrete, verifiable, coordinated with the existing contributor, and useful regardless of whether the PR ultimately merges as-is, needs revision, or is reworked.