Polkadot’s transition to JAM provides a unique opportunity to solve the “Original Sin” of smart contract blockchains: the lack of native privacy. However, simply deploying privacy protocols (like Aztec or Tornado Cash clones) as isolated Services / Parachains (manta?) will lead to fragmented anonymity sets and poor UX.
Recently I heard Gavin Wood advocate for client-side zk-proofs generation, and I agree with tihs. But it is clear that privacy requires state contention management (preventing double spends without revealing the spender) which the Account model doesn’t handle natively. When writting Noir on top of EVM this becomes clear right away, and you have to turn up to projects that do, like Aztec.
I propose that JAM must deploy a Canonized Privacy Service. This service should provide the bare-metal primitives for a Global Anonymity Set, specifically managing the UTXO/Nullifier state and Merkle Frontiers, while leaving the application logic to upper-layer services.
1. Private State
The Account Model while efficient for transparency, is fundamentally hostile to privacy.
Privacy protocols like Zcash and Aztec utilize an Encrypted UTXO model managed by a Nullifier Set. State is not modified in place, it is appended. This prevents double-spende without revealing the user, etc. But implementing this on general-purpose chains is a nightmare. Developers are forced to deploy custom Merkle contracts and build complex, centralized off-chain indexers to reconstruct paths, leading to “Indexing Hell.”
2. JAM: opportunity for a Global Anonymity Set
The transition to JAM shifts us from asynchronous chains to synchronous services. If we treat privacy as just another “App” layer, we risk two failures:
-
Fragmentation: A user on “Privacy App A” is not hidden among users of “Privacy App B.” The anonymity sets remain small and statistically vulnerable.
-
Broken Composability: Without a shared Nullifier standard, distinct privacy services fracture the anonymity set. A shared System Service allows distinct applications to share a unified ‘Shielded Pool’ of liquidity, even if the application logic differs. Otherwise it’s back to incoherence.
3. Proposed Architecture: JAM Privacy System Service
A Native System Service that implements the UTXO/Nullifier logic within the CoreJAM workflow. This decouples the heavy cryptography (ZK verification) from the state management (Nullifier tracking).
- Refine (Stateless Verification): This phase acts as a massively parallel verifier. It ingests client-generated Work Packages containing ZK proofs. It executes the raw verification logic on the PVM, filtering out invalid proofs without touching the global state.
- Accumulate (Nullifier Sequencer) This phase maintains the canonical Nullifier Set and the Merkle Tree Root.
-
Input: Validated Work Results from the Refine phase.
-
Logic: It checks for Nullifier collisions (Double Spends) and updates the Merkle Frontier.
-
Concurrency: To handle the parallel generation of proofs against moving state, the service must implement a State Root History (Ring Buffer), allowing proofs generated against recent roots to settle validly.
-
- Data Lake: this service could publish encrypted note ciphertexts directly to the JAM Distributed Data Lake. This creates a canonical, high-throughput stream that wallets can sync from without bloating the scarce Accumulate state with history.
Technical Requirements: For this Service to be viable, the PVM (RISC-V) may have expose Host Functions for pairing-friendly curves (BN254 or BLS12-381). Without these specific ecalls, SNARK verification may exhaust Core limits (unsure), rendering the service economically nonviable.
For privacy to be a first-class citizen, the JAM implementation must expose Host Functions for EC Pairings.
Note: Everything proposed here is admittedly above my paygrade. Contrary to @polka.dom’s advice to be assertive, I can’t say to be an expert on these topics. I’m a simple Solidity dev with some introduction to Noir and previous work in infrastructure.
However, I care deeply about privacy, JAM, and the core values of this ecosystem. I’m bringing this forward because I’m worried we might miss a critical train, one that is essential for societies relying on truly resilient sovereign systems.
This architecture might be complete bollocks. But from I’ve started to see, having some private state management as first-class citizen will become essential for blockchain tech. It may also be the case that all of this was already considered.
