Skip to content

feat: FlyClient Path A library + design decision (#1555, #3479)#3909

Open
iho wants to merge 1 commit into
mimblewimble:stagingfrom
iho:feat/flyclient-path-a
Open

feat: FlyClient Path A library + design decision (#1555, #3479)#3909
iho wants to merge 1 commit into
mimblewimble:stagingfrom
iho:feat/flyclient-path-a

Conversation

@iho

@iho iho commented Jul 10, 2026

Copy link
Copy Markdown

Summary

Implements Phase 0 + Phase 1 of FlyClient for Grin, following the research plan grounded in #1555, #3479, the FlyClient paper, ZIP 221, and RFC 0018 (wtema).

Design decision (Path A)

Grin already has a header MMR and prev_root (#1555 largely done). The remaining gap is the light-client sampling + proof protocol.

Path A (this PR): no consensus change — difficulty-weighted samples + Merkle proofs against the existing header MMR + predecessor headers for wtema neighborhood checks.

Path B (deferred): VDMMR parent aggregates (paper / ZIP 221 / closed #3480) would be a hard fork; only pursue if security review shows ancestor aggregate checks are load-bearing under wtema.

Details: doc/flyclient.md

Code

Item Role
core/src/flyclient.rs SampleParams, sample_difficulty_targets, height_for_difficulty_target, FlyClientProof / FlyClientSample, verify_structure
Tests Synthetic chain prove+verify; tampered Merkle path rejected; PRF determinism

Not in this PR

  • Full-node prover against live chain (chain crate)
  • HTTP/JSON-RPC API
  • Cuckoo PoW verification on sampled headers (structural verify only; PoW is a follow-on flag/call)
  • P2P messages / light-client binary
  • Path B hard fork

Test plan

  • cargo test -p grin_core --lib flyclient (5 passed)
  • Maintainer review of Path A vs B in doc/flyclient.md
  • Follow-up: chain prover + API

Refs: #1555 #3479

…mimblewimble#3479)

Phase 0 + Phase 1 for FlyClient without a consensus-breaking VDMMR:

- doc/flyclient.md: design memo recommending Path A (sampling-only)
  given existing header MMR + prev_root and wtema DAA; Path B deferred
- core/src/flyclient.rs: difficulty-weighted sampling, proof types,
  structural verification (Merkle paths, prev linkage, difficulty order,
  inter-sample work/time bounds), binary ser/de via Writeable/Readable
- Unit tests: deterministic sampling, synthetic chain prove+verify,
  reject tampered Merkle paths

Full-node prover, API, and PoW checks on samples are follow-ups.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant