白皮书第4章:密码学基础

阿努比斯

阅读时间：8分钟

密码学基础

Anubis 的安全性建立在成熟的现代密码学原语之上。本章将深入探讨支撑 Anubis 隐私功能的核心算法。

4.1 零知识证明系统：PLONK

Anubis 选择 PLONK 作为其核心证明系统而不是 Groth16 或 STARKs，是基于一系列经过深思熟虑的权衡。

4.1.1 为什么选择 PLONK？

• 通用信任设置：尽管 Groth16 算法拥有极小的证明和快速验证的优势，但其致命缺陷在于每个电路都需要单独的信任设置。对于支持任意智能合约的 Anubis 而言，这意味着每次开发者部署新合约时都需要进行全网仪式，这在工程实践中是不切实际的。PLONK 支持通用参考字符串 (SRS)，只需一次全网仪式（Tau 的永恒幂）即可支持任何电路逻辑。该仪式由以太坊社区主导，超过 10 万名参与者贡献随机数。只要有一位参与者诚实地销毁其随机数，该设置就是安全的。因此，只要仪式中至少有一位参与者诚实，系统就是安全的。
• 性能平衡方面，与STARK（其证明大小大、验证成本高）相比，PLONK具有恒定的证明大小（约400字节）和较低的验证gas成本，使其非常适合链上环境。
• PLONK 的可定制门支持自定义约束门。Anubis 利用此功能设计了一个专用于 Pedersen 哈希和椭圆曲线加法的“Turbo PLONK”门，将证明生成速度提高了 3-5 倍。

图 3-3 Anubis PLONK 核心验证系统工作流程示意图

• merkle_root：当前 Note 树的根哈希值。
• nullifier_old：要消耗的 Note 的空终止符。
• commitment_new：新生成的票据的承诺。
• contract_address：用于交互的合约（例如 DEX）。
• asset_type：资产类型。
• 金额：交易金额。

证人/私人意见

• 存在性证明：验证将 merkle_path 添加到 note_old 可以计算 merkle_root。
• 所有权证明 验证 note_old 的公钥是否可以从 spend_key 推导出来。
• 无效化符一致性验证 nullifier_hash = Hash(note_old, spend_key)。
• 承诺完整性验证 commitment_new = Pedersen(note_new)。
• 价值保护验证
• 

这些约束被打包成一个简洁的证明 $\pi$，并使用 KZG 承诺方案进行验证。
4.2 Pedersen承诺和同态加密
佩德森的承诺是掩盖交易金额的关键。
公式：，
就是金额，

这是一个随机盲法因素。

和

是椭圆曲线上的生成元。

同态加法性质：
这使得验证节点能够在不解密的情况下验证交易金额的平衡（即，输入之和是否等于输出之和）。。
范围证明：为了防止恶意用户构造负数（在有限域中表现为极大的正整数），从而凭空“印钞”，Anubis 集成了 Bulletproofs 或 PLONK 查找参数。这会生成一个简洁的证明，确保值

承诺的范围为 $[0, 2^{64})$.6
4.3 EIP-5564 隐蔽地址协议
4.3.1 隐蔽地址保护
Anubis 在构建其隐身地址系统时严格遵循 EIP-5564 标准，旨在打破区块链交易中接收地址的关联性。然而，传统的隐身地址方案需要用户钱包扫描整个网络中的每笔交易以尝试解密，这会导致移动设备上极高的延迟和功耗。
协议流程：
1.收件人发布元地址：


2.发送方生成临时私钥

并计算临时公钥

3.使用 Diffie-Hellman 密钥交换协议共享秘密计算。
发送方计算

接收器计算

两种计算方法的结果相同
。
4.隐蔽地址派生
汇款人将资产转移到该地址

并将临时公钥附加到交易中

。
4.3.2 扫描和优化分层架构
为了解决“可扩展性-隐私”悖论，Anubis 引入了一种创新的三层扫描优化策略，将客户端的计算负担降低了几个数量级。
为了克服“接收者需要扫描整个网络”的性能瓶颈，Anubis 实现了视图标签。发送者将标签附加到邮件上。

将共享密钥哈希的第一个字节添加到交易中。扫描过程中，接收方只需检查标签是否匹配。如果不匹配，则立即跳过该交易；如果匹配，接收方将继续执行计算量巨大的椭圆曲线 (EC) 乘法进行解密。此机制可过滤掉 99.6% 的无关交易，从而将移动钱包同步速度提升 100 倍。
第一层：视图标签启发式过滤
这是第一道防线，旨在以极低的计算成本过滤掉绝大多数无关交易。
• 机制：在构建交易时，发送方计算共享密钥 $S$ 的哈希值，并提取其第一个字节（1 字节）作为 view_tag，并将其附加到交易元数据中。
• 效果：接收方只需比对区块链上的 view_tag 即可。由于该标签仅为 1 字节（256 种可能性），因此只有大约 1/256 的交易能够成功匹配。这意味着在执行代价高昂的椭圆曲线乘法运算之前，99.6% 的无关交易已被过滤掉。
• 隐私性：由于 view_tag 是一个截断的哈希值，因此会引入歧义，防止观察者仅凭标签就逆向工程出接收者的身份。
第二层：节点端预过滤（不经意消息检索，OMR）
为了解决通过第 1 层过滤的剩余流量，Anubis 引入了 OMR 协议，该协议将部分搜索工作外包给完整节点，同时确保节点在此过程中无法知道用户查询的具体内容。
• 机制：用户客户端生成一个包含其隐私特征的加密查询结构（类似于隐私保护的布隆过滤器或基于 FHE 的线索检测器），并将其提交给完整节点。
• 处理过程：完整节点在候选交易集上执行同态操作或盲匹配，而不解密用户的查询条件或了解交易的所有权。
• 结果：节点返回一个非常小的“潜在相关”交易子集。在此过程中，节点无法确定哪些交易真正属于用户，从而可以抵御元数据分析攻击。
第 3 层：轻客户端协议
对于 Layer 2 返回的极少数候选交易，客户端会在本地执行最终验证。
• 机制：客户端不需要同步完整的节点数据，而是采用了类似于以太坊轻客户端的模型。
• 仅同步：区块头并从完整节点请求特定交易的默克尔证明。
• 验证：客户端使用其本地私钥对这些过滤后的交易执行完整的 ECDH 解密和零知识证明验证，以确保资金所有权。
4.3.3 扫描性能和复杂度分析
通过上述三层架构，Anubis 将隐蔽地址的扫描复杂度从线性增长优化为对数或极低的常数水平，从而显著改善用户体验。

表3-3 扫描模式性能比较
该架构不仅解决了移动钱包同步速度慢的痛点，而且为未来支持数亿用户的隐私支付网络奠定了可扩展的基础。
4.4 查看关键系统
查看密钥对于实现符合监管要求且具有选择性的信息披露至关重要。Anubis 采用分层密钥管理系统：
• 消费键（最高级别的权力，可以支配资金，但绝不与他人分享。
• 完整视图图例（它可以解密所有历史交易详情（金额、发送人、备注），这些详情通常会提供给合规审计人员。
• 收款查看键：此功能仅允许您查看付款记录，适合商家进行账户核对。
• 外发视图键：此功能仅允许查看费用记录，适用于企业费用管理。
加密数据存储在票据的 encryptedData 字段中，采用椭圆曲线集成加密方案 (ECIES)。只有持有相应查看密钥的一方才能解密并重构交易明文。查看密钥不会泄露发送者的“真实地址”（即原始钱包地址）；它仅允许查看用于该特定交易的一次性隐蔽地址。这确保即使查看密钥被共享，用户的完整身份仍然无法追踪。

表3-4 分层密钥管理权限比较