Skip to main content

​
4.1 Role of Zero-Knowledge in Abyss

Zero-knowledge proofs are the core enforcement mechanism of Abyss. They allow users to demonstrate that a withdrawal or state transition is valid without revealing the underlying secrets that establish ownership or linkage to prior deposits. In Abyss, zero-knowledge does not sit at the periphery as an optimization. It is the protocol’s primary authorization system. Formally, every withdrawal from the anonymity pool must be accompanied by a proof that asserts the existence of a prior valid deposit, the possession of the corresponding secret, and the non-use of that deposit’s nullifier. The verifier contract checks this proof deterministically, without learning which deposit is being spent or how many withdrawals have previously occurred.

​
4.2 Proof System Choice

Abyss uses succinct non-interactive arguments of knowledge (ZK-SNARKs) due to their compact proof size and constant-time verification characteristics. These properties are critical for EVM compatibility, where gas costs impose strict constraints on computation. Proof generation occurs off-chain, while verification is enforced on-chain. The protocol assumes standard cryptographic hardness assumptions, including:
  • Knowledge of exponent assumptions
  • Collision resistance of hash functions
  • Soundness and completeness of the underlying SNARK construction
No trusted intermediary is involved in proof validation once parameters are established.

​
4.3 Statement, Witness, and Public Inputs

Each proof in Abyss asserts a statement of the following form: 
“I know a secret s and a commitment C such that:
  1. C exists in the commitment set
  2. H(s) = C
  3. nullifier(s) has not been used before
  4. withdrawal_amount ≤ remaining_balance(s)
”
The witness includes:
  • The secret key
  • Internal accounting data for remaining balance
  • Merkle path data proving inclusion in the pool
The public inputs include:
  • The Merkle root of the anonymity pool
  • The nullifier hash
  • The withdrawal amount
  • The recipient address
This separation ensures that ownership is proven without disclosure.

​
4.4 Merkle Tree Commitments

Deposits are represented as leaves in a Merkle tree. The tree root represents the canonical state of the anonymity pool at a given time. Users include Merkle proofs inside their ZK circuit to show membership without revealing position. Merkle roots are periodically updated on-chain: 
function updateRoot(bytes32 newRoot) external;
Only roots corresponding to valid deposits are accepted.

​
4.5 Soundness and Finality

Once a proof verifies:
  • The withdrawal is final
  • The nullifier is permanently marked as spent
  • No further linkage is possible on-chain
The protocol does not support proof revocation or discretionary rollback. This finality is essential for trust minimization and composability.

​
4.6 Design Implications

By making zero-knowledge the sole authorization mechanism, Abyss eliminates address-based permissions entirely at the withdrawal layer. Control flows from cryptography, not identity. This allows the protocol to support advanced behaviors, such as infinite withdrawals from a single deposit, without introducing additional trust assumptions.