自比特币诞生以来，区块链技术迎来了爆发式发展。从比特币的点对点电子现金系统，到以太坊支持图灵完备的智能合约平台，去中心化账本，不仅重新定义了货币，也正在深刻改变整个全球金融体系。
但与此同时，区块链账本完全公开透明的特点，在建立信任的同时，也成了大规模落地应用的一大阻碍。在现有的公链上，任何人都可以随意查看、追踪每一笔交易、每一个账户余额，甚至每一个NFT的流转路径。
对个人用户来说，这意味着自己的财务状况完全暴露；对企业来说，供应链关系、现金流这些商业机密很容易泄露；对机构投资者来说，对手可以通过链上数据分析，轻易摸清你的交易策略。
目前市场上也有不少隐私解决方案，但都存在明显短板。
像Zcash、门罗币这类隐私公链，采用零知识证明或者环签名，隐私保护能力很强，但它们大多不支持智能合约，或者只支持非常简单的脚本，没法运行复杂的DeFi应用。这就导致隐私资产只能躺着，没法产生收益，变成了“死钱”。
还有一类是隐私智能合约，比如Secret Network，还有基于EVM的混币工具。Secret Network需要开发者学习Rust这类新语言，和庞大的EVM生态完全脱节；而像Tornado Cash这类混币器，虽然跑在以太坊上，但只支持固定面额转账，而且缺少合规设计，很容易被非法资金利用，最终遭到监管严厉制裁。
另外还有二层隐私方案，比如基于Rollup的Aztec，虽然可以继承一层主网的安全性，但用户在一层和二层之间转移资产，要面临跨链桥的风险和延迟，而且二层流动性分散，没办法直接和一层主流DeFi协议交互。
1.2 行业核心痛点
经过深入的市场调研和技术分析，我们发现当前Web3隐私赛道，主要存在三大痛点，这也是Anubis想要重点解决的问题。
第一，EVM生态割裂。
大部分隐私公链都用自己定制的虚拟机和开发语言，以太坊生态里已经成熟的智能合约、开发工具、安全审计经验，全都没法直接复用。开发者还要重新学习复杂的电路编程语言，开发门槛极高，迁移成本大，生态很难做起来。
第二，隐私陷入“非此即彼”的困境。
传统隐私交易，会把发送方、接收方、金额、资产类型全部加密，完全变成黑盒。这么做的后果是，DeFi协议失去了可组合性。比如AMM交易所，需要知道流动性池余额，才能计算价格和滑点，如果所有余额都隐藏，AMM根本无法运行。DeFi协议没法统计TVL、交易量这些关键数据，严重限制金融应用的发展。
第三，智能合约交互存在隐私悖论。
用户在用智能合约时，面临两难选择：要么完全公开透明，交易对手、金额、投资策略全都暴露；要么完全隐私，但合约又无法验证交易是否合法，没办法正常执行。现有方案很难做到：既隐藏用户身份，又让合约正常运行公开逻辑。目前缺少一种机制，既能让合约执行公开逻辑，又能保护使用者的身份隐私。
1.3 Anubis愿景与解决方案
Anubis提出了一套全新的选择性隐私架构。核心思路很简单：把隐私变成一个可编程的功能，而不是整条链强制统一的模式。
可以公开的信息：智能合约地址、交易类型、交易金额
需要隐私保护的信息：发送方地址、接收方地址、用户真实余额
Anubis在协议层集成了零知识证明验证和双账本同步机制，实现了几个关键目标：
第一，DEX的交易量可以正常统计分析。交易资产类型和数量可以选择性公开，外部可以验证平台交易量和深度，保证市场透明可信。
第二，合约可审计。智能合约代码和执行逻辑完全公开，任何人都能检查合约有没有后门。
第三，用户不可追踪。虽然链上宏观数据公开，但通过隐身地址和零知识证明，交易发起者身份和链上历史完全隔离，没有查看权限的第三方，无法把交易和具体用户关联起来。
第四，支持合规。协议自带合规接口，用户可以向监管机构提供查看密钥或合规证明，在满足反洗钱要求的同时，保护自身隐私。
第二章 设计目标与原则
Anubis的目标，是打造一套高性能、易用、同时符合监管的隐私底层基础设施，整体有四大核心设计目标和四大原则。
2.1 核心设计目标
目标一：完全兼容EVM
Anubis不只是简单兼容EVM，而是实现完全等效。支持所有标准EVM操作码，兼容最新EIP标准；可以直接部署现有的Solidity、Vyper合约，开发者基本不用改代码；同时支持市面上主流开发工具和钱包接口，MetaMask这类钱包可以直接连接Anubis网络。
目标二：选择性隐私
打破“要么全公开、要么全隐藏”的极端模式，支持灵活的隐私等级设置。
默认隐私：用户身份默认隐藏；
选择性公开：合约地址、交易金额等信息可以公开，保证DeFi正常运行；
支持查看密钥：用户可以选择性向审计、税务等机构开放交易记录；
用零知识证明保证交易有效，比如余额充足、不双花，在不泄露真实数据的前提下，保证账本安全可靠。
目标三：高性能
隐私计算，尤其是零知识证明的生成和验证，一直是区块链性能瓶颈。Anubis做了深度优化：
出块时间2秒，用户体验更流畅；
交易吞吐量超过1000 TPS，能满足高频交易；
链上验证时间低于10毫秒；
通过底层预编译合约，把零知识证明验证放到节点底层执行，而不是跑在EVM里，大幅降低Gas成本和验证时间。
桌面端证明生成时间不到3秒。针对手机等移动设备算力不足的问题，Anubis支持委托证明生成和轻量化电路设计。用户可以把证明计算委托给可信节点，私钥不会离开自己设备；同时轻量化电路减少了一半约束条件，专门为移动端优化，保证手机钱包也能流畅使用。
目标四：符合监管
在全球监管越来越严格的环境下，隐私公链想要长久发展，必须具备合规能力。
支持通过查看密钥实现被动审计；
集成ZK-KYC，用户可以用零知识证明，在不暴露真实身份的前提下，证明自己符合合规要求；
保留反洗钱接口和黑名单功能，但必须通过去中心化治理或多签委员会管理，避免单点权限过大。
2.2 设计原则
原则一：默认隐私，自愿公开
在传统互联网里，隐私往往是后期才考虑的功能。Anubis完全反过来，把隐私设为默认状态。用户任何操作，默认使用匿名地址、加密信息，只有用户主动选择公开时才会显示，比如参与DAO治理、展示NFT等场景。
原则二：最小化信任假设
Anubis的安全，不依赖任何单一可信第三方，也不依赖特殊安全硬件。安全性完全建立在成熟密码学基础上，采用通用可信设置，只要有一个参与方诚实，整个系统就是安全的。
原则三：对开发者友好
隐私技术本身非常复杂，涉及大量高深数学。Anubis把底层复杂性全部封装起来，提供简易SDK，开发者只需要调用shield、privateTransfer这类简单接口，不用懂底层电路和证明逻辑。同时通过预编译合约，让Solidity合约可以直接验证零知识证明。
原则四：平滑渐进式迁移
现有项目可以无痛迁移到Anubis。开发者可以先把应用部署在Anubis的公开EVM层，再逐步叠加隐私功能，不用推翻原有逻辑重写整个应用。
第三章 系统架构
Anubis采用创新的三层架构，分为底层共识层、执行环境层和应用层。最核心的突破，是它的混合状态模型，实现了UTXO模型和账户模型的无缝兼容。
3.2 核心模块详解
3.2.1 Anubis EVM
Anubis基于成熟的Geth客户端深度定制，在标准EVM功能之外，增加了专门用于隐私的预编译合约。这些合约直接用Go语言底层实现，而不是跑在EVM字节码里，执行效率极高。开发者可以用这些合约，轻松实现“验证某人拥有资产，但不泄露他的身份”。
3.2.2 Note（票据）系统
为了实现隐私，Anubis在传统账户模型之外，引入了类似UTXO的Note票据模型。
每一张Note包含：承诺值、用于防止双花的无效符、公开的资产类型、被隐藏的金额、以及加密的元数据。
Note的生命周期分为三步：
创建：用户把资金从公共账户转入隐私池，生成新的Note，承诺值上链；
持有：Note只在默克尔树里记录承诺值，外界看不到持有者和真实金额；
消费：用户生成零知识证明，证明自己拥有这张Note，同时公布无效符，标记该Note已使用，防止双花。
针对交易量变大后可能出现的状态膨胀问题，Anubis做了多项优化：使用稀疏默克尔树、布隆过滤器加速校验、归档历史数据、支持无状态客户端，同时自动合并小额票据，避免因输入过多导致交易失败，保证和DeFi协议顺畅交互。
3.2.3 隐身地址注册表
Anubis内置了符合标准的隐身地址注册合约，可以理解成隐私生态的“通讯录”。任何人都可以通过对方公开身份，查到对应的元地址，生成一次性隐身地址进行转账，不需要双方提前线下沟通，既方便又保护隐私。
3.3 混合状态模型
Anubis最关键的架构创新，就是双状态同步。
• 账户状态：沿用传统结构，保存合约代码、公开余额、合约存储；
• 私有状态：基于默克尔树，保存Note票据相关数据。
每一个区块执行时，EVM会同时更新这两套状态，所有操作原子性执行，要么全部成功，要么全部回滚。
这种设计，让Anubis同时具备了UTXO模型的隐私性和并发能力，又保留了账户模型的图灵完备性，既能保护隐私，又能完美支持复杂智能合约。
ANUBIS项目白皮书 第1-3章
