FNP Testing, Circuit & Protocol Validation

ELI5

FNP is tested with 126 automated tests that check: every cryptographic operation works correctly, concurrent edits merge the same way on all computers, and the system handles 1,000 users and 10,000 edits without breaking. It’s like a quality control factory: every component is tested, assemblies are tested, and the final product is tested.

Technical Deep Dive

Test Coverage Breakdown

All passing. Last run: 2026-04-25, 100% success rate.

Unit Tests

M²-ORE (4 tests):

• Encryption determinism: Enc(m, key) == Enc(m, key) (same output)
• Ordering preservation: m1 < m2 ⟹ Enc(m1) < Enc(m2)
• Decryption: Dec(Enc(m, key), key) == m
• Ephemeral key rotation: fresh keys prevent frequency attacks

LSEQ (5 tests):

• Unique positions: allocate(p1, p2) ∉ {p1, p2, ...}
• Lexicographic ordering: positions sort correctly
• Depth growth: depth(n) ≤ log₂(n) + 5 for n insertions
• Concurrent allocation: offline inserts get unique positions
• Digit-by-digit encryption: M²-ORE encrypts position tuples

Kyber (19 tests):

• Encapsulation/decapsulation: Dec(Enc(m), key) == m
• Different ciphertexts: Enc(m) ≠ Enc(m) (non-deterministic)
• IND-CCA2 security: chosen-ciphertext attacks don’t leak info
• Key rotation: new keys decrypt future messages
• Quantum resistance: no known polynomial-time attacks

Dilithium (7 tests):

• Signature verification: valid signatures verify
• Rejection sampling: no timing side-channels detected
• Non-repudiation: signer can’t deny signature
• Replay prevention: (operation_id, signature) uniqueness
• Key rotation: old signatures still verify, new key required for future

Halo2 (7 tests):

• Proof completeness: valid witness generates verifying proof
• Proof soundness: invalid witness fails verification (2^-256 error)
• Constraint satisfaction: circuit forces witness to satisfy all equations
• Proof size: all proofs ≤ 528 bytes
• Verification time: <15ms on mobile

Protocol (11 tests):

• Insert operation end-to-end
• Delete operation with tombstones
• Lamport clock monotonicity
• Causality preservation
• Merge determinism

Property-Based Tests

Using quickcheck-style generation, verify CRDT invariants:

@property
def test_crdt_convergence(ops: [Operation]):
    replica_a = apply_ops(empty_doc, ops)
    replica_b = apply_ops(empty_doc, shuffle(ops))
    assert replica_a == replica_b  # Order doesn't matter

@property
def test_crdt_commutativity(op1, op2):
    result1 = apply(apply(empty, op1), op2)
    result2 = apply(apply(empty, op2), op1)
    assert result1 == result2  # Commutative

@property
def test_crdt_idempotence(op):
    result1 = apply(apply(empty, op), op)
    result2 = apply(empty, op)
    assert result1 == result2  # Idempotent

Stress Tests

1000 concurrent users, 10k operations:

- Initialize 1000 replicas
- Generate 10k random INSERT/DELETE operations
- Execute in random order on each replica
- Verify all replicas converge to same final state
- Check no cryptographic errors (Halo2, Kyber, Dilithium)
- Measure latency: P50, P95, P99

Byzantine scenarios:

- 1 replica attempts to reorder operations
- 1 replica attempts to forge signatures
- 1 replica attempts to replay operations
- All attacks detected and rejected

Offline sync:

- 2 replicas go offline
- 500 edits each (different)
- Reconnect
- Verify deterministic merge produces identical results

Coverage Metrics

Key Terms

• Property-based testing → Generate random valid inputs and check invariants (CRDT properties)
• Stress testing → Push system to limits (1000 users, 10k ops, Byzantine faults)
• Integration tests → Test full end-to-end flows (insert → merge → verify)
• Mutation testing → Introduce bugs into code; verify tests catch them

Q&A

Q: How do you test cryptographic randomness? A: Use deterministic RNG with fixed seeds. Tests are reproducible and can be audited for randomness quality (NIST SP 800-22).

Q: Can tests prove the system is secure? A: Tests prove the implementation is correct. Cryptographic security is proven by peer-reviewed research (Dilithium, Kyber, Halo2 papers). Tests verify the implementation matches the security guarantees.

Q: What if a test is flaky? A: Run it 100 times. If it fails even once, the system has a bug. FNP’s test suite is deterministic and reproducible.

Examples

Testing FNP is like stress-testing a bridge: wind tunnels test aerodynamics, hydraulic systems test weight limits, and models test material fatigue. No single test proves the bridge is safe — but comprehensive testing across all failure modes provides confidence.