Fundamentals of Cryptography

Anubis' security is built upon proven modern cryptographic primitives. This chapter will delve into the core algorithms that underpin Anubis' privacy features.

4.1 Zero-knowledge Proof System: PLONK

Anubis's choice of PLONK as its core proof system over Groth16 or STARKs is based on a deliberate set of trade-offs.

4.1.1 Why choose PLONK?

• General trust settings While the Groth16 algorithm boasts extremely small proofs and rapid verification, its fatal flaw is that each circuit requires a separate trusted setup. For Anubis, which supports arbitrary smart contracts, this means a network-wide ritual is needed every time a developer deploys a new contract, which is impractical in engineering. PLONK supports Universal Reference Strings (SRS), requiring only a single network-wide ritual (Perpetual Powers of Tau) to support any circuit logic. This ritual is led by the Ethereum community, with over 100,000 participants contributing randomness. The setup is secure as long as even one participant honestly destroys their random number. Therefore, the system is secure as long as one participant in the ritual is honest.5

• Performance balance Compared to STARKs (which have large proof sizes and high verification costs), PLONK has a constant proof size (approximately 400 bytes) and low verification gas costs, making them very suitable for on-chain environments.16

• Customizable doors PLONK supports custom constraint gates. Anubis leverages this feature to design a dedicated "Turbo PLONK" gate for Pedersen hashing and elliptic curve addition, increasing proof generation speed by 3-5 times.5。

Figure 3-3 Schematic Diagram of Anubis PLONK Core Proof System Workflow

4.1.2 Circuit design and arithmetization

Anubis transforms transaction logic into arithmetic circuits. Take a transfer circuit as an example:

Public inputs

• merkle_root: The root hash of the current Note tree.

• nullifier_old: The null terminator for the Note to be consumed.

• commitment_new: The commitment of the newly generated Note.

• contract_address: The contract for interaction (such as a DEX).

• asset_type: Asset type.

• amount: Transaction amount.

Witness/Private inputs

• note_old: Complete information about the old Note (amount, random number).

• merkle_path: The Merkle path of the old Note in the tree.

• spending_key: User's private key.

• recipient_pubkey: The recipient's public key.

• randomness: The randomization factor for new commitments.

Constraints

1. Existence proof Verify that adding merkle_path to note_old can calculate merkle_root.

2. Certificate of ownership Verify that the public key of note_old can be derived from spending_key.

3. Nullifier consistency Verify nullifier_hash = Hash(note_old, spending_key).

4. Commitment Integrity Verify that commitment_new = Pedersen(note_new).

5. Value conservation Verify

These constraints are packaged into a concise proof $\pi$ using a KZG commitment scheme for verification.

4.2 Pedersen Commitments and Homomorphic Encryption

Pedersen's promise is key to concealing the amount of the transaction.

Formula: , is the amount, is a random blinding factor. and are generators on an elliptic curve.

Homomorphic addition properties：

This allows validator nodes to verify the balance of transaction amounts (i.e., whether the sum of inputs equals the sum of outputs) without decrypting .

Range proofs: To prevent malicious users from constructing negative amounts (which manifest as extremely large positive integers in a finite field), thereby "Printing Money" out of thin air, Anubis integrates Bulletproofs or PLONK Lookup Arguments. This generates a succinct proof ensuring that the value within the commitment lies within the range $[0, 2^{64})$.6

4.3 EIP-5564 Stealth Address Protocol

4.3.1 Stealth address protection

Anubis strictly adheres to the EIP-5564 standard in building its stealth address system, aiming to break the associativity of recipient addresses in blockchain transactions. However, traditional stealth address schemes require user wallets to scan every transaction across the entire network to attempt decryption, which leads to extremely high latency and power consumption on mobile devices.

Agreement process：

1. Recipient Publish meta address:

2. Sender Generate a temporary private key, and calculate the temporary public key

3. Sharing secrets calculation Using the Diffie-Hellman key exchange protocol.

• Sender calculation

• Receiver calculation Both calculations yield the same .

1. Stealth address derivation

2. Funds sent The sender transfers assets to the address . And attach a temporary public key to the transaction .

4.3.2 Scanning and optimizing hierarchical architecture

To resolve the "Scalability-Privacy" paradox, Anubis introduces an innovative three-layer scanning optimization strategy, reducing the computational burden on the client side by several orders of magnitude.

To overcome the performance bottleneck of "recipients needing to scan the entire network," Anubis implements View Tags. The sender attaches (the first byte of the shared secret hash) to the transaction. During the scanning process, the recipient simply checks for a Tag match. If it’s a mismatch, the transaction is skipped immediately; if it matches, the recipient proceeds with the computationally expensive Elliptic Curve (EC) multiplication for decryption. This mechanism filters out 99.6% of irrelevant transactions, boosting mobile wallet synchronization speeds by 100x.

Layer 1: View tag heuristic filtering

This is the first line of defense, designed to filter out the vast majority of irrelevant transactions with extremely low computational cost.

• Mechanism When constructing a transaction, the sender calculates the hash of the shared key $S$ and extracts its first byte (1 byte) as a view_tag and appends it to the transaction metadata.

• Effect The recipient only needs to compare the view_tag on the blockchain. Since this tag is only 1 byte (256 possibilities), only about 1/256 transactions will match successfully. This means that 99.6% of irrelevant transactions are filtered out before performing costly elliptic curve multiplications.

• Privacy As the view_tag is a truncated hash, it introduces ambiguity, preventing observers from reverse-engineering the recipient's identity based on the tag alone.

Layer 2: Node-side pre-filtering (Oblivious Message Retrieval, OMR)

To address the remaining traffic filtered through Layer 1, Anubis introduced the OMR protocol, which outsources part of the search work to full nodes while ensuring that the nodes cannot know the specific content queried by the user during this process.

• Mechanism The user client generates an encrypted query structure containing its privacy features (similar to a privacy-preserving Bloom filter or an FHE-based clue detector) and submits it to the full node.

• Process The full node performs homomorphic operations or blind matching on the candidate transaction set without decrypting the user's query conditions or knowing the transaction's ownership.

• Result The node returns a very small subset of "Potentially Relevant" transactions. During this process, the node cannot determine which transactions truly belong to the user, thus resisting metadata analysis attacks.

Layer 3: Light client protocol

For the very small number of candidate transactions returned by Layer 2, the client performs the final verification locally.

• Mechanism The client does not need to synchronize full node data, but instead adopts a model similar to Ethereum Light Client.

• Process Only synchronize block headers and request Merkle Proofs for specific transactions from full nodes.

• Verify The client uses its private key locally to perform full ECDH decryption and zero-knowledge proof verification on these filtered transactions to ensure ownership of funds.

4.3.3 Scanning performance and complexity analysis

Through the three-layer architecture described above, Anubis optimizes the scanning complexity of stealth addresses from linear growth to logarithmic or extremely low constant level, significantly improving the user experience.

Scanning mode	Algorithm complexity	Calculation Cost Description
Full scan (Naive Scan)	$O(n)$	Requires Elliptic Curve Multiplication (ECC Mul) for all $n$ transactions network-wide, resulting in the lowest performance.
View Tag Optimization	$O(n) \text{ Bitwise} + O(\frac{n}{256}) \text{ ECC}$	Performs bitwise comparisons on $n$ transactions, with ECC decryption executed only for approximately $0.4%$ of them.
OMR Deep Optimization	$O(m) \text{ Verify} + O(\frac{m}{256}) \text{ ECC}$	$m$ represents a tiny candidate set returned by Layer 2 (m≤ n). The client requires minimal computational resources, making it ideal for mobile and IoT devices.

Table 3-3 Performance Comparison of Scanning Modes

This architecture not only solves the pain point of slow mobile wallet synchronization, but also lays a scalable foundation for a privacy payment network that will support hundreds of millions of users in the future.

4.4 View Key System

View keys are central to achieving regulatory-friendly and selective disclosure. Anubis employs a tiered key management system:

• Spending Key () Highest level of authority, can spend funds, never share.

• Full View Key () It can decrypt all historical transaction details (amount, sender, memo), which is usually provided to compliance auditors.

• Incoming View Key This feature allows you to view payment records only and is suitable for merchants to reconcile accounts.

• Outgoing View Key This feature allows viewing only expense records and is suitable for enterprise expense management.

Encrypted data is stored within the encryptedData field of the Note, utilizing the Elliptic Curve Integrated Encryption Scheme (ECIES). Only the party holding the corresponding View Key can decrypt and reconstruct the transaction plaintext. The View Key does not reveal the sender's "real address" (i.e., the original wallet address); it only grants visibility into the one-time stealth address used for that specific transaction. This ensures that even if a View Key is shared, the user's full identity remains untraceable.

Ability	Spending Key	Viewing Key
Initiate a transaction	√	×
Check balance	√	√
View transaction history	√	√
Identify hidden addresses	√	√
Decrypting Note Amount	√	√
Decrypting the Memo field	√	√
Decrypting receiver information	√	√

Table 3-4 Comparison of Hierarchical Key Management Permissions