Research Traceability

Gap Closure & Evidence — SAFE Prototype

13addressed6partial3stub3out of scope

About this page

This page maps every SAFE research requirement to its implementation artifact, evidence type, and dissertation wording. Entries labeled Stub or Partial are intentional prototype-scope limitations — not software bugs. Use the filter controls below to explore by research question, status, or evidence type. Click any row to expand its evidence panel with dissertation-ready wording.

Research Question Overview

RQ1

ZKP Operational Feasibility

Evaluate whether ZK-SNARK proof protocols can operate within the timing, bandwidth, and reliability constraints of a tactical coalition sensor fusion system.

1 addressed2 partial3 stub
33%
RQ2

Adaptive Gatekeeper Architecture

Demonstrate that a policy-score-driven gatekeeper outperforms a simple proof-check baseline in distinguishing legitimate tracks from adversarial inputs under mixed conditions.

4 addressed0 partial0 stub
100%
RQ3

Dissemination & Lineage Architecture

Verify that recipient binding, Bloom-filter incest detection, and clearance-based field visibility provide adequate data provenance and access control across a multi-hop coalition topology.

3 addressed2 partial0 stub
80%

Visual Summaries

Progress by Research Question

Status Breakdown

Artifact Coverage by RQ

Requirement-to-Artifact Matrix

25 / 25 entries
IDRQCategoryRequirement / ClaimEvidenceStatus
rq1-l1-fidelityRQ1
ZKP Layer
Layer 1 — Verifiable FidelityChartStub
rq1-l2-lineageRQ1
ZKP Layer
Layer 2 — Anonymous LineageChartStub
rq1-l3-identityRQ1
ZKP Layer
Layer 3 — Physics-Based IdentityChartStub
rq1-l4-freshnessRQ1
ZKP Layer
Layer 4 — Freshness BindingSim EventPartial
rq1-l5-recipientRQ1
ZKP Layer
Layer 5 — Recipient BindingUI WidgetPartial
rq1-protocol-comparisonRQ1
ZKP Layer
ZKP Protocol ComparisonExportAddressed
rq2-policy-scoreRQ2
Gatekeeper
Policy Score ComputationChartAddressed
rq2-fusion-modeRQ2
Gatekeeper
Gatekeeper Fusion Mode SelectionSim EventAddressed
rq2-safe-vs-baselineRQ2
Gatekeeper
SAFE vs Baseline ComparisonExportAddressed
rq2-audit-logRQ2
Gatekeeper
Gatekeeper Audit LogUI WidgetAddressed
rq3-bloom-lineageRQ3
Lineage
Bloom Filter Incest DetectionUI WidgetPartial
rq3-lineage-depthRQ3
Lineage
Lineage Depth DistributionChartAddressed
rq3-epoch-rotationRQ3
Lineage
Ephemeral Epoch RotationUI WidgetPartial
rq3-clearance-visibilityRQ3
Dissemination
Clearance-Based Field VisibilityUI WidgetAddressed
rq3-attack-routingRQ3
Dissemination
Attack Type RoutingChartAddressed
sim-zk-pipelineSIM
Simulation
ZK Pipeline Panel (Per-Track)UI WidgetAddressed
sim-gatekeeper-auditSIM
Simulation
Gatekeeper Audit Trail (SIM)Sim EventAddressed
sim-coalition-threatSIM
Simulation
Coalition Threat ModelSim EventAddressed
dash-task-trackerDashboard
Dashboard
Research Task TrackerClaimAddressed
dash-sim-runsDashboard
Dashboard
Simulation Run PersistenceExportAddressed
lim-stub-proverLimitation
Limitation
Stub ZK ProverLimitationOut of Scope
lim-trusted-setupLimitation
Limitation
Simulated Trusted SetupLimitationOut of Scope
lim-no-rate-limitingLimitation
Limitation
No Server-Side Rate LimitingLimitationOut of Scope
lim-no-byzantineLimitation
Limitation
Limited Byzantine Fault InjectionLimitationPartial
lim-audit-log-persistenceLimitation
Limitation
In-Memory Audit LogLimitationPartial

Prototype Scope & Limitations

Stub ZK Prover

Requires Crypto Infra

All proof generation uses calibrated timing with random hex proof strings. No real PLONK/GROTH16/STARK circuits.

•"Not a software bug — real ZK circuit compilation requires native toolchain (circom, snarkjs, or Noir)."

•"Timing calibrated against published PLONK benchmarks on commodity hardware."

•"Future work: integrate a real PLONK prover (e.g., Bellman or Halo2) as a backend service."

Simulated Trusted Setup

Requires Crypto Infra

Trusted setup ceremony is simulated as a version string. No real structured reference string (SRS) is generated or consumed.

•"PLONK/GROTH16 require a one-time or per-circuit trusted setup ceremony."

•"Prototype uses a static string "universal-srs-v2" to mark the concept without executing it."

•"Production: use a universal SRS (Powers of Tau) or a per-circuit Groth16 ceremony."

No Server-Side Rate Limiting

Future Work

Gatekeeper rate limiting is not implemented. A production deployment would throttle proof verification requests per node.

•"Rate limiting is a deployment concern outside prototype scope."

•"Future work: implement token-bucket rate limiter at gatekeeper ingress per coalition node."

Limited Byzantine Fault Injection

Future Work

Replay, incest, and proof spoof attacks are simulated. Deep Byzantine fault injection (e.g., Sybil nodes with colluding proofs) is not fully modelled.

•"Prototype simulates three adversarial modes: replay, incest, and link degradation."

•"Deep Byzantine modelling (colluding proof-spoofing nodes) is out of scope for Phase 1."

•"Future work: add multi-node coalition Byzantine scenarios with collusion detection."

In-Memory Audit Log

Prototype Scope

Audit log in the UI components resets on page reload. sim_events table now provides persistent per-event storage for exported runs.

•"UI audit log is ephemeral. Persistent evidence available via Simulation Exports → save run → sim_events table."

•"Not a software bug — extending to full persistent audit trail requires server-side log stream."