Design Goals and Principles
Anubis is designed following a set of rigorous technical goals and guiding principles, aiming to build a high-performance, easy-to-use, and compliant privacy infrastructure.
2.1 Core Design Objectives
Objective 1: Complete EVM compatibility
Anubis' primary goal is to achieve full equivalence with the Ethereum Virtual Machine (EVM), not just compatibility.
Opcode support Support all standard EVM opcodes, including the latest EIPs (such as PUSH0).
Language compatibility It is fully compatible with existing Solidity and Vyper smart contracts, and developers can deploy it without modifying the code.
Toolchain compatibility Support mainstream development tools (Hardhat, Foundry, Truffle, Remix) and client libraries (Web3.js, Ethers.js, Viem).
API Standard It provides a standard JSON-RPC interface, ensuring that wallets such as MetaMask can directly connect to the Anubis network.
Objective 2: Selective privacy
The system must support flexible privacy level configurations, breaking down the binary opposition of "fully open" or "fully hidden".
Default privacy User identity is hidden by default through anonymous URLs and the Note mechanism.
Optional disclosure Contract addresses and transaction metadata (such as amounts) should be kept public to support DeFi logic.
View Key It supports a hierarchical view key system, allowing users to selectively disclose transaction history to specific third parties (such as auditors or tax authorities).
Zero-knowledge proof ZK technology is used to ensure the validity of transactions (such as sufficient balance and no double-spending) while maintaining the integrity of the ledger without revealing specific values.
Objective 3: High performance
Privacy-preserving computation (especially the generation and verification of zero-knowledge proofs) is often considered a bottleneck for blockchain scalability. Anubis achieves high-performance metrics through deep optimization:
Block time 2 seconds, ensuring an excellent user experience.
Transaction throughput >1000 TPS, meeting the needs of high-frequency trading.
Proof verification time <10ms (on-chain). By introducing pre-compiled contracts, the ZK verification logic is pushed down to the node's underlying layer (Go/Rust implementation) instead of running in the EVM bytecode, significantly reducing gas costs and verification latency.
Proof of generation time Desktop devices achieve a processing time of less than 3 seconds. To address the limited computing power of mobile devices, Anubis has introduced the delegated proof generation mechanism and lightweight circuit design to ensure smooth operation of mobile wallets as well.
Power of attorney generation
Users encrypt and send the witness statement to a trusted proof service node.
After the node generates the proof, it returns it, and the user's private key does not leave the device.
Privacy trade-off warning: While the private key is secure, the witness contains transaction metadata (amount, Merkle path, recipient's public key, etc.). Choosing this option means disclosing detailed transaction information to the proof service node. It is recommended to use only self-hosted or highly trusted proof services.
Lightweight circuitry Simplified circuitry optimized for mobile devices, reducing the number of constraints by 50%, sacrificing some functionality (such as reducing the maximum number of input notes from 4 to 2) in exchange for performance.
Incremental proof The proof is broken down into multiple small steps, which can be computed step by step in the background, making it suitable for non-real-time transaction scenarios.
Objective 4: Regulatory friendly
In an increasingly stringent global regulatory environment, privacy-focused public blockchains must possess compliance capabilities to survive.
Auditability Support passive auditing via view keys.
ZK-KYC Integration Support zero-knowledge proof-based identity authentication, allowing users to prove they meet compliance requirements (such as being a "non-sanctioned individual") without exposing their true identity on-chain.2
Anti-money laundering interface Retain regulatory interfaces and support blacklist mechanisms (for illicit funds), but these must be implemented through decentralized governance or multi-signature committees.
2.2 Design Principles
Principle 1: Privacy by default, publicity by choice
In the Web2 era, privacy is often an option for post-hoc remedies. Anubis overturns this model, making privacy the default setting. When users perform any operation, the system uses an anonymous address and encrypted note by default, unless the user actively chooses to make it public (e.g., to participate in public DAO governance or NFT displays).
Principle 2: Minimize trust assumptions
Anubis' security does not rely on any single trusted third party or hardware security module (SGX, etc.).
Cryptographic security The security of the system is entirely based on solid cryptographic assumptions (such as the discrete logarithm problem and elliptic curve pairing).
Trusted settings It employs a PLONK-based Universal Trusted System (Universal SRS). Since this system originates from the Perpetual Powers of Tau ceremony led by the Ethereum community, with over 100,000 participants, the entire system is secure as long as even one person is honest (by destroying the random number).
Principle 3: Developer-friendly
Privacy technologies are extremely complex, involving profound mathematical knowledge. A core principle of Anubis is to encapsulate this complexity.
SDK encapsulation It provides an advanced SDK, allowing developers to simply call interfaces such as shield() or privateTransfer() without needing to understand the underlying circuit constraints and proof generation process.
Pre-compilation support Privacy primitives are provided through EVM pre-compiled contracts, enabling Solidity contracts to directly verify ZK proofs.
Principle 4: Gradual adoption
Anubis allows for a smooth migration of existing applications. Developers can first deploy their applications on Anubis's public layer (i.e., the standard EVM layer) and then gradually introduce privacy features (such as adding a "mask" option for tokens) without having to rewrite the entire application logic.
Last updated