Deposit and Commitment Creation

Protocol Description

A deposit transaction creates three primary on-chain artifacts: a cryptographic commitment $(C)$, a cryptographic linker $(L_D)$, and a zero-knowledge proof $(\pi_D)$ attesting to their consistency.

Commitment Structure

The commitment $C$ is a nested hash that binds the user to all public and private details of the deposit.

$$C \triangleq \text{Poseidon}( V, I, \text{Poseidon}( s, n, pk_{U, \text{low}}, pk_{U, \text{high}} ), pk_{SOL, 1}, pk_{SOL, 2}, \text{amount}, pk_{\text{mint}, 1}, pk_{\text{mint}, 2}, Y, M, D, h, m, s )$$

Commitment Components

• V, I: Version and index parameters
• Inner Hash: $\text{Poseidon}(s, n, pk_{U, \text{low}}, pk_{U, \text{high}})$
  • $s$: Random secret for hiding
  • $n$: Nullifier for double-spend prevention
  • $pk_{U, \text{low}}, pk_{U, \text{high}}$: Recipient Umbra address (split)
• Public Keys: $pk_{\text{SOL}, 1}, pk_{\text{SOL}, 2}$ (depositor's Solana keys)
• Amount: Deposit amount
• Mint Keys: $pk_{\text{mint}, 1}, pk_{\text{mint}, 2}$ (token mint information)
• Timestamp: $Y, M, D, h, m, s$ (year, month, day, hour, minute, second)

Deposit Linker Hash

The linker hash $L_D$ allows a viewer with the ITK to link a transaction to a recipient.

$$L_D \triangleq \text{Poseidon}(k_{ITK, D}, pk_{U, \text{low}}, pk_{U, \text{high}})$$

Linker Components

• ITK: Individual Transaction Key for deposit $k_{\text{ITK}, D}$
• Recipient Address: $pk_{U, \text{low}}, pk_{U, \text{high}}$ (same as in commitment)
• Purpose: Enables authorized viewers to link deposits to recipients

Deposit Proof Statement

A ZK-SNARK proof $\pi_D$ is generated and submitted with each deposit. It proves knowledge of a private witness $w$ for a set of public inputs $x$.

Private Witness $(w)$

Consists only of the secret inputs:

• The Solana MVK $(k_{\text{MVK}, \text{SOL}})$
• The recipient Umbra public key $(pk_U)$
• The random secret $(s)$
• The nullifier $(n)$

Public Inputs $(x)$

Consist of all other transaction parameters:

• The final commitment $(C)$
• The linker hash $(L_D)$
• The on-chain commitment to the MVK $(\text{MVK\_commitment})$
• The timestamp
• The depositor's Solana public key
• The amount
• Other public parameters

Proof Demonstrates

1. MVK Knowledge: The public $\text{MVK\_commitment}$ is a valid commitment to the private MVK, $k_{\text{MVK}, \text{SOL}}$
2. ITK Derivation: The Individual Transaction Key $k_{\text{ITK}, D}$ was correctly derived from $k_{\text{MVK}, \text{SOL}}$ and the public $\text{timestamp}$
3. Linker Integrity: The public linker hash $L_D$ was correctly computed using the derived $k_{\text{ITK}, D}$ and the recipient Umbra address $pk_U$
4. Commitment Consistency: The public commitment $C$ was correctly computed using the same recipient Umbra address $pk_U$ that was used to create the linker hash

Security Analysis

Security Proof: Deposit Security

Assumptions: Poseidon is a collision-resistant hash function; the ZK-SNARK system is zero-knowledge and sound.

Argument:

1. Commitment Hiding/Binding: The inclusion of the random secret $s$ ensures $C$ is hiding. Collision resistance ensures it is binding.
2. Linker Privacy: $L_D$ is a PRF output keyed by the secret $k_{\text{ITK}, D}$. To an observer, it is indistinguishable from random noise.
3. Deposit Integrity: The soundness of the ZK-SNARK $\pi_D$ guarantees that a malicious depositor cannot create a proof where the linker and commitment are for different recipient addresses.

Properties

Commitment Properties

• Hiding: Random secret $s$ prevents commitment revelation
• Binding: Collision resistance ensures commitment binding
• Comprehensive: Includes all transaction parameters
• Verifiable: Publicly verifiable without revealing secrets

Linker Properties

• Private: Only derivable by holders of the ITK
• Consistent: Uses same recipient address as commitment
• Unlinkable: Appears random without the ITK
• Authorized Access: Enables authorized transaction viewing

Proof Properties

• Zero-Knowledge: Reveals no private information
• Sound: Cannot prove false statements
• Consistency: Ensures linker and commitment match
• Verifiable: Publicly verifiable proof validity