FNP Insert Operation Complete Flow

ELI5

When you type a character in an FNP document, six things happen in sequence: the client calculates a unique position, locks it, encrypts what you typed, proves the encryption is correct, signs the whole thing, and sends it to the server. The server verifies the signature and proof without reading your content, orders it with other edits, and sends it to other clients who decrypt only what they’re allowed to see.

Technical Deep Dive

The Complete Insert Workflow

Client Side (5 steps):

1. Generate LSEQ position — Allocate unique position identifier [⟨digit, site, counter⟩, …]
2. Encrypt position with M²-ORE — Position becomes deterministically comparable without decryption
3. Encrypt content with Kyber-1024 — Full content becomes unreadable except to recipient with shared secret
4. Generate Halo2 proof — Create zero-knowledge circuit proving “this position + content was encrypted correctly”
5. Sign with Dilithium — Append digital signature proving authenticity

Server Side (3 steps):

1. Verify Dilithium signature — Ensure operation came from authorized replica
2. Verify Halo2 proof blind — Confirm correctness without decryption
3. M²-ORE compare encrypted positions — Merge deterministically using encrypted ordering

Other Clients (3 steps):

1. Verify Halo2 proof — Can’t decrypt Alice’s content, but verify the proof is valid
2. Observe position ordering — Apply CRDT semantics using encrypted positions
3. Decrypt if authorized — Only decrypt content they have the shared secret for

End-to-End Sequence

sequenceDiagram
    participant Alice as Alice (client)
    participant Server as Server (blind)
    participant Bob as Bob (other client)
    Alice->>Alice: 1. LSEQ position
    Alice->>Alice: 2. M²-ORE encrypt position
    Alice->>Alice: 3. Kyber-1024 encrypt content
    Alice->>Alice: 4. Halo2 proof
    Alice->>Alice: 5. Dilithium sign
    Alice->>Server: Insert{lseq, ct, proof, sig}
    Server->>Server: Verify Dilithium signature
    Server->>Server: Verify Halo2 proof (blind)
    Server->>Server: M²-ORE order vs existing ops
    Server->>Bob: Insert{lseq, ct, proof, sig}
    Bob->>Bob: Verify Halo2 proof
    Bob->>Bob: CRDT merge by encrypted position
    Bob->>Bob: Decrypt content if authorised

Insert Envelope (wire layout)

The Insert message bundles the four cryptographic artefacts produced by the client. The diagram is symbolic — each field gets one slot regardless of on-wire byte width — because real parameter sizes (Kyber-1024 ciphertext ≈ 1568 B, Dilithium-3 signature ≈ 3293 B, Halo2 proof depends on circuit) are too large to draw to scale:

---
config:
  packet:
    bitsPerRow: 8
---
packet-beta
  title FNP Insert envelope
  0-7: "op_id (8 B)"
  8-15: "lseq_position (M²-ORE, ~32 B)"
  16-23: "kyber_ciphertext (~1568 B)"
  24-31: "halo2_proof (variable)"
  32-39: "dilithium_signature (~3293 B)"

Performance Characteristics

• Client computation: ~50ms (dominated by Halo2 proof generation on weak hardware)
• Network round-trip: ~10-20ms
• Server verification: ~2ms (parallel proof verification)
• End-to-end latency: ~50ms typical

Key Terms

• Proof generation → Creating a Halo2 circuit that proves correctness without revealing witness
• Blind verification → Server verifies proof without seeing plaintext
• Deterministic merge → All replicas compute identical result using CRDT rules
• Non-repudiation → Dilithium signature proves Alice signed, she can’t deny it

Q&A

Q: What if the server tries to reorder operations? A: Dilithium signatures would be invalid — any modification to the operation is detected. The server can’t reorder without an agent’s permission.

Q: How do offline clients handle concurrent inserts? A: LSEQ gives each insert a unique position based on (site, counter). When two clients insert at the same logical position offline, both positions are preserved — CRDT merge ensures convergence.

Q: Can proofs be reused across operations? A: No. Halo2 proofs are per-operation and include the operation_id in the witness. A replay attack fails because the operation_id has already been seen.

Examples

The insert flow is like registering a package: you write the address (LSEQ position), seal it (Kyber), attach a tracking number (Halo2 proof), and sign the receipt (Dilithium). The post office (server) verifies the signature and receipt, sorts by address (encrypted comparison), and delivers sealed packages.