下一步计划与已知问题

后续步骤与已知问题

ZK 电路集成（主要障碍）

Noir ZK 电路存在于 (circuits/)，但尚未集成到实时协议中。有三个问题阻碍了集成：

问题 1：Poseidon 哈希不一致

问题：Poseidon2 的输出在 Noir、Rust (zkhash) 和 Solidity 实现之间存在差异。已测试了多个实现（TaceoLabs、Aztec、HorizenLabs）；没有一个能在所有三种语言中产生一致的输出。许多替代实现缺乏许可证或目标领域不同（例如，Goldilocks）。

建议修复：迁移到 Poseidon 1，使用已知兼容的实现：

arnaucube/poseidon-rs 和 iden3 的生成器已知兼容。Noir 的兼容性需要验证。

步骤：

• 在 crates/common/ 中用 poseidon-rs 替换 zkhash
• 使用 iden3 生成 Solidity 合约，替换 Poseidon2T2.sol
• 更新 circuits/lib/src/merkle.nr 以使用 Poseidon 1 API
• 添加跨语言测试向量（使用现有的 CLF 基础设施）

问题 2：Solidity 堆栈过深 (Stack-Too-Deep)

问题：生成的 UltraHonk 验证器合约在使用 Foundry 编译时超出了 Solidity 的堆栈限制。同样的合约在 Remix IDE 中可以编译（不同的优化器设置），这表明是工具配置问题。

步骤：

• 调试 Foundry 编译器设置（via-ir 模式、优化器运行）与 Remix 默认设置的差异
• 调查 Poseidon 1 迁移是否能降低验证器复杂性
• 考虑使用 assembly (memory-safe) 注解来减少堆栈使用
• 如果验证器大小仍然有问题，评估证明聚合策略

问题 3：noir-rs 集成

问题：zkmopro/noir-rs 可以独立用于证明生成和验证，但未作为 ProofClient 实现与 TEE 一起连接到 crate 工作区。

步骤：

• 实现一个包装 noir-rs 并符合 ProofClient trait 的 ZkProofClient
• 连接到 UserApp<P>，以便相同的应用程序代码适用于任一后端
• 调查 Wasm 可移植性以支持基于浏览器的证明

TEE 生产就绪度

TEE 子系统在模拟模式下工作，但尚未在真实硬件上测试：

• 使用真实 SGX 硬件测试（Gramine 模式而非模拟）
• 实现真实的 DCAP quote 验证（目前为模拟解码）
• 密钥轮换和恢复程序
• 飞地边界的安全审计

应用层

• CLI：目前没有 CLI；系统仅作为库存在。一个用于用户操作（设置、支付、结算）的 CLI 将使测试和演示变得实用。
• HTTP 402 流程：Coinbase x402 支付协议集成超出了当前阶段的范围。

测试差距

• 原文链接： github.com/ConorNethermi...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～