Skip to main content

​
FNP - Architecture - System Overview

​
Summary (Explain Like I’m 5)

Imagine a shared Google Doc where nobody can read your document except you, but the server can still let multiple people edit together. Fork Node Protocol (FNP) does this magic trick using three cryptographic locks:
  1. Content Lock (Kyber): Only you can read what you type
  2. Position Lock (M²-ORE): Server can order your locked characters correctly
  3. Proof Lock (Halo2): Server verifies edits are legit without seeing them

​
Technical Deep Dive

Fork Node Protocol is a collaborative encrypted document editing system combining:
  • M²-ORE (Module-LWE Order-Revealing Encryption): Enables server-side character ordering without decryption. Parameters: n=1536, k=4, q=2^56, delivering 115-bit quantum security for ephemeral ordering keys.
  • LSEQ (LogootSplit CRDT): Conflict-free replicated data structure using variable-length position identifiers [⟨digit, site, counter⟩, …] that can be encrypted digit-wise while preserving ordering.
  • Kyber-1024 (NIST FIPS 203): Post-quantum key encapsulation mechanism encapsulating 32-byte shared secrets for content encryption. Security: 128 bits quantum-resistant.
  • Halo2 Circuits: Zero-knowledge proofs verifying operation correctness (insert/delete) without decryption. Proof size: 514-528 bytes, verification: <15ms.
Three-Layer Protocol Flow:
  1. Replica generates LSEQ position, encrypts with M²-ORE
  2. Content encrypted under Kyber-1024
  3. Halo2 proof generated proving correctness
  4. Server merges deterministically using encrypted ordering
  5. Clients decrypt only content they can access

​
Mermaid Diagrams

​
Key Terms

  • M²-ORE → Module-LWE Order-Revealing Encryption; deterministic, reveals ordering but not values
  • LSEQ → LogootSplit CRDT; conflict-free identifiers with (digit, site, counter) tuples
  • Kyber-1024 → Post-quantum KEM; 128-bit quantum security, encapsulates 32-byte shared secrets
  • Halo2 → Zero-knowledge proof system using Inner Product Argument (IPA); ~514 byte proofs
  • Blind Merge → Server coordinates edits without reading plaintext using encrypted ordering
  • CRDT → Conflict-free Replicated Data Type; commutative, deterministic merge semantics
  • Replica → Individual client copy of document with local keys and operation log
  • Post-Quantum → Cryptography resistant to attacks from quantum computers

​
Q/A

Q: How does the server order encrypted characters without decryption? A: M²-ORE uses a mathematical property where m₁ > m₂ ⟺ Enc(m₁) > Enc(m₂). The comparison reveals ordering but not the exact values. It’s like weighing boxes: heavier box = bigger number, but you never open the box. Q: What prevents Alice from cheating and inserting false proofs? A: Halo2 circuits are zero-knowledge proofs that Alice must generate with the correct witness (her secret keys). Forging a proof without knowing the secrets is cryptographically hard (IPA security). Q: Can the server read my document content? A: No. Kyber encryption means only you hold the decryption key. Server sees only encrypted bytes. Even if the server stores your encrypted content forever, future quantum computers can’t break Kyber-1024. Q: What if multiple people insert at the same position simultaneously? A: LSEQ gives each edit a unique identifier based on (replica_id, lamport_clock). Both edits are preserved with deterministic ordering. Like binary tree: position 100 can split into 100.0, 100.1, etc. Q: How long does a proof take to verify on mobile? A: Estimated <15ms for Halo2 verification (IPA has O(log n) verifier complexity). In production, proofs are typically verified server-side to reduce mobile latency.

​
Example / Analogy

Restaurant Ledger Analogy: You and your business partner keep a shared expense ledger:
  • Without encryption: Partner reads everything (not private)
  • With traditional encryption: Partner can’t verify legitimacy (not collaborative)
  • With FNP:
    • Each expense is in a locked box (Kyber)
    • Box weight indicates expense amount (M²-ORE)
    • You provide unforgeable seal of authenticity (Halo2)
    • Partner can sort by weight, verify seal, never read inside
    • Multiple simultaneous entries get unique, ordered identifiers (LSEQ)
Cross-References: M2ORE Encryption, LSEQ CRDT, Kyber-1024, Halo2 Circuits, FNP Protocol Flow, Deployment Architecture Category: Architecture | Protocol Design | Cryptography Difficulty: Beginner ⭐⭐ Updated: 2025-11-28