# System Architecture

Anubis adopts an innovative three-layer architectural design, establishing a tight synergy among the underlying consensus, execution environment, and application layer. At its core lies a unique Hybrid State Model, enabling seamless interoperability between the UTXO and Account models.

#### 3.1 Overall Architecture Layering

<table data-header-hidden><thead><tr><th width="147.5"></th><th width="111.5"></th><th></th></tr></thead><tbody><tr><td>Layers</td><td>Components</td><td>Function Description</td></tr><tr><td>Layer 3:<br>Application layer</td><td><p>DApps &#x26; </p><p>Wallets</p></td><td>It includes DeFi protocols, NFT marketplaces, and privacy wallets. It interacts with the underlying infrastructure via the Anubis SDK, handling off-chain transaction construction and zero-knowledge proof generation (Client-side Proving).</td></tr><tr><td>Layer 2:<br>Privacy Execution Layer</td><td><p>Anubis EVM</p><p>Extensions</p></td><td>It includes a note system, a stealth address registry, and ZK-verified pre-compiled contracts. This serves as a bridge connecting privacy computing and EVM logic.</td></tr><tr><td>Layer 1:<br>Core protocol layer</td><td><p>Consensus &#x26;</p><p>Ledger</p></td><td>Responsible for achieving consensus (PoS), block proposals, and maintaining and synchronizing the State Trie &#x26; Note Tree.</td></tr></tbody></table>

Table 3-1 Anubis Three-layer Architecture Components and Functions

<figure><img src="https://2959245646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmEmETHGD25p8MAXUfWEC%2Fuploads%2FCL7AXh8aOd2w6P2VgmHH%2F01.png?alt=media&#x26;token=5d439264-40ef-4695-931a-9d33d8012454" alt=""><figcaption></figcaption></figure>

Figure 3-1 Anubis Three-Layer Architecture Diagram

#### 3.2 Detailed Explanation of Core Components

**3.2.1 Anubis EVM (Modified Geth)**

Anubis is built upon deep customization of the mature Go-Ethereum (Geth) client. Beyond standard EVM functionality, Anubis introduces a suite of privacy-focused precompiled contracts. Instead of existing as EVM bytecode, these contracts are implemented directly in Go and compiled into the node client, ensuring exceptionally high execution efficiency.

List of key pre-compiled contracts：

<table data-header-hidden><thead><tr><th width="88"></th><th width="127.5"></th><th></th><th></th></tr></thead><tbody><tr><td>Address</td><td>Name</td><td>Function</td><td>Gas Mechanism</td></tr><tr><td>0x0100</td><td>VERIFY_PROOF</td><td>Verification of PLONK zero-knowledge proof</td><td>Fixed base cost + variable cost (approximately 50k gas)3</td></tr><tr><td>0x0101</td><td>PEDERSEN_COMMIT</td><td>Calculate Pedersen commitments<br>C = g^v * h^r</td><td>Extremely low, optimized based on ECC addition.</td></tr><tr><td>0x0102</td><td>STEALTH_ADDRESS</td><td>Stealth address and shared key derived from EIP-5564</td><td>Medium difficulty, involving elliptic curve multiplication.</td></tr><tr><td>0x0103</td><td>NULLIFIER_CHECK</td><td>Check and mark null characters (to prevent double-spending).</td><td>High, including Bloom filter lookup and state writing.</td></tr><tr><td>0x0104</td><td>ENCRYPT_NOTE</td><td>Encrypt note data using the ECIES algorithm.</td><td>The length increases linearly with the data length.</td></tr><tr><td>0x0105</td><td>VIEW_KEY_DERIVE</td><td>Derive view keys at each level from the private key.</td><td>Based on curve scalar multiplication</td></tr></tbody></table>

\
Table 3-2 List of Key Anubis EVM Pre-compiled Contracts

These pre-compiled contracts allow Solidity developers to easily implement logic in smart contracts that "Verify that someone owns an asset without revealing who it is."

**3.2.2 Note-taking system**

To achieve privacy, Anubis introduces a UTXO-like "Note" model alongside the traditional account-based balance model.

**Note structure：**

*Solidity*

*struct Note {*\
&#x20;   *bytes32 commitment;   // Pedersen commitment: C = g^amount \* h^blinding*\
&#x20;   *bytes32 nullifier;   // Null symbol, used to prevent double-spending during consumption*\
&#x20;   *address assetType;  // Asset type (e.g., USDC address), publicly visible*\
&#x20;   *uint256 amount;   // Amount, hidden in the promise, or revealed in selective privacy mode*\
&#x20;   *bytes encryptedData;   // Encrypted metadata (recipient, Memo, etc.), visible only to those             holding the View Key.*\
*}*<br>

**Note lifecycle：**

* **Create (Minting/Shielding)**\
  When a user transfers funds from a public account to a private pool, a new Note is generated. Its Commitment is added to the Note Commitment Tree.
* **Holding**\
  Notes exist statically within the Merkle tree. Since only the Commitment is public, the owner and value of a Note are unknown to outsiders.
* **Spending**\
  When a user constructs a transaction, they need to generate a ZK proof to demonstrate that they possess the private key of a specific Note in the tree and disclose the corresponding Note of the Nullifier。
* **Nullification**\
  The nullifier is recorded in the nullifier set. Any transaction attempting to reuse the nullifier will be rejected, thus preventing double-spending.

**State explosion and optimization mechanism**

As transaction volume increases, the Merkle Tree and Nullifier Set can grow indefinitely. Anubis employs several optimization measures:

* **Sparse Merkle Tree**\
  Using a tree structure with a depth of 32, the theoretical capacity reaches...![](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACsAAAApCAYAAACsldDLAAAEz0lEQVR4AeyYZ8gUVxSGxzRSSSW9EJJAGukJaYS0PyGNVFJIISEJ6Z0khMT0H7H8sKFiBRUFEUVEQQUVQbCLHcWuYFes2J9n3DvOjLMf+627C8J+vO+cc8/cmXvm3HPPvfudEp1Ef01n6zVZzcieTJFtg7MXwyvgpfBU2BLO5eYD8HaojihGrdPgFoaZAcfAf+A0uAN+AfNOn4WtHVwNh8KZ0L7DkJfD41BLZ6/m7YPgX/B++CG8B86DneFHMOA0lI7wQnglvBaeD3vDl+AAaBtxDLV09m5eexfsC51SRLSZy0IoXuVyDhQ3c3keboTBhz3ov8JF8Cn4DswgdMwYq2w42GGePRueB/Mwmuaz9uu5XAV/hk/CgA0opgMieobLmTBBLZ0dz1uN7m3IKVCYl5epQHN5J1Is47IJboNrYIAfe6DUcBb8wFIziso5ew09PoE9S/wTeS/MLxJMCRxoDq2lMOA+lCfgEtgJBsxHcQwrxiz0ACN5SamxHLkLJsg769f40lX06A5dFPJ39OlwMXTa2iDL4SJuvAL90LHIUfAxuBKmsZeGRCS4Ee1huA/2gQYAcRRpZ119IzC/CV+DZ0Cd8ku7oIsbuOjA50jvIQrhVE7kzgToM7ciW+rP7eh0Lt/DC+BvcDLMIDjri37gjlP9LNK6tx8pXNFfofwEhc90QHkUFmELRj96INIV72yYzz/SdhzEcdD+Ldb3oH5YfzNRxZ7krLXOUmFRfpobpgMigQ9aAy3yGo36ZyiZBUA7Dz94cMn4N/JBWISXMbaFH0Drr+OhZmGUtIRSYtL/i8HCjsjACJsCwfg4isUcEcPF8hyaaYNIYK7upuUHPoTMw622PcbXYT+oo+b9I+iZYARnrYvpG3fSMR9dTJHlRyl1yhlR9yzgFjuSRn/oqkbEcAyn2YZ5qQx0QRnJtzG4EBExzPH30Q7CBL7Ixlwu7hyIGOZspmzE1ihyWktqZBkLTvmh5Q4hzpb11hU+KTyMvA6aIv8jLVPOTKA7mBuEUeb2UQRnLcwumBcwu2X2QBbhppRxK/paKHyxUXUxfYMhlCQj+QZtYcQtf+pWHteAC9rFuA5jmn/QXgAzCM5qNCcd0MKe+SJvQqNnDUSN4WJbEWtRZP+26LPhVOjHfoc0kpZBc/Jr2mFmrLtGD1MhfN/6/J20s/l7+bZ57H6t/RCXbtDzACLGdq5G8Q7kaOjH/4c0ty1b6b4GxTwuR/0ax7MZaMwYyjScTs+kHlLs4hTqkHqenk+HY3TadUqnaZ44KnXWXH63NJxnTQt4mNKSuXJRbc9KnLUO9mIA+xrRj9GLKgXm+kIHWhrB8mIk3a/dYj+lczr3aDYOLTkbyosHkS9xyUXS8Kln3ATlnHVBeZjwLPoWvbtCywkihtuhh5TCH3ZxjzpcipzVUZ1zC3RhDWHctKM0I7dDa2n4FaCt7sw7a91zpfvj7kVGT+/XNBP408WUcOdKjPVW0s7qqOfJXxjUXwf+9Ah7dVq66PwY93OPlHRvDNLOeqa0NLnyPcik9+q07hbrmdejX/gB2BBvg7P+Kg21tNKBPbRU2rcm/YKz/jfFiLbmpekjZWueq7pvcNY93JxtDf2fVNUDV/NgcLaaZxv+TNPZeoW8GdlmZKMoOgIAAP//i6KTqgAAAAZJREFUAwCIFc9TOmJf7gAAAABJRU5ErkJggg==)(Approximately 4.3 billion) notes, supporting efficient non-containment proofs. To address long-term state growth:
* Paid Notes Pruning\
  Nullifier Set using a hybrid approach of Bloom Filter + full storage.
* Historical state archiving\
  Historical data exceeding a certain block height can be archived to cold storage via the Merkle path.
* Stateless clients\
  Lightweight clients only require the latest Tree Root; the Merkle Path is provided on demand by full nodes.
* **Bloom filter optimization**\
  To accelerate nullifier deduplication, a Bloom filter is maintained in memory. This is a probabilistic data structure that can quickly determine whether a nullifier "absolutely does not exist" or "may exist" with minimal memory usage. If Bloom FilterReturning to "potentially exists" before performing a disk database query, significantly reduces disk I/O and improves TPS.4。
* **JoinSplit mechanism**\
  To prevent "Dust Attacks" from exceeding circuit input limits (currently capped at 4 input Notes for PLONK circuits), the SDK automatically performs background JoinSplit operations. By merging multiple small-amount Notes into a single large-amount Note, it ensures that interactions with major DeFi protocols do not fail due to input overflow.

<figure><img src="https://2959245646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmEmETHGD25p8MAXUfWEC%2Fuploads%2F75tQE7RibMmj3jIR4sOW%2F02.png?alt=media&#x26;token=c8837362-5244-41f7-b07c-fbbbc5c3102e" alt=""><figcaption></figcaption></figure>

Figure 3-2 Schematic Diagram of Anubis JoinSplit Merging Mechanism

**3.2.3 Stealth address registry**

Anubis includes a built-in stealth address registry contract compliant with the EIP-5564 standard.

*Solidity*

*contract StealthAddressRegistry {*\
&#x20;   *// User's meta address mapping (User -> MetaAddress)*\
&#x20;   *mapping(address => StealthMetaAddress) public metaAddresses;*\
\
&#x20;   *struct StealthMetaAddress {*\
&#x20;   *bytes32 spendingPubKey;   // Public key for spending: used to generate a stealth address*\
&#x20;   *bytes32 viewingPubKey;     // View public key: Used to generate the shared key (ECDH)*\
*}*\
\
&#x20;   *// Registration meta address*\
&#x20;   *function register(bytes32 spendPubKey, bytes32 viewPubKey) external;*\
\
&#x20; *// On-chain helper function: Calculates the stealth address (usually calculated by the off-chain SDK to save gas).*\
&#x20; *function generateStealthAddress(address recipient, bytes32 ephemeralPubKey) external view returns (address);*\
*}*<br>

This registry acts as the "phonebook" of the privacy ecosystem. It enables any user to look up a recipient's meta-address via their public identity (such as an ENS domain) and generate a unique stealth address for transfers—eliminating the need for real-time peer-to-peer negotiation.

#### 3.3 Mixed-State Model

The most significant architectural breakthrough of Anubis lies in its state synchronization.

* **Account state**\
  Based on Patricia Merkle Trie, it stores contract code, public balances (such as ETH balance), and contract storage.
* **Private State (Note State)**\
  Store Note Commitments based on an Append-only Merkle Tree.

**Synchronization mechanism：**

When executing a block, the EVM updates both trees simultaneously. For example, a Type 103 (privacy contract call) transaction might:

* Mark old notes as spent in the Note Tree (insert nullifier).
* Temporarily increase the contract's token balance in the Account State.
* Execute the contract logic and change the Storage Variable in the Account State.
* Insert the newly generated Note Commitment into the Note Tree.
* All state changes are atomically committed, either all succeed or all are rolled back.

This design allows Anubis to possess both the concurrent processing capabilities and privacy of the UTXO model and the Turing completeness of the account model.

<figure><img src="https://2959245646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmEmETHGD25p8MAXUfWEC%2Fuploads%2FkD9iz9MHVdgcs7qrYz5n%2FAnubis-twitter%E5%B0%81%E9%9D%A2.jpg?alt=media&#x26;token=11f3d738-a19f-4ba7-a33b-6c4540fbb809" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://anubis-network.gitbook.io/anubis-network/system-architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.