阿努比斯
阅读时间：10分钟
选择性隐私协议模型
Anubis 并不强制要求所有交易完全匿名；相反，它提供了一系列隐私选项，以适应不同的应用场景。
5.1 隐私分类的定义
5.2交易类型详细说明（基于 EIP-2718）
为了在完全兼容现有以太坊基础设施（例如 MetaMask 钱包和 Etherscan 区块浏览器）的同时引入复杂的隐私语义，Anubis 网络采用了 EIP-2718 类型化交易信封标准。这一设计决策使我们能够定义全新的隐私交易有效载荷，而不会破坏传统的 EVM 交易结构，从而实现从公共账本到私有账本的无缝状态转换。
Anubis 协议保留了以太坊主网的标准交易类型（传统 0x00、EIP-2930 0x01 和 EIP-1559 0x02），这些类型被归类为 0 级（完全公开）交易，用于处理非私有资产转移和合约交互。为了实现隐私层功能，Anubis 在 0x70 到 0x73 范围内引入了四种核心私有交易类型。这些交易类型不仅促进了“公共账户模型”和“私有票据模型”之间的资产流动，还定义了私有状态下的价值转移和智能合约互操作性的逻辑。
5.2.1 交易类型概述
表 5-2 Anubis 交易类型概述
5.2.2 类型 0x70：块交易
交易阻塞是用户进入Anubis隐私生态系统的入口。从系统架构的角度来看，这是一种“锁定和增发”操作：公共账户中的资产被锁定到Anubis隐私流动性池合约中，并在隐私状态树中创建等量的票据。
RLP编码结构：
事务类型 0x70 | | rlp()
执行逻辑和隐私边界
- 资产锁定（公共层）： EVM 执行环境首先从发送方（msg.sender）处扣除价值（ETH），或者调用 ERC-20 transferFrom 函数将代币转移到隐私池合约。此步骤完全在链上公开，观察者可以知道“谁”存入了“多少”资产。
- 承诺插入（隐私层）：系统验证 noteCommitment（属于 BN254 标量场）的格式，并将其作为叶节点插入到全局 Note Merkle 树中。
- 事件启动：发出 Shield(地址索引自, bytes32 承诺, uint256 金额) 事件。
- 隐私分析：虽然存款是公开的，但生成的承诺票据会切断资产与后续支出之间的联系。一旦资产转换为票据，外部人员就无法追踪票据的支出时间或将其与未来的提款关联起来（除非金额具有极其独特的特征，因此建议使用 10、100 和 1000 等标准面额）。
5.2.3 类型 0x71：隐私传输
这是阿努比斯网络中隐私保护级别最高的交易类型（3 级）。对于外部观察者而言，它是一串不可读的二进制数据和零知识证明，因此不可能推断出发送者、接收者或具体的转账金额（依赖于佩德森承诺的同态隐藏特性）。
RLP编码结构：
交易类型 0x71 | | rlp([ chainId, nonce, // 用于支出密钥的随机 nonce（不是账户 nonce），用于
// 防重放保护。maxPriorityFeePerGas、maxFeePerGas、gasLimit、nullifiers、// 输入票据的可空值列表 [nullifier_1, nullifier_2,...] commitments、// 输出票据的承诺列表 [commitment_1, commitment_2,...] ephemeralKey、// 临时公钥，用于 ECDH 密钥协商 encryptedCiphertext、// 加密后的票据密文（包含金额、收款人和备注）。
// 仅可通过接收方的查看密钥解密。zkProof，// PLONK 零知识证明 v, r, s // 绑定签名 ])
核心机制详解：
- 输入/输出平衡约束：ZK 证明的核心逻辑是约束。
。这样可以确保货币供应量的安全。 - 用于去重和防止双重支付的无效化器：对于每个输入的票据，电路会生成一个唯一的无效化器：nullifier = H(spending_key, note_position,...)。验证节点通过哈希计算检查该无效化器是否已存在于全局无效化器集合中。如果存在，则拒绝该交易。此机制完美地解决了双重支付问题，同时保护了隐私。
- 绑定签名：为了防止恶意中继节点篡改交易费用或收款人信息，交易必须使用消费密钥通过交易哈希进行签名。由于消费密钥始终保留在用户设备内，因此这种签名方式确保了交易的不可否认性和完整性。
5.2.4 类型 0x72：隐私合约调用
这是 Anubis “选择性隐私”架构的基石，允许用户使用私有身份与标准的、完全公开的 EVM 合约（如 Uniswap、Aave 和 Compound）进行交互。
RLP编码结构：
事务类型 0x72 | | rlp()
执行流程和即时账户机制：
- 预验证阶段：节点首先验证 zkProof，以确认用户拥有与无效化符对应的资产，并且金额满足守恒关系：输入备注总价值 = 公共价值 + 新增承诺 + 手续费。此步骤确保用户没有凭空创造货币。
- 临时资金：系统会在执行环境中临时创建一个虚拟的临时账户。然后，它会将隐私池中公共价值数量的资产“注入”到该账户中。
- EVM 调用执行：使用即时帐户作为 msg.sender 执行 targetContract.call(calldata)。
- 隐私边界目标合约（例如 Uniswap）只能看到即时账户地址，而无法追踪其背后的真实用户地址或历史记录。
- 数据透明度：调用数据（例如，swap(tokenA, tokenB, amount)）是公开的。这体现了Anubis“公开交易逻辑，匿名交易者身份”的设计理念。市场参与者可以追踪交易量，但无法分析交易者的特征。
- 状态清理和资产回收：调用结束后，瞬时账户中剩余的任何资产（例如通过交换获得的代币 B）都必须被“回收”。交易结构包含指示系统将瞬时账户余额打包到与 newCommitments 对应的输出备注中的指令。如果瞬时账户中仍有未处理的余额，则交易将被回滚。
5.3 合同互动中的隐私保护和模式
在Anubis的设计中，隐私不再是非此即彼的二元对立（完全公开或完全隐藏），而是一个可配置的连续谱。通过0x72类型的交易，开发者可以构建复杂的、以隐私为中心的DeFi应用。本节将深入探讨去中心化金融（DeFi）场景中的具体实现模型和隐私权衡。
5.3.1 AMM DEX 的隐私交互模式
在传统的隐私币模型（例如 Zcash）中，用户无法直接与 Uniswap 交互，因为 AMM 是一个公共函数。
交互序列图
- 链下计算（客户端）：
- 用户持有票据
（例如，价值 1000 USDC）。 - 用户想要将 500 USDC 兑换成 ETH。
- ZK电路生成证明
该授权有效，用户已授权将 500 USDC 用于此次调用。 - 生成变更说明
（500 USDC）。
- 链上执行：
- 步骤 1（系统）验证证明，然后销毁
（记录清零器） - 步骤 2（系统）系统创建一个临时地址 0xTemp... 并向其中注入 500 USDC。
- 步骤 3 (EVM) 0xTemp 调用 Uniswap 路由器：swapExactTokensForETH(500 USDC,...)。
- 步骤 4（EVM）：Uniswap 计算价格并将 ETH 发送回 0xTemp。此过程在链上完全透明，任何观察者都可以看到有 500 USDC 的买单。
- 步骤 5（系统）系统拦截了 0xTemp 收到的 ETH，并根据交易附带的指令，将其封装到一个新的隐私声明中
。 - 步骤 6（系统）插入
（美国内贸易委员会）和
（ETH）承诺进入默克尔树。） - 步骤 7（系统）销毁瞬时地址 0xTemp。
隐私分析：
- 观察者的视角：观察一个随机生成的地址与 Uniswap 交互，执行一笔交易，然后停止活动。我们无法知道这个地址属于谁，也无法将其与之前的交易关联起来。
- 分析价值：由于交易金额和代币类型是公开的，因此仍可准确衡量 TVL（总锁定价值）和 DeFi 协议的交易量等关键指标，这对于生态系统的健康发展至关重要。
5.3.2 跨合同的组成
Anubis 的架构允许隐私交易在单个原子交易中调用多个合约，从而保持以太坊强大的可组合性。
例如：隐私杠杆贷款
1.用户可以通过一次 0x72 交易完成复杂的“闪电贷+杠杆”操作：
2.从隐私说明中解包 ETH。
3.致电 Aave 存入 ETH 作为抵押品。
4.致电 Aave 借入 USDC。
5.使用 Uniswap 将 USDC 兑换成 ETH。
6.再次存入 Aave（循环贷款）。
7.最终的债券凭证（aToken）将以隐私声明的形式封装。
证明资产所有权的挑战与解决方案：
在上述过程中，Aave 将 0xTemp 记录为债务人。然而，0xTemp 是临时的，交易完成后即失效。
解决方案：隐私代理注册表
1.用户预先部署长期有效的隐私代理协议。
2.0x72 该事务不直接对 Aave 进行操作，而是使用 Proxy 命令进行操作。
3.代理人持有债券头寸（aToken）。
4.代理的控制权通过零知识证明（持有特定的查看密钥或支出密钥签名）来管理。这样，虽然代理地址是公开的，但代理的控制者仍然是私密的。
5.3.3 选择性隐私实施——以去中心化交易所交易为例
solidity // DEX 合约（公开部分）合约 AnubisSwap { event Swap( address indexed tokenIn, address indexed tokenOut, uint256 amountIn, uint256 amountOut, bytes32 proofHash, // 关联的隐私证明 );
function swap( address tokenIn, address tokenOut, uint256 amountIn, uint256 minAmountOut, bytes calldata zkProof, // 零知识证明 bytes32 noteCommitment // 新票据承诺 ) external returns (uint256 amountOut) { // 1. 验证零知识证明（证明发送方拥有足够的资产） require( verifyProof(zkProof, noteCommitment, amountIn), "无效证明" );
// 2. 执行换股逻辑（标准 AMM） amountOut = _swap(tokenIn, tokenOut, amountIn); require(amountOut >= minAmountOut, "Slippage"); // 3. 创建输出票据 _createNote(tokenOut, amountOut, noteCommitment);
// 4. 发布公共事件（用于分析） emit Swap(tokenIn, tokenOut, amountIn, amountOut, keccak256(zkProof)); } }
链上可见信息：
DEX合约地址、交易对（USDC/WBTC）、交易金额（5000 USDC → 0.1 WBTC）、时间戳
区块链上不可见的信息：
交易发起人的真实地址、发起人的交易历史记录以及发起人的总资产。
5.4 监管合规框架
Anubis 坚信，可持续的隐私保护区块链必须在保护用户基本权利和打击洗钱、恐怖主义融资等非法金融活动之间取得平衡。我们提出了一种“可编程合规性”架构，该架构利用零知识证明技术来实现“在不损害隐私数据的情况下证明合规性”。Anubis 提供可选的合规性机制：
- 查看关键信息披露：用户可以选择向监管机构提供查看关键信息。
- 合规性证明：证明资金来源的合法性，但不要透露具体的资金来源。
- 阈值解密：只有通过多个机构的合作，才能破译特定的交易。
- 可审计资金池：可选的 KYC 资金池提供更高的限额。
- ZK-KYC（零知识认证）：用于证明“我不在制裁名单上”，而无需透露“我是谁”。
5.4.1 ZK-KYC 身份验证协议
传统的 KYC（了解你的客户）流程要求用户在链上上传护照或个人信息，这会损害用户隐私并带来严重的数据泄露风险。Anubis 集成了基于 ICAO 电子护照标准的零知识 KYC 解决方案。
图 5-1 ZK-KYC 身份验证流程图
技术实施过程：1.信任锚点
- 该系统利用现有的电子护照基础设施。全球超过170个国家签发的电子护照芯片中包含由国家认证中心签发的数字签名。
2.客户端验证
- 用户可以使用支持 NFC 功能的手机读取护照数据（包括照片哈希值、个人信息和国家签名）。
- 在本地运行 ZK 电路，输入：护照隐私数据。
- 电路逻辑验证：验证护照签名的有效性（使用链上国家公钥注册表）。
- 护照经核实有效。
- 确认用户不在国际制裁名单上（通过 Merkle Inclusion Proof 验证 OFAC 和其他制裁名单快照）。
- 输出一个零知识证明
身份代币铸造（SIT铸造）：
- 用户将提交
- 合约验证成功后，将铸造一个 Soulbound 身份代币 (SIT) 并将其绑定到用户的私有地址（使用无效化机制防止从同一护照生成多个 SIT）。
许可池的应用：
DeFi 协议（例如 Aave Arc 或 RWA 资产平台）可以通过配置修饰符，使其仅接受来自有效 SIT 地址的交互：
固体
modify onlyCompliant() { require(IdentityRegistry.verifyCompliant(msg.sender), "ZK-KYC required"); _; }
这样，组织就可以让用户在完全合规的环境中进行私密交易，满足监管要求，而无需向外界或竞争对手披露其交易策略。
5.4.2 视图键的分层披露机制
Anubis 采用分层密钥系统，严格地将消费权限与查看权限分离，为审计提供了技术基础。
- 消费键（
）：有最高权限，用于生成零知识证明，但会产生费用。永远不会离开用户的设备。 - 传入视图键（
）：允许解密已接收的交易（金额、发送方）。
- 出站视图键（
）：允许解密已发送的交易。
审计计接口和场景：
企业用户可以主动提供
- 解密用户的所有历史交易详情（时间、金额、交易对手）。
- 在链上验证所有交易是否确实发生且未被篡改。
- 限制保证：审计员无法支出资金或查看用户与其他地址的交互（除非另一方也披露了查看密钥）。
该机制完美地复制了传统银行系统的“只读访问”，使公司能够在满足财务审计和税务申报要求（对监管机构透明）的同时，保护商业秘密（对竞争对手保密）。
表 5-3 ZK-KYC 与传统查看密钥的比较
