简要总结
Boundless（由RISC Zero开发）将自己定位为dApp与区块链之间的zk中间件层：它在zkVM上执行重或敏感的计算，生成“收据”（证明 + 日志），并允许智能合约或链上/验证者服务在不重新执行的情况下验证结果。通过R0VM（zkVM）、Steel（EVM的ZK协处理器）、Bento/Broker（自托管证明集群 + 编排）和Bonsai（托管证明）等构建模块，Boundless为开发者提供了一条快速通道，并为dApp生态系统提供了一条生产就绪的路径。这些能力适用于许多dApp场景：复杂的DeFi、私人计算、链外预言机、游戏/NFT重计算和RWA认证。


1. 概念：什么是“zk 中介软体”，为什么 dApps 需要它？

  1. 快速定义：zk 中介软体是一种软件层，允许 dApp 将计算任务（聚合、定价模型、机器学习推断、签名聚合、批量状态证明）委托给外部环境，然后返回加密证明（零知识证明），验证计算根据规范正确执行。链上智能合约仅验证收据；无需重新运行原始数据或逻辑。

  2. 对 dApps 的好处：减少链上成本，绕过链上虚拟机的燃气/计算限制，保护敏感数据隐私，并为结果创建加密审计跟踪。这是 Boundless 针对其工具和协议堆栈的目标层。

2. 与中介角色直接相关的 Boundless 组件

  • R0VM (zkVM)：运行客户程序和生成证明的环境。R0VM 2.0 引入了重大性能改进，扩展内存至 3GB，降低证明成本，并为 EVM 附近的工作流添加有用的预编译。这些改进使得中介软体对于实时或对延迟敏感的工作负载变得可行。

  • Steel (EVM 的 ZK 协处理器)：允许 dApp/EVM 调用“协处理器”以执行超越燃气限制的逻辑（例如，历史计算、重型加密）并接收收据。这一模式使 Boundless 中介软体可以与 EVM dApps 兼容，而不会破坏现有的合约 UX。

  • Bento（自托管证明集群） + 经纪人（协调）：为团队在内部运行证明者、管理工作队列、SLA，并可选择与证明者市场整合的堆栈 — 对于希望保持数据在本地的企业或 dApps 至关重要。

  • Bonsai / 托管证明：快速原型的管理服务，无需 GPU 基础设施。适用于 MVP 或不含 PII 的工作负载。

3. dApp 与 Boundless 之间的常见整合模式


以下是开发者的实用模式及其优缺点：

  1. 模式 1 — 查看调用 / 协处理器 (EVM dApp)

  • 描述：dApp 智能合约向 Boundless Steel/Bento 发出请求（链外工作规范）；证明者运行逻辑，返回收据；合约调用验证者（Steel/Light 验证者）检查日志并应用结果。

  • 优势：保留 Solidity UX，使计算超越燃气限制。

  • 劣势：需要挑战窗口和重放保护设计。

  1. 模式 2 — 批量有效性证明（rollup 样式）

  • 描述：排序器/聚合器收集批量交易，将工作发送至 Bento，接收批量状态转换的有效性证明，将证明提交至结算链以完成。

  • 优势：节省燃气/每笔交易验证，适用于 rollup 或 L2。

  • 劣势：批量延迟，需要聚合/递回以优化成本。

  1. 模式 3 — 链外预言机 / 证明中介软体

  • 描述：预言机（价格数据，KYC 证明者，来源）进行链外计算/验证并发布 ZK 证明；dApp 使用证明作为数据来源。

  • 优势：增加预言机数据的信任最小化；保护隐私。

  • 劣势：依赖于证明者的可用性和协调者。

  1. 模式 4 — 隐私 / 选择性披露中介软体

  • 描述：dApp（身份、KYC、医疗保健）提交选择性披露工作；Boundless 证明者在不泄漏 PII 的情况下证明属性（日志仅包含标志/摘要）。

  • 优势：合规友好，保护输入数据。

  • 劣势：开发者必须小心避免在日志中记录 PII。

4. 开发者体验：工具、SDK 和工作流程

  1. 基本开发工具链（根据公共文档）：

  • 克隆模板/示例库（risc0 foundry 模板，Boundless 快速入门）。

  • 撰写客户程序（RISC-V 二进制 / WASI 目标）或使用 Steel API 进行 EVM 工作流。

  • 运行本地 Bento / 托管 Bonsai 以生成证明。

  • 在链上部署验证者（参考验证者合约/模组）。

  1. 工具和示例：

  • Foundry/Hardhat 模板（RISC Zero 为 EVM 整合提供模板）。

  • Bento 快速入门和经纪文档以配置工作生命周期和 SLA。

  1. 开发者备注：

  • 确定性约束：客户程序必须是确定性的并且是映像哈希的；收据包括映像 ID，以防止在不同程序之间重放。

  • 日志纪律：仅公布必要的输出；意外记录是常见的泄漏来源。

5. 使用 Boundless 中介软体的 dApps 的操作和大小考虑

  • 证明者大小：将热池（低延迟，保留的 GPU）分类为交互式 dApp 调用，冷池（批量）用于夜间工作；Bento 支持证明 + 提升 + 加入协调模式。

  • SLA 和市场：如果使用外部证明者，实施质押/声誉，而经纪人处理投标/工作锁定；直接影响延迟和成本。

  • 端到端成本：包括计算（GPU/CPU 小时）、DA 费用（如果使用 Celestia/Blobstream 进行 blobs）、链上的燃气/验证成本，以及运营/管理。R0VM 2.0 与先前版本相比报告了显著的成本降低，但团队必须针对实际工作负载进行基准测试。

6. 担任中介时的安全性、隐私和合规性

  1. 证明和验证者安全性：验证者合约/模组应保持最小逻辑；使用经过审计的参考验证者；对解析器/验证者进行模糊测试 + 单元测试。Veridise 和审计合作伙伴在 RISC Zero 的形式验证出版物中列出。

  2. 隐私：选择自托管的 Bento 或强制资料处理协议与 Bonsai；日志应仅包含承诺/摘要，以防止 PII 泄漏。

  3. 合规性：对于金融或个人数据用例，及早与法律部门协调（证券、KYC/AML、GDPR）。ZK 减少公共数据，但不免除法律义务。

7. 特定技术风险及缓解措施

  • 约束不足的客户程序：如果程序约束不够，可能允许证明者生成畸形证明；缓解措施：形式验证、确定性测试、CI 门槛。

  • 验证者/解析器错误：保持验证者最小化，使用经过审计的库，为合约部署升级/暂停模式。

  • DoS / 垃圾邮件证明：对工作提交实施费用/分类，限速，并在经纪市场中进行质押。

8. dApp 团队的部署检查清单（可复制）

  1. 识别需要证明的用例和输入数据（明确定义要证明的内容）。

  2. 选择整合模式（1 查看调用 / 2 批量证明 / 3 预言机 / 4 隐私）。

  3. 原型：撰写最小客户程序，运行本地 Bento/Bonsai，生成证明，在本地验证者合约上验证。

  4. 基准：测量 prove_time、proof_size、verify_gas、端到端延迟；测试多个批量大小。

  5. 安全性：审计客户程序和验证者；对解析器运行模糊测试；尽可能进行形式检查。

  6. 操作：配置热/冷证明者、监控、经纪政策（投标、SLA）。

  7. 法律与合规：将输出对应到法律要求，定义挑战窗口和取证日志（日志 + DA 指标）。

9. 简单的流程示意图（使用协处理器模式的 dApp）

  1. dApp (UI) 调用 contract.requestProof(params) → contract 发出带有工作规范的事件。

  2. 协调者（链外）接收事件，构建输入快照，将工作提交给 Bento/Bonsai（包括图像 ID，约束）。

  3. 证明者在 R0VM 上运行客户程序 → 生成收据 {imageID, journalDigest, proof}。

  4. 协调者提交交易 verifyProof(receipt) → 链上验证者验证并应用结果状态变更/发出结果。

  5. dApp 读取结果事件并更新 UX（日志仅包含公共输出）。

10. 结论


Boundless 可以作为 dApps 的高度实用中介软体：扩展计算限制、保护数据，并为链外结果提供加密证明。现实世界中的中介软体成功取决于三个因素：(1) 选择与 UX 和延迟目标一致的整合模式，(2) 操作设计（热/冷证明者，经纪人/SLA，成本模型），以及 (3) 安全性 — 使用经过审计的验证者，对客户程序进行形式检查，并为日志/DA 提供隐私优先政策。RISC Zero 的公开文档和工具（Boundless 博客，R0VM 2.0，Bento/经纪人文档，Steel 协处理器）是实际部署的重要参考。

@Boundless t-99/>c-100/>