介绍 bonsol：Solana上的ZK，可验证计算会带来哪些新用例？

撰文：Austbot

编译：深潮TechFlow

Anagram Build 大部分时间都用于研究新型的加密用例，并将这些用例应用于特定产品中。我们最近的一个研究项目进入了可验证计算（VC）领域。我们的团队利用这项研究创建了一个名为 Bonsol 的新开源系统。我们之所以选择这一研究领域，是因为可验证计算带来了许多有效的用例，而且各个 L1 都在共同努力优化可验证计算的成本效益和可扩展性。

在本文中，我们有两个目标

• 首先，我们希望确保您对 VC 作为一个概念以及它在 Solana 生态系统中可能启用的产品有更好的理解。

• 其次，我们希望向您介绍我们的最新作品：Bonsol

什么是可验证计算呢

“可验证计算（Verifiable Compute）”这个术语在牛市初创公司的投资说明书中可能不会出现，但“零知识”这个术语会。那么，这些术语是什么意思呢？

可验证计算（VC）是以一种能够生成其工作过程的证明的方式运行特定工作负载，而这个证明可以在不重新运行计算的情况下公开验证。零知识（ZK）是指能够证明关于数据或计算的陈述，而无需揭示所有数据或计算的输入。在现实世界中，这些术语有些混淆在一起，ZK 有些是一个误称。它更多地与选择需要公开以证明其陈述的信息有关。VC 是一个更准确的术语，并且是许多现有分布式系统架构的总体目标。

VC 如何帮助我们构建更好的加密产品？

那么，为什么我们想要在 Solana 和以太坊等平台上添加 VC 或 ZK 系统呢？答案似乎更多地与开发者的安全有关。系统的开发者充当了用户对黑匣子的信任与使该信任客观有效的技术功能之间的中介。通过利用 ZK/VC 技术，开发者可以减少他们正在构建的产品中的攻击面。VC 系统将信任的重点转移到了证明系统和被证明的计算工作负载上。这类似于从典型的 web2 客户端/服务器方法转向 web3 区块链方法时发生的信任倒置。信任从依赖于公司的承诺转变为信任开源代码和网络的加密系统。从用户的角度来看，没有真正的零信任系统，我认为对用户来说，这一切都像一个黑匣子。

例如，通过使用 ZK 登录系统，开发者在维护安全数据库和基础设施方面的责任就会减少，因为这个系统只需验证某些加密属性是否已实现。VC 技术正在应用于许多需要共识以确保所需共识的唯一条件是数学是有效的地方。

虽然有许多在野外使用 VC 和 ZK 的成功案例，但其中许多目前都依赖于加密软件栈各个层面的开发进度，以使其足够快速、高效地用于生产。

作为我们在 Anagram 所做的工作的一部分，我们有机会与众多加密创始人/开发者交谈，了解当前加密软件堆栈的状态如何影响产品创新。从历史上看，我们的谈话帮助我们识别出了一个有趣的趋势。具体来说，一批项目正在积极将链上产品逻辑转移到链下，因为它变得太昂贵了，或者他们需要添加更多的奇特业务逻辑。因此，最终这些开发者发现自己试图找到平衡他们正在开发的产品的链上和链下部分的系统和工具，这些产品变得越来越强大。这就是 VC 在帮助使用不可信任和可验证方法连接链上和链下世界的道路上成为关键部分的地方。

当下 VC/ZK 系统是如何工作的呢？

现在，VC 和 ZK 函数主要是在替代计算层（如Rollup、侧链、中继、预言机或协处理器）上执行的，可通过智能合约运行时回调使用。为了实现这一工作流程，许多 L1 链正在努力提供智能合约运行时之外的快捷方式（例如系统调用或预编译），以便执行一些在链上否则会太昂贵的操作。

当前 VC 系统有几种常见的模式。我将提及我知道的前四种。除了最后一种情况外，ZK 证明是在链下进行的，但正是证明何时何地被验证给了这些模式各自的优势。

完全在链上验证

对于能够生成小证明的 VC 和 ZK 证明系统，例如 Groth16 或一些 Plonk 变种，证明随后被提交到链上，并且使用先前部署的代码在链上进行验证。这样的系统现在非常常见，尝试此方法的最佳方式是使用 Circom 和 Solana 或 EVM 上的 Groth16 验证器。缺点是这些证明系统相当慢。它们通常还需要学习一种新语言。在 Circom 中验证一个 256 位哈希实际上需要手动处理每个 256 位。虽然有许多库允许您只需调用哈希函数，但在幕后，您需要在 Circom 代码中重新实现这些函数。当您的用例中的 ZK 和 VC 元素较小时，以及您需要证明在采取某些其他确定性操作之前证明是有效的时，这些系统非常棒。Bonsol 目前属于此第一类别。

链下验证

证明被提交到链上，以便所有各方都能看到它，并且稍后可以使用链下计算进行验证。在这种模式下，您可以支持任何证明系统，但由于证明不是在链上进行的，因此您无法为依赖于证明提交的任何操作获得相同的确定性。对于具有某种挑战窗口的系统而言，这是很好的，其中各方可以“否决”并尝试证明证明是不正确的。

验证网络

证明被提交到验证网络，并且该验证网络充当调用智能合约的预言机。您会获得确定性，但您也需要信任验证网络。

同步链上验证

第四种和最后一种模式相当不同；在这种情况下，证明和验证是同时在链上完成的。这就是 L1 或 L1 上的智能合约实际上能够在用户输入上运行 ZK 方案，并允许证明私有数据上的执行。在外并没有太多广泛的例子，通常您可以使用这种方法做的事情被限制在更基本的数学操作上。

总结

所有这四种模式都正在各种链生态系统中进行测试，我们将看到是否会出现新的模式，并且哪种模式会占主导地位。例如，在 Solana 上，没有一个明显的赢家，而且 VC 和 ZK 的景观还处于早期阶段。跨许多链，包括 Solana 在内，最受欢迎的方法是第一种模式。完全在链上验证是黄金标准，但正如所讨论的那样，它也带来了一些缺点。主要是延迟和它限制了您的电路可以做什么。当我们深入研究 Bonsol 时，您将看到它遵循了第一种模式，但有些不同之处。

介绍 Bonsol

Bonsol，这是我们 Anagram 所构建并开源的一个新的 Solana 原生 VC 系统。Bonsol 允许开发者创建一个可验证的可执行文件，涉及私有和公共数据，并将结果集成到 Solana 智能合约中。请注意，该项目依赖于流行的 RISC0 工具链。

这个项目的灵感来自于我们每周与许多项目交流时提出的一个问题：“我怎样才能使用私有数据在链上证明它？”虽然每个情况下的“事情”都有所不同，但底层的愿望是相同的：减少他们的中心化依赖。

在我们深入了解系统的细节之前，让我们通过两个不同的用例来说明 Bonsol 的强大之处。

情景一

一个 Dapp 允许用户购买各种代币池中的彩票。这些池子每天从一个全局池中“倾斜”，这样一来，池子中的金额（每种代币的金额）都是隐藏的。用户可以购买访问越来越具体范围的池子中的代币。但有一个陷阱：一旦用户购买了该范围，它就会同时对所有用户公开。然后用户必须决定是否购买彩票。他们可以决定不值得购买，或者他们可以通过购买彩票来确保他们在池子中有一份利益。

当池被创建并且当用户为范围付费时，Bonsol开始发挥作用。当创建/倾斜池子时，ZK 程序接收每种代币的数量的私有输入。代币的类型是已知的输入，而池子地址是已知的输入。该证明是对从全局池随机选择到当前池子中的证明。证明中还包含对余额的承诺。链上的合约将接收此证明，对其进行验证，并保存这些承诺，以便在最终关闭池子并将余额从全局池发送到彩票所有者时，他们可以验证自从池子开始时的随机选择以来代币数量是否发生了变化。

当用户购买隐藏代币余额范围的“开放”时，ZK程序将实际代币余额作为私有输入，并生成一系列数值，与证明一起承诺。此ZK程序的公共输入是先前承诺的池创建证明及其输出。通过这种方式，整个系统得到验证。先前的证明必须在范围证明中进行验证，并且代币余额必须散列到与第一个证明中承诺的相同值。范围证明也被提交到链上，并且如先前所述，使范围对所有参与者可见。

虽然有许多方法可以实现这种类似抽奖票的系统，但 Bonsol 的属性使得对组织举办抽奖的信任要求很低。它还突显了 Solana 和 VC 系统的互操作性。Solana 程序（智能合约）在促成信任方面发挥着关键作用，因为它验证证明，然后允许程序采取下一步行动。

情景二

Bonsol 允许开发人员创建供其他系统使用的工具套件。Bonsol 包含部署的概念，开发人员可以创建一些 ZK 程序并将其部署到 Bonsol 运营商那里。Bonsol 网络运营商目前有一些基本方式来评估是否对一个 ZK 程序的执行请求经济上有利。他们可以看到有关 ZK 程序将需要多少计算、输入大小和请求者提供的小费的一些基本信息。开发人员可以部署一个他们认为许多其他 Dapp 会想要使用的工具套件。

在 ZK 程序的配置中，开发人员指定所需输入的顺序和类型。开发人员可以发布一个预先配置了一些或全部输入的 InputSet。这意味着他们可以配置部分输入，帮助用户在非常大的数据集上验证计算。

例如，假设开发人员创建了一个系统，根据 NFT，可以证明链上的所有权转移包括了特定的一组钱包。开发人员可以有一个预配置的输入集，其中包含大量历史交易信息。ZK 程序搜索该集合以找到匹配的所有者。这是一个人为的例子，可以用许多方法实现。

再考虑另一个例子：开发人员能够编写一个 ZK 程序，可以验证一个密钥对签名来自一个密钥对或分层密钥对，而不泄露这些授权密钥对的公钥。假设这对许多其他 Dapp 有用，并且它们使用这个 ZK 程序。协议为这个 ZK 程序的作者提供了一小笔使用小费。由于性能至关重要，开发人员被激励使他们的程序运行速度快，以便运营商愿意运行它们，而试图剽窃另一个开发人员工作的开发人员需要改变程序的某些方式才能部署它，因为对 ZK 程序的内容进行验证。添加到 ZK 程序的任何操作都会影响性能，虽然这肯定不是绝对可靠的，但这可能有助于确保开发人员因创新而受到奖励。

Bonsol 架构

这些用例有助于描述 Bonsol 的用途，但让我们来看看它的当前架构、当前激励模型和执行流程。

上述图像描述了一个用户需要执行某种可验证计算的流程，这通常通过需要用户执行某些操作的 dapp 来实现。这将采取执行请求的形式，其中包含关于正在执行的 ZK 程序、输入或输入集、必须在其中证明计算的时间和小费（这是中继收费的方式）。请求被中继拾取，他们必须竞赛决定是否要声明对此执行的所有权并开始证明。根据特定的中继运营商的能力，他们可以选择放弃，因为小费不值得或者 zk 程序或输入太大。如果他们决定执行此计算，他们必须对其执行声明。如果他们是第一个获得声明的人，那么他们的证明将被接受直到某个时间。如果他们没有及时产生证明，其他节点可以声明执行。为了声明，中继必须提供一些抵押品，当前硬编码为小费/2，如果他们未能产生正确的证明则会被削减。

Bonsol 的构建基于这样一个论点，即更多的计算将转移到一个层面，在该层面上对其进行验证并进行链上验证，并且 Solana 将很快成为 VC 和 ZK 的首选链。Solana 的快速交易、廉价计算和不断增长的用户群使其成为测试这些想法的绝佳场所。

这很容易构建吗？当然不是！

这并不是说在构建 Bonsol 时没有挑战。为了将 Risco0 证明带到 Solana 并在其上验证，我们需要使其变小。但我们不能简单地这样做，而不牺牲证明的安全性。因此，我们使用 Circom 将 Risc0 Stark 包装起来，该 Stark 可以是约 200kb，然后将其包装在 Groth16 证明中，其大小始终为 256 字节。幸运的是，Risc0 为此提供了一些初步的工具，但它增加了许多开销和依赖项到系统中。

当我们开始构建 Bonsol 并使用现有的工具包装 Stark 与 Snark 时，我们寻求减少依赖性并增加速度的方法。Circom 允许将 Circom 代码编译成 C++ 或 wasm。我们首先尝试将 Circom 电路编译为由 LLVM 生成的 wasmu 文件。这是使 Groth16 工具包便携且仍然快速的最快、最有效的方法。我们选择 wasm 是因为其可移植性，而 C++ 代码依赖于 x86 cpu 架构，这意味着新的 Macbooks 或基于 Arm 的服务器将无法使用此代码。但在我们必须工作的时间表上，这对我们来说成为了一个死胡同。因为我们大部分的产品研究实验都是有时间限制的，直到证明其价值为止，我们有 2-4 周的开发时间来测试这个想法。llvm wasm 编译器无法处理生成的 wasm 代码。通过更多的工作，我们可能会克服这一难题，但我们尝试了许多优化标志和使 llvm 编译器作为 wasmer 插件工作的方法，以将此代码预编译为 llvm，但我们没有成功。由于 Circom 电路约为 150 万行代码，您可以想象到 wasm 的数量会很大。然后，我们将目光转向尝试创建一个仅在 C++ 和我们的 Rust 中继代码库之间创建桥梁。这也很快被击败了，因为 C++ 包含一些 x86 特定的汇编代码，我们不想去摆弄。为了将系统公开给公众，我们最终简单地启动了一个使其使用 C++ 代码但移除了一些依赖的系统。在未来，我们希望扩展另一条我们正在努力的优化线路。那就是将 C++ 代码实际编译成执行图。Circom 编译的这些 C++ 构件主要只是对具有非常非常大的素数生成器的有限域的模块化算术。这对于较小、更简单的 C++ 构件显示了一些有希望的结果，但需要更多的工作来使其与 Risc0 系统配合。这是因为生成的 C++ 代码约为 700 万行代码，而图生成器似乎达到了堆栈大小限制，并且提高这些限制似乎会产生其他故障，我们没有时间确定。尽管其中一些方法没有取得预期的结果，但我们能够对开源项目做出贡献，并希望在某个时候这些贡献将被合并到上游。

接下来的一系列挑战更多地涉及设计领域。该系统的一个重要部分是能够拥有私有输入。这些输入需要来自某个地方，并且由于时间限制，我们无法添加一些花哨的 MPC 加密系统，以允许私有输入在系统中形成闭环。因此，为了满足这个需求并解除开发人员的阻塞，我们添加了私有输入服务器的概念，它需要验证请求者是否通过有效载荷的签名验证了当前的索赔者，并为他们提供服务。随着我们扩展 Bonsol，我们计划实现一个 MPC 阈值解密系统，通过该系统，中继节点可以允许索赔者解密私有输入。所有关于私有输入的讨论都使我们想到了我们计划在 Bonsol 仓库中提供的设计演进。那就是 Bonsolace，这是一个更简单的系统，使您作为开发人员能够轻松地在自己的基础架构上证明这些 zk 程序。您可以自己证明，然后在与证明网络相同的合同上进行验证。这种用例适用于非常高价值的私有数据用例，其中对私有数据的访问必须尽可能减少。

最后关于 Bonsol 的一点我们还没有在其他地方使用 Risc0 的地方看到的是，我们强制要求在输入数据进入 zk 程序时进行承诺（哈希）。我们实际上在合同上检查了证明者必须承诺的输入，以确保它与用户期望并发送到系统中的输入相匹配。这会产生一些成本，但如果没有它，意味着证明者可能会作弊，并对用户没有指定的输入运行 zk 程序。Bonsol 的其余开发工作落入了正常的 Solana 开发中，但应该注意的是，我们有意在那里尝试了一些新的想法。在智能合约中，我们使用 flatbuffers 作为唯一的序列化系统。这是一种有些新颖的技术，我们希望将其发展并制作成一个框架，因为它很适合生成跨平台的 sdk。关于 Bonsol 的最后一点是，它目前需要预编译才能工作得最有效，这个预编译计划将在 Solana 1.18 中实现，但在那之前，我们正在努力看看团队是否对此研究感兴趣，并且超越 Bonsol 探索其他技术。

总结

除了 Bonsol，Anagram 构建团队还深入研究了 VC 领域的许多地方。像 Jolt、zkllvm、spartan 2、Binius 这样的项目是我们正在跟踪的项目，还有在全同态加密（FHE）领域工作的公司。

请查看 Bonsol 软件库，并为您需要的示例或您想要扩展它的方式提出问题。这是一个非常早期的项目，您有机会大显身手。

如果您正在进行有趣的 VC 项目，请申请 Anagram EIR 计划。

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。