docs

Reference

Research

Forward-secure, post-quantum-ready note encryption, and ideas that were rejected.

Copy Markdown

Research, not a commitment

Nothing on this page changes the circuit or promises a launch feature.

The problem

Each transaction carries two encrypted notes that stay on-chain forever. If a viewing key leaks, every past note encrypted to it can be read. And if the key exchange is elliptic-curve only, someone can store the ciphertexts now and decrypt them once a large quantum computer exists.

The commitments and nullifiers use a hash and are fine. The proof system (UltraHonk over BN254) is not post-quantum: a quantum attacker could forge proofs, not read old notes. So the ciphertext is the privacy gap that matters first.

Proposal

  • Hybrid key exchange. Combine an elliptic-curve exchange with ML-KEM-768, so an attacker has to break both.
  • A versioned ciphertext format, with an epoch field from day one, so epoch keys can be added later without a format change.
  • Fixed-length plaintext, so ciphertext size reveals nothing.
  • Ciphertexts in event data, not storage. About 1.2 KB each, so about 2.4 KB per two-note transaction. Real cost on Robinhood Chain is not measured.

Epoch keys (optional, later)

  • A cold master key with per-epoch hot keys limits the damage of a device leak and allows date-range disclosure. It is not strict forward secrecy.
  • Per-epoch ML-KEM keys must be generated and published in advance, and looking them up can reveal who is receiving.
  • Tree-based forward-secure encryption gives strict forward secrecy and is large and slow. Out of scope for now.

Moving to a post-quantum proof system

The pool is immutable, so a new proof system means a new pool version. The plan is to design for it now: a next version whose circuit accepts the old pool's nullifiers, so users migrate without a public unshroud and reshroud. "Post-quantum" will not be used as a claim until commitments, proofs and encryption all are.

Rejected ideas

  • Replacing the Merkle tree with lattice ring signatures: smaller anonymity sets, huge signatures, no EVM support.
  • Security tiers picked by a threat oracle: needs an admin and splits the anonymity set.
  • Private computation with homomorphic encryption: impractical on the EVM.
  • Notary-set bridges: add a trusted set. A ZK light-client proof is the better tool.
  • Nullifiers that stop being linkable after some epochs: allows double spends.