Encrypted Balance Claim

Protocol Description

A claim transaction publishes a nullifier hash $(nh)$, a claim linker hash $(L_C)$, and a ZK-proof $(\pi_C)$.

Nullifier Hash

The nullifier hash prevents double-spending. It is derived from the secret nullifier $n$ of the commitment being spent.

$$nh \triangleq \text{Poseidon}(n)$$

Nullifier Properties

• Double-Spend Prevention: Ensures each commitment can only be spent once
• Secret-Based: Derived from the private nullifier $n$
• Public Verification: Can be publicly verified without revealing the nullifier
• Uniqueness: Each commitment has a unique nullifier

Claim Linker Hash

The claim linker hash $L_C$ allows a viewer with the claim's ITK to link the claim action to the specific commitment that was spent.

$$L_C \triangleq \text{Poseidon}( k_{\text{ITK}, C}, I )$$

Linker Components

• ITK: Individual Transaction Key for claim $k_{\text{ITK}, C}$
• Commitment Index: $I$ (the index/ID of the commitment being spent)
• Purpose: Enables authorized viewers to link claims to specific commitments

Claim Statement

The ZK-SNARK proof $\pi_C$ attests that the prover knows a private witness for a set of public inputs.

Public Inputs $(x)$

• The Merkle tree root $(\text{root})$
• The nullifier hash $(nh)$
• The claim linker hash $(L_C)$
• The on-chain commitment to the Umbra MVK $(\text{MVK\_commitment})$
• The claim $\text{timestamp}$

Private Witness $(w)$

The secret details of the commitment being spent:

• $(s, n, pk_{U_i}, I, \text{path})$ - commitment secrets and Merkle proof path
• The corresponding Umbra secret key $(sk_{U_i})$
• The Umbra MVK $(k_{\text{MVK}, U_i})$

Proof Demonstrates

1. Ownership: The prover knows the secrets for a valid commitment $C'$ at index $I$ in the Merkle tree
2. Nullifier Correctness: The public $nh$ corresponds to the secret nullifier $n$
3. MVK Knowledge: The public $\text{MVK\_commitment}$ is a valid commitment to the private MVK, $k_{\text{MVK}, U_i}$
4. ITK Derivation: The key $k_{\text{ITK}, C}$ was correctly derived from $k_{\text{MVK}, U_i}$ and the public claim $\text{timestamp}$
5. Linker Integrity: The public claim linker hash $L_C$ was correctly computed using the derived $k_{\text{ITK}, C}$ and the private commitment index $I$

Security Analysis

Security Proof: Claim Security

Assumptions: The ZK-SNARK system is zero-knowledge and sound; the smart contract correctly enforces nullifier uniqueness.

Argument:

1. Anonymity: The zero-knowledge property of $\pi_C$ ensures the proof reveals no information about which specific commitment is being spent.
2. Double-Spend Prevention: The soundness of the proof ensures a user must reveal the correct $nh$ for the commitment they are spending. The contract will reject any previously seen $nh$.
3. Linker Privacy & Integrity: The claim linker $L_C$ is a PRF output and appears random. The soundness of the proof ensures that the public $L_C$ is correctly tied to the specific, confidential commitment index $I$ being spent.

Claim Process

Prerequisites

1. MVK Registration: The Umbra MVK must be registered on-chain
2. Valid Commitment: Must have a valid commitment in the Merkle tree
3. Merkle Proof: Must have a valid Merkle proof path to the commitment

Transaction Components

1. Nullifier Hash: Public proof of spending authorization
2. Claim Linker: Links claim to specific commitment (for authorized viewers)
3. ZK Proof: Proves ownership and validity without revealing secrets
4. Merkle Proof: Proves commitment exists in the tree

On-Chain Verification

• Nullifier Uniqueness: Contract checks that $nh$ hasn't been used before
• Proof Validity: Verifies the ZK-SNARK proof
• Merkle Tree: Validates the Merkle proof path
• MVK Commitment: Verifies the MVK commitment matches

Properties

Anonymity Properties

• Unlinkable: Claims cannot be linked to deposits without the ITK
• Zero-Knowledge: Proof reveals no private information
• Random Appearance: Linker hash appears random to observers
• Selective Disclosure: Only authorized parties can link transactions

Security Properties

• Double-Spend Prevention: Nullifier system prevents double-spending
• Ownership Proof: ZK proof proves ownership without revealing secrets
• Integrity: Ensures claim corresponds to valid commitment
• Binding: Commits to specific commitment index privately

Compliance Properties

• Audit Trail: Provides cryptographic audit trail for authorized parties
• Regulatory Support: Enables compliance with regulatory requirements
• Selective Disclosure: Allows disclosure to authorized entities
• Transaction Monitoring: Supports transaction monitoring capabilities