阿努比斯
阅读时间：8分钟
- 像 Zcash 和 Monero 这样的隐私公链平台采用 ZK-SNARKs 或环签名技术，提供极其强大的隐私保护。然而，它们大多不支持智能合约，或者仅支持非常有限的脚本功能，因此无法运行复杂的 DeFi 应用。这导致隐私资产无法产生收益，沦为“死钱”。
- 隐私智能合约的例子包括 Secret Network 和基于 EVM 的混币器。前者通常需要学习一种新的编程语言（例如 Rust），从而与庞大的 EVM 开发者生态系统脱节；后者，例如 Tornado Cash，虽然运行在以太坊上，但仅支持固定面额的存款和取款，并且由于缺乏合规措施，很容易成为非法资金的滋生地，导致监管机构的严厉制裁。
- 二层隐私解决方案 基于 Rollups 的隐私层（例如 Aztec）利用了 L1 的安全性。然而，在 L1 和 L2 之间迁移资产的用户面临着跨链桥接带来的风险和延迟，而且 L2 的流动性往往分散，无法直接与 L1 上的蓝筹 DeFi 协议交互。
- EVM生态隔离 大多数注重隐私的公链都采用定制的虚拟机和编程语言。这意味着以太坊生态系统中积累的大量智能合约代码、开发工具（例如Hardhat、Foundry和Remix）以及安全审计经验无法复用。开发者需要重新学习复杂的电路编程语言（例如Circom和Leo），这大大提高了隐私应用开发的门槛。因此，开发者迁移成本高昂，生态系统发展缓慢。
- 隐私的“非此即彼”困境：传统的隐私交易会对所有信息（发送方、接收方、金额、资产类型）进行加密。这种完全黑盒的模型会导致一个严重的后果：DeFi 协议失去了可组合性。例如，自动做市商 (AMM) 需要知道流动性池中的代币余额才能计算滑点和价格。如果所有余额都被隐藏，AMM 算法将无法运行。因此，DeFi 协议无法分析交易数据并计算 TVL 和交易量等关键指标，从而阻碍金融应用的发展。
- 智能合约交互中的隐私悖论：用户在使用智能合约时面临两难选择：要么完全透明，暴露交易对手、金额和策略；要么完全隐私，但合约无法验证交易的有效性，因此无法执行。现有系统难以在“隐藏用户身份”和“公开合约逻辑”之间找到平衡。目前，尚缺乏一种机制，既能让合约执行公开逻辑，又能保护调用者的身份隐私。
- 公开可见的状态属性：智能合约地址、交易类型、交易金额
- 隐私保护状态属性：发件人地址、收件人地址、用户余额
- DEX 的交易量可以进行统计分析。交易资产的类型和数量可以（选择性地）披露，使外部观察者能够验证 DEX 的交易量和深度，从而维护市场的透明度和可信度。
- 合约可审计 智能合约的代码和状态转换逻辑是公开的，任何人都可以验证合约没有后门。
- 用户无法被追踪。虽然宏观数据公开可用，但通过隐身地址和零知识证明，交易发起者的身份与链上历史记录完全隔离。任何第三方（除非拥有查看密钥）都无法将交易与特定用户关联起来。
- 通过内置的合规界面，用户可以向监管机构出示查看密钥或合规证书，满足反洗钱合规要求，同时保护其隐私。
- 操作码支持 支持所有标准 EVM 操作码，包括最新的 EIP（例如 PUSH0）。
- 语言兼容性：它与现有的 Solidity 和 Vyper 智能合约完全兼容，开发者无需修改代码即可部署。
- 工具链兼容性支持主流开发工具（Hardhat、Foundry、Truffle、Remix）和客户端库（Web3.js、Ethers.js、Viem）。
- API 标准：它提供标准的 JSON-RPC 接口，确保 MetaMask 等钱包可以直接连接到 Anubis 网络。
- 默认隐私设置下，用户身份默认通过匿名 URL 和备注机制隐藏。
- 可选披露：合约地址和交易元数据（例如金额）应保持公开，以支持 DeFi 逻辑。
- 查看密钥支持分层查看密钥系统，允许用户选择性地向特定第三方（例如审计员或税务机关）披露交易历史记录。
- 零知识证明 (ZK) 技术用于确保交易的有效性（例如足够的余额和无双重支付），同时保持账本的完整性，而不泄露具体数值。
- 阻塞时间为 2 秒，确保良好的用户体验。交易吞吐量＞1000 TPS，满足高频交易的需求。
- 链上验证时间小于 10 毫秒。通过引入预编译合约，零知识证明验证逻辑被下推到节点底层（Go/Rust 实现），而不是在 EVM 字节码中运行，从而显著降低了 gas 成本和验证延迟。
- 生成时间证明：桌面设备的处理时间不到 3 秒。为了解决移动设备计算能力有限的问题，Anubis 引入了委托证明生成机制和轻量级电路设计，以确保移动钱包也能流畅运行。
- 授权委托书的生成用户对证人声明进行加密，并将其发送到可信的证明服务节点。节点生成证明后，会将其返回，用户的私钥不会离开设备。
- 隐私权衡警告：虽然私钥安全，但见证人包含交易元数据（金额、默克尔路径、收款人公钥等）。选择此选项意味着将详细的交易信息披露给证明服务节点。建议仅使用自托管或高度可信的证明服务。
- 轻量级电路 简化的电路针对移动设备进行了优化，减少了 50% 的约束条件，牺牲了一些功能（例如将最大输入音符数从 4 个减少到 2 个）以换取性能。
- 增量证明：证明被分解成多个小步骤，可以在后台逐步计算，使其适用于非实时交易场景。
- 支持通过视图键进行被动审计。
- ZK-KYC 集成支持基于零知识证明的身份验证，允许用户在不暴露其链上真实身份的情况下证明其符合合规要求（例如“非制裁个人”）。
- 反洗钱接口 保留监管接口并支持黑名单机制（针对非法资金），但这些必须通过去中心化治理或多签名委员会来实现。
目标 4：符合监管要求
在全球监管环境日益严格的背景下，以隐私为中心的公共区块链必须具备合规能力才能生存。
2.2 设计原则
原则一：默认隐私，自愿公开
在 Web2 时代，隐私通常只是事后补救的选项。Anubis 颠覆了这一模式，将隐私设为默认设置。用户执行任何操作时，系统默认使用匿名地址和加密信息，除非用户主动选择公开（例如，参与公共 DAO 治理或 NFT 展示）。
原则二：尽量减少信任假设
Anubis 的安全性不依赖于任何单一的受信任第三方或硬件安全模块（SGX 等）。
- 密码安全性：该系统的安全性完全基于可靠的密码学假设（例如离散对数问题和椭圆曲线配对）。
- 可信设置：它采用基于 PLONK 的通用可信系统（Universal SRS）。由于该系统源自以太坊社区主持的拥有超过 10 万名参与者的“永恒 Tau 力量”仪式，只要有一个人诚实（通过销毁随机数），整个系统就是安全的。
原则三：对开发者友好
隐私技术极其复杂，涉及深奥的数学知识。
Anubis 的核心原则之一就是将这种复杂性提炼出来。
- SDK 封装：它提供了一个高级 SDK，允许开发人员简单地调用诸如 shield() 或 privateTransfer() 之类的接口，而无需了解底层电路约束和证明生成过程。
- 预编译支持隐私原语通过 EVM 预编译合约提供，使 Solidity 合约能够直接验证零知识证明。
原则四：逐步采用
Anubis 允许现有应用程序平滑迁移。开发人员可以先将应用程序部署在 Anubis 的公共层（即标准 EVM 层），然后逐步引入隐私功能（例如为令牌添加“掩码”选项），而无需重写整个应用程序逻辑。
系统架构
Anubis 采用创新的三层架构设计，在底层共识层、执行环境层和应用层之间建立了紧密的协同作用。其核心是独特的混合状态模型，实现了 UTXO 模型和账户模型之间的无缝互操作性。
图 3-1 阿努比斯三层架构图
3.2 核心部件详解
3.2.1 Anubis EVM（修改版 Geth）
Anubis 基于成熟的 Go-Ethereum (Geth) 客户端深度定制构建而成。除了标准的 EVM 功能外，Anubis 还引入了一套注重隐私的预编译合约。这些合约并非以 EVM 字节码的形式存在，而是直接用 Go 语言实现并编译到节点客户端中，从而确保了极高的执行效率。
关键预编译合约列表：
这些预编译合约使 Solidity 开发人员能够轻松地在智能合约中实现逻辑，即“验证某人是否拥有某项资产，而不透露其身份”。
3.2.2 笔记系统
为了实现隐私保护，Anubis 在传统的基于账户的余额模型之外，引入了类似 UTXO 的“Note”模型。
Anubis 采用创新的三层架构设计，在底层共识层、执行环境层和应用层之间建立了紧密的协同作用。其核心是独特的混合状态模型，实现了 UTXO 模型和账户模型之间的无缝互操作性。
笔记结构：
固体
struct Note { bytes32 commitment; // Pedersen 承诺：C = g^amount * h^blinding bytes32 nullifier; // 空符号，用于防止消费期间的双重支付 address assetType; // 资产类型（例如，USDC 地址），公开可见 uint256 amount; // 金额，隐藏在 Promise 中，或在选择性隐私模式下显示 bytes encryptedData; // 加密元数据（收件人、备注等），仅对持有 View Key 的用户可见。 }
注音生命周期：
- 创建：（铸造/屏蔽）：当用户将资金从公共账户转移到私有资金池时，会生成一张新的票据。其承诺会被添加到票据承诺树中。
- 持有：票据在默克尔树中静态存在。由于只有承诺是公开的，因此票据的持有者和价值对外界来说是未知的。
- 消费：当用户构建交易时，他们需要生成一个零知识证明，以证明他们拥有树中特定 Note 的私钥，并披露相应的无效化 Note。
- 无效化：无效化符记录在无效化符集中。任何试图重复使用该无效化符的交易都将被拒绝，从而防止双重支付。
状态爆炸和优化
随着交易量的增加，默克尔树和无效化集可能会无限增长。Anubis 采用了多种优化措施：
- 使用深度为 32 的稀疏默克尔树，其理论容量可达……
（约34亿）张票据，支持高效的非包容性证明。 - 为应对长期状态增长：使用布隆过滤器 + 完全存储的混合方法对已付票据进行修剪无效化集。
- 历史状态归档 超过一定块高度的历史数据可以通过 Merkle 路径归档到冷存储中。
- 无状态客户端 轻量级客户端只需要最新的树根；默克尔路径由完整节点按需提供。
- 布隆过滤器优化：为了加速空值去重，内存中维护着一个布隆过滤器。这是一种概率数据结构，能够以最小的内存占用快速判断空值是“绝对不存在”还是“可能存在”。如果在执行磁盘数据库查询之前，布隆过滤器返回到“可能存在”的状态，则可以显著减少磁盘 I/O 并提高 TPS。
- 为了防止“尘埃攻击”超出电路输入限制（目前PLONK电路的输入Note数量上限为4张），SDK会自动在后台执行JoinSplit操作。通过将多张小额Note合并为一张大额Note，可以确保与主流DeFi协议的交互不会因输入溢出而失败。
图 3-2 Anubis JoinSplit 合并机制示意图
3.2.3 隐蔽地址注册表
Anubis 包含一个符合 EIP-5564 标准的内置隐蔽地址注册合约。
固体
合约 StealthAddressRegistry { // 用户元地址映射 (User -> MetaAddress) mapping(address => StealthMetaAddress) public metaAddresses; struct StealthMetaAddress { bytes32 spendPubKey; // 用于消费的公钥：用于生成隐身地址 bytes32 viewsPubKey; // 用于查看的公钥：用于生成共享密钥 (ECDH) } // 注册元地址函数 register(bytes32 spendPubKey, bytes32 viewPubKey) external; // 链上辅助函数：计算隐身地址（通常由链下 SDK 计算以节省 gas）。 function generateStealthAddress(address recipient, bytes32 ephemeralPubKey) external view returns (address); }该注册表充当隐私生态系统的“电话簿”。它使任何用户都能通过其公开身份（例如 ENS 域名）查找接收者的元地址，并生成用于转账的唯一隐蔽地址——从而无需进行实时点对点协商。
3.3 混合状态模型
阿努比斯最重要的架构突破在于其状态同步。
- 账户状态：基于 Patricia Merkle Trie，它存储合约代码、公共余额（例如 ETH 余额）和合约存储。
- 私有状态：（Note 状态）存储基于仅追加 Merkle 树的 Note 承诺。
- 在笔记树中将旧笔记标记为已使用（插入无效符）。
- 暂时增加账户状态中合约的代币余额。
- 执行合约逻辑并更改账户状态中的存储变量。
- 将新生成的票据承诺插入票据树中。
- 所有状态变更都是原子性的，要么全部成功，要么全部回滚。
同步机制
执行区块时，EVM 会同时更新两个树。例如，类型 103（隐私合约调用）交易可能：
这种设计使得 Anubis 既具备 UTXO 模型的并发处理能力和隐私性，又具备账户模型的图灵完备性。
