Bonsol: 为Solana提供可验证计算服务

中级5/8/2024, 3:10:13 PM
可验证计算(VC)是以一种能够生成其工作过程的证明的方式运行特定工作负载,这个证明可以在不重新运行计算的情况下公开验证。除了 Bonsol,Anagram 构建团队还深入研究了 VC 领域的许多地方,像 Jolt、zkllvm、spartan 2、Binius 这样的项目是我们正在追踪的项目,还有在全同态加密(FHE)领域工作的公司。

Anagram Build团队主要从事新加密技术的研究并将其应用于具体产品。最近,我们的研究围绕可验证计算(VC),并基于此研究开发了一种名为 Bonsol的开源系统。我们选择深入这一领域,是因为VC已经显示出其在多个L1平台上提升成本效益和可扩展性的巨大潜力。

本文有两个目标:

  • 首先,希望读者能更好地理解可验证计算这一概念及其在Solana生态中可能开辟的新产品。
  • 其次,向您介绍我们的新作——Bonsol

何为可验证计算?

虽然“可验证计算”一词可能不常见于牛市时期初创公司的投资简报中,“零知识”则更为常见。可验证计算(VC)指的是以某种方式运行特定任务,生成一个可以公开验证的证明,而无需重复计算过程。而零知识(ZK)则是在不完全公开数据或输入的情况下,证明某数据或计算的真实性。虽然这两个概念在现实中经常被混淆,但应该注意,零知识更多关注于选择哪些信息公开以证实某种声明,而可验证计算则是众多现代分布式系统架构追求的更准确的目标。

VC如何帮助我们打造更好的加密产品?

那么,为什么我们要在Solana和Ethereum等平台上引入VC或ZK系统呢?这主要是考虑到开发者的安全需求。系统开发者需要在终端用户对技术的盲信与技术实际功能之间架起桥梁。使用ZK/VC技术,开发者能够减少潜在的安全风险。VC系统通过将信任焦点转移到证明系统及其计算任务上,改变了原有的信任模式。这种从传统Web2到Web3区块链模式的信任转移,意味着从依赖企业承诺转向信赖开源代码及网络加密体系。

例如,采用ZK登录系统的开发者比那些仅验证加密属性的系统的开发者承担更少的安全维护责任。VC技术被应用于许多需要确保共识的场合,其核心是验证数学的正确性而不是其他因素。虽然市场上已有许多VC和ZK的成功应用,但许多应用仍依赖于加密软件各层面的持续开发,以实现足够的速度和效率,使其适合正式投入使用。

在Anagram,我们通过与许多加密项目创始人和开发者的交流,了解到当前加密技术栈的局限性如何阻碍了产品创新。我们的讨论揭示了一个趋势,即许多项目正将链上逻辑转移到链外,以应对成本过高或需引入复杂业务逻辑的问题。开发者正努力寻找合适的系统和工具,以平衡产品开发中链上与链外的部分,使之更加强大。在这一过程中,VC技术成为连接链上与链外世界,采用可信且可验证方式的关键技术。

可验证计算和零知识系统如何运作?

VC和ZK功能现在主要在替代性计算层上进行,这些计算层包括Rollups、侧链、中继、预言机或辅助处理器等,它们通过智能合约运行时的回调来提供服务。为了实现这一流程,许多L1链条都在开发旨在绕过智能合约运行时的快捷方式,如系统调用或预编译,以执行那些在链上成本过高的操作。

目前的VC系统有几种主流模式。以下是我了解的四种主要模式。在这些模式中,除了最后一种,ZK证明都是在链下完成的,但它们的优势在于证明的验证地点和时间。

完全链上验证

对于那些可以生成较小证明的VC和ZK证明系统,例如Groth16或某些Plonk变体,这些证明将提交到链上,并使用之前部署的代码在链上进行验证。这种系统现在非常普遍,使用Circom和Groth16验证器在Solana或EVM上进行尝试是一种很好的方法。不过,这些系统的缺点是运行速度很慢,通常还需要学习新的编程语言。例如,在Circom中验证一个256位的哈希值,实际上需要手动处理这256位的每一位。虽然有许多库可以让你直接调用哈希函数,但实际上你需要在你的Circom代码中重写这些函数。当你的应用场景中ZK和VC的部分较小时,这些系统非常有用,你需要在执行某些其他确定性操作之前验证证明的有效性。目前,Bonsol就属于这一类系统。

链下验证

这种验证方式将证据上传到区块链,以便所有参与方都能看到并利用链下计算进行验证。这种模式允许使用任何验证系统,但因为验证过程不在链上进行,所以无法保证依赖于该证据的任何操作的确定性。这种方式适合于那些有挑战期的系统,在这期间参与者可以挑战证据的正确性。

验证网络

在这个模式下,证据被上传到一个专门的验证网络,该网络作为一个预言机调用智能合约。这样可以确保操作的确定性,但同时需要对验证网络持有信任。

同步链上验证

这是一种与众不同的验证模式,验证和证明过程完全在链上同步进行。在这种模式下,L1或L1上的智能合约可以直接处理用户的私有数据,使用零知识证明技术来确保执行的正确性。这种方法在现实中应用不广,通常只限于执行一些基本的数学操作。

总结

这四种验证模式目前正在多个区块链生态系统中进行试验,未来我们将观察到哪些新模式的出现以及哪一种将成为主导。比如,在Solana上目前还没有一个统治模式,而整个VC和ZK领域还处于初期阶段。多个链,包括Solana,普遍采用的是第一种模式。全链上验证虽然是公认的最佳模式,但正如讨论的那样,它存在一些问题,尤其是在延迟和电路功能限制方面。接下来,当我们详细介绍Bonsol时,你会发现它基本遵循第一种模式,但稍作修改。


Bonsol介绍!

欢迎了解Bonsol,这是一个由我们Anagram团队开发并公开源代码的Solana原生VC系统。Bonsol允许开发者在私有和公开数据上创建可验证的执行文件,并将结果集成进Solana的智能合约。注意,这个项目基于流行的RISC0工具链构建。

这个项目的启发来自我们与多个合作项目每周都会提出的问题:“如何能在链上使用私有数据并进行验证?”虽然具体问题各不相同,但所有问题的共同点在于:减少对中心化系统的依赖。

在深入了解系统细节之前,我们将通过两个独特的使用案例来展示Bonsol的强大功能。

场景一

有一款Dapp允许用户购买参与各种代币池的抽奖活动的门票。这些池每天会从一个全球代币池中进行”分配”,分配过程中会隐藏各代币的具体金额。用户可以购买对池中特定代币范围的访问权。但是有个限制:一旦用户决定购买这个范围,它就会同时对所有用户公开。用户随后需要决定是否真的购买这张抽奖票。他们可以选择放弃,认为这次购买不划算,或者通过购买门票来确保自己在池中的份额。

当涉及到创建池及用户为公开所购范围支付费用时,Bonsol就发挥作用了。在池创建或分配时,ZK程序会处理每种代币分配数量的隐私数据。这一证明确认了从全球池到当前池的随机选择,并对余额进行了承诺。这个证明会被链上的合约接收和验证,并保存这些数据,确保当池关闭并将代币分配给抽奖票持有者时,可以证明代币数量从开始至结束未被更改。

当用户选择公开某个隐藏的代币范围时,ZK程序将用代币实际余额作为私密输入,生成一系列被承诺的值和证明。这个过程的公开数据包括之前的池创建证明及其结果。这样可以保证整个系统的可靠性,确保之前的证明在新的范围验证中有效,并且代币的余额与初次承诺的值一致。这个范围的证明也会被记录在链上,并使得所有参与者都可见这个范围。尽管有许多方法可以实现这种抽奖系统,但Bonsol的特性让举办方几乎不需要赢得太多信任即可操作,这一点非常便利。同时,它还强调了Solana和VC系统之间的互通性。Solana的智能合约在构建这种信任机制中扮演了关键角色,通过验证这些证明并允许后续操作的执行。

场景二

Bonsol平台允许开发者创建基础功能模块,供其他系统使用。开发者可以编写特定的零知识证明(ZK)程序并将其部署到Bonsol的网络中。这些网络运营商会评估每一个ZK程序的执行请求是否具有经济效益,例如程序的计算需求、输入数据的大小以及请求者提供的激励金额等。

开发者可以设置ZK程序所需的输入数据类型和顺序,甚至预先配置输入集,使得这些基础模块能够在处理大型数据集时验证计算过程。

以NFT为例,开发者可能创建一个系统,通过链上验证机制证实某个NFT的所有权转移涉及特定的钱包组。开发者可以预设包含大量交易历史的输入数据集,让程序能找到对应的所有者信息。虽然这只是一个例子,实际应用可以多种多样。

另一个例子是,开发者可能开发一个ZK程序来验证某个密钥对签名是否来自指定的密钥对集,而不暴露任何公钥信息。如果这种程序被许多其他Dapps采用,那么它的创作者可以从中获得小额的使用费。由于高效性能是关键,开发者会被激励优化他们的程序以吸引运营商使用。并且,如果其他开发者想要使用该程序,他们需要修改程序来满足自己的需求,这种机制虽然不是绝对安全,但能够一定程度上确保创新者得到应有的回报。

Bonsol 架构

让我们探索Bonsol平台的架构、激励机制和操作流程。以下情景描绘了一个用户通过Dapp进行可验证计算的过程:

用户发起一个包含ZK程序详情、输入数据、验证时限及激励费用(即中继节点的报酬)的执行请求。该请求由中继节点接手,他们需要迅速判断是否接受此任务并开始验证过程。中继节点会根据自身的处理能力和激励的价值,决定是否接受任务。一旦他们决定接受并能首先成功认领任务,他们提交的证明便被暂时接受。如果他们未能在规定时间内提交证明,其他节点则有机会接手此任务。中继节点为了认领任务,需要支付一定的保证金(相当于激励费用的一半),如果验证失败,这部分保证金将被扣除。

Bonsol是基于一个观点构建的:计算处理将越来越多地转移到链上进行验证,而Solana将成为实现VC和ZK技术的首选平台。Solana的快速交易处理、低成本的计算能力及日益增长的用户群体,使其成为测试这些概念的理想场所。

构建Bonsol简单吗?并非如此!

在Solana上验证Risco0证明的过程中,我们面临的主要挑战是如何在不损害安全性的前提下减小其大小。我们采用了Circom工具,并将Risc0 Stark包装在Groth16证明中,这种包装方式固定输出为256字节。虽然Risc0提供了一些早期工具,但这大大增加了系统的复杂度和依赖性。

当我们开始构建 Bonsol 并使用现有工具将 Stark 与 Snark 包装起来时,我们寻求减少依赖性和提高速度的方法。 Circom 允许将 Circom 代码编译为 C++ 或 wasm。我们首先尝试将 Circcom 电路编译为 LLVM 生成的 wasmu 文件。这是使 Groth16 工具便携且快速的最快、最有效的方法。我们选择 wasm 是因为它的可移植性,因为 C++ 代码依赖于 x86 cpu 架构,这意味着新的 Macbook 或基于 Arm 的服务器将无法使用它。但这在我们必须合作的时间表上成为了我们的死胡同。因为我们的大多数产品研究实验都有时间限制,直到证明其价值,所以我们有 2-4 周的开发时间来测试这个想法。 llvm wasm 编译器无法处理生成的 wasm 代码。通过更多的工作,我们本可以克服这个问题,但我们尝试了许多优化标志和方法来让 llvm 编译器作为 wasmer 插件工作,以将此代码预编译到 llvm 中,但我们没有成功。因为 Circcom 电路大约有 150 万行代码,所以可以想象 Wasm 的数量变得巨大。然后,我们将目光转向尝试在 C++ 和 Rust 中继代码库之间创建一座桥梁。这也很快遭到失败,因为 C++ 包含一些我们不想摆弄的 x86 特定汇编代码。为了让系统向公众开放,我们最终只是以使用 C++ 代码但删除了一些依赖项的方式引导系统。未来,我们希望扩展我们正在研究的另一条优化路线。那就是获取 C++ 代码并将其实际编译成执行图。这些来自 Circcom 编译的 C++ 工件大多只是对有限域 用一个非常非常大的素数作为生成器。这为更小、更简单的 C++ 工件展示了一些有希望的结果,但需要做更多的工作才能使其与 Risc0 系统一起运行。这是因为生成的 C++ 代码大约有 700 万行代码,并且图形生成器似乎达到了堆栈大小限制,并且引发这些问题似乎会产生我们还没有时间确定的其他错误。尽管其中一些途径没有成功,但我们能够为 OSS 项目做出贡献,并希望在某个时候这些贡献将被上游化。

接下来的设计挑战更为复杂。这个系统的核心在于能处理私有数据输入。这些数据必须有可靠的来源,但由于时间限制,我们未能加入高级的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)计划,你将有机会与Anagram团队一道验证你的想法、创办公司,并挑战最大的问题。我们欢迎你的任何贡献和问题。

声明:

1.本文转载自[Anagram],所有版权归原作者[austbot]所有。若对本次转载有异议,请联系Gate Learn,团队会根据相关流程尽速处理。

2、免责声明:本文所表达的观点和意见仅代表作者个人观点,不构成任何投资建议。

3.文章其他语言版本由Gate Learn团队翻译。除非另有说明,否则禁止复制、传播或抄袭经翻译文章。

Bonsol: 为Solana提供可验证计算服务

中级5/8/2024, 3:10:13 PM
可验证计算(VC)是以一种能够生成其工作过程的证明的方式运行特定工作负载,这个证明可以在不重新运行计算的情况下公开验证。除了 Bonsol,Anagram 构建团队还深入研究了 VC 领域的许多地方,像 Jolt、zkllvm、spartan 2、Binius 这样的项目是我们正在追踪的项目,还有在全同态加密(FHE)领域工作的公司。

Anagram Build团队主要从事新加密技术的研究并将其应用于具体产品。最近,我们的研究围绕可验证计算(VC),并基于此研究开发了一种名为 Bonsol的开源系统。我们选择深入这一领域,是因为VC已经显示出其在多个L1平台上提升成本效益和可扩展性的巨大潜力。

本文有两个目标:

  • 首先,希望读者能更好地理解可验证计算这一概念及其在Solana生态中可能开辟的新产品。
  • 其次,向您介绍我们的新作——Bonsol

何为可验证计算?

虽然“可验证计算”一词可能不常见于牛市时期初创公司的投资简报中,“零知识”则更为常见。可验证计算(VC)指的是以某种方式运行特定任务,生成一个可以公开验证的证明,而无需重复计算过程。而零知识(ZK)则是在不完全公开数据或输入的情况下,证明某数据或计算的真实性。虽然这两个概念在现实中经常被混淆,但应该注意,零知识更多关注于选择哪些信息公开以证实某种声明,而可验证计算则是众多现代分布式系统架构追求的更准确的目标。

VC如何帮助我们打造更好的加密产品?

那么,为什么我们要在Solana和Ethereum等平台上引入VC或ZK系统呢?这主要是考虑到开发者的安全需求。系统开发者需要在终端用户对技术的盲信与技术实际功能之间架起桥梁。使用ZK/VC技术,开发者能够减少潜在的安全风险。VC系统通过将信任焦点转移到证明系统及其计算任务上,改变了原有的信任模式。这种从传统Web2到Web3区块链模式的信任转移,意味着从依赖企业承诺转向信赖开源代码及网络加密体系。

例如,采用ZK登录系统的开发者比那些仅验证加密属性的系统的开发者承担更少的安全维护责任。VC技术被应用于许多需要确保共识的场合,其核心是验证数学的正确性而不是其他因素。虽然市场上已有许多VC和ZK的成功应用,但许多应用仍依赖于加密软件各层面的持续开发,以实现足够的速度和效率,使其适合正式投入使用。

在Anagram,我们通过与许多加密项目创始人和开发者的交流,了解到当前加密技术栈的局限性如何阻碍了产品创新。我们的讨论揭示了一个趋势,即许多项目正将链上逻辑转移到链外,以应对成本过高或需引入复杂业务逻辑的问题。开发者正努力寻找合适的系统和工具,以平衡产品开发中链上与链外的部分,使之更加强大。在这一过程中,VC技术成为连接链上与链外世界,采用可信且可验证方式的关键技术。

可验证计算和零知识系统如何运作?

VC和ZK功能现在主要在替代性计算层上进行,这些计算层包括Rollups、侧链、中继、预言机或辅助处理器等,它们通过智能合约运行时的回调来提供服务。为了实现这一流程,许多L1链条都在开发旨在绕过智能合约运行时的快捷方式,如系统调用或预编译,以执行那些在链上成本过高的操作。

目前的VC系统有几种主流模式。以下是我了解的四种主要模式。在这些模式中,除了最后一种,ZK证明都是在链下完成的,但它们的优势在于证明的验证地点和时间。

完全链上验证

对于那些可以生成较小证明的VC和ZK证明系统,例如Groth16或某些Plonk变体,这些证明将提交到链上,并使用之前部署的代码在链上进行验证。这种系统现在非常普遍,使用Circom和Groth16验证器在Solana或EVM上进行尝试是一种很好的方法。不过,这些系统的缺点是运行速度很慢,通常还需要学习新的编程语言。例如,在Circom中验证一个256位的哈希值,实际上需要手动处理这256位的每一位。虽然有许多库可以让你直接调用哈希函数,但实际上你需要在你的Circom代码中重写这些函数。当你的应用场景中ZK和VC的部分较小时,这些系统非常有用,你需要在执行某些其他确定性操作之前验证证明的有效性。目前,Bonsol就属于这一类系统。

链下验证

这种验证方式将证据上传到区块链,以便所有参与方都能看到并利用链下计算进行验证。这种模式允许使用任何验证系统,但因为验证过程不在链上进行,所以无法保证依赖于该证据的任何操作的确定性。这种方式适合于那些有挑战期的系统,在这期间参与者可以挑战证据的正确性。

验证网络

在这个模式下,证据被上传到一个专门的验证网络,该网络作为一个预言机调用智能合约。这样可以确保操作的确定性,但同时需要对验证网络持有信任。

同步链上验证

这是一种与众不同的验证模式,验证和证明过程完全在链上同步进行。在这种模式下,L1或L1上的智能合约可以直接处理用户的私有数据,使用零知识证明技术来确保执行的正确性。这种方法在现实中应用不广,通常只限于执行一些基本的数学操作。

总结

这四种验证模式目前正在多个区块链生态系统中进行试验,未来我们将观察到哪些新模式的出现以及哪一种将成为主导。比如,在Solana上目前还没有一个统治模式,而整个VC和ZK领域还处于初期阶段。多个链,包括Solana,普遍采用的是第一种模式。全链上验证虽然是公认的最佳模式,但正如讨论的那样,它存在一些问题,尤其是在延迟和电路功能限制方面。接下来,当我们详细介绍Bonsol时,你会发现它基本遵循第一种模式,但稍作修改。


Bonsol介绍!

欢迎了解Bonsol,这是一个由我们Anagram团队开发并公开源代码的Solana原生VC系统。Bonsol允许开发者在私有和公开数据上创建可验证的执行文件,并将结果集成进Solana的智能合约。注意,这个项目基于流行的RISC0工具链构建。

这个项目的启发来自我们与多个合作项目每周都会提出的问题:“如何能在链上使用私有数据并进行验证?”虽然具体问题各不相同,但所有问题的共同点在于:减少对中心化系统的依赖。

在深入了解系统细节之前,我们将通过两个独特的使用案例来展示Bonsol的强大功能。

场景一

有一款Dapp允许用户购买参与各种代币池的抽奖活动的门票。这些池每天会从一个全球代币池中进行”分配”,分配过程中会隐藏各代币的具体金额。用户可以购买对池中特定代币范围的访问权。但是有个限制:一旦用户决定购买这个范围,它就会同时对所有用户公开。用户随后需要决定是否真的购买这张抽奖票。他们可以选择放弃,认为这次购买不划算,或者通过购买门票来确保自己在池中的份额。

当涉及到创建池及用户为公开所购范围支付费用时,Bonsol就发挥作用了。在池创建或分配时,ZK程序会处理每种代币分配数量的隐私数据。这一证明确认了从全球池到当前池的随机选择,并对余额进行了承诺。这个证明会被链上的合约接收和验证,并保存这些数据,确保当池关闭并将代币分配给抽奖票持有者时,可以证明代币数量从开始至结束未被更改。

当用户选择公开某个隐藏的代币范围时,ZK程序将用代币实际余额作为私密输入,生成一系列被承诺的值和证明。这个过程的公开数据包括之前的池创建证明及其结果。这样可以保证整个系统的可靠性,确保之前的证明在新的范围验证中有效,并且代币的余额与初次承诺的值一致。这个范围的证明也会被记录在链上,并使得所有参与者都可见这个范围。尽管有许多方法可以实现这种抽奖系统,但Bonsol的特性让举办方几乎不需要赢得太多信任即可操作,这一点非常便利。同时,它还强调了Solana和VC系统之间的互通性。Solana的智能合约在构建这种信任机制中扮演了关键角色,通过验证这些证明并允许后续操作的执行。

场景二

Bonsol平台允许开发者创建基础功能模块,供其他系统使用。开发者可以编写特定的零知识证明(ZK)程序并将其部署到Bonsol的网络中。这些网络运营商会评估每一个ZK程序的执行请求是否具有经济效益,例如程序的计算需求、输入数据的大小以及请求者提供的激励金额等。

开发者可以设置ZK程序所需的输入数据类型和顺序,甚至预先配置输入集,使得这些基础模块能够在处理大型数据集时验证计算过程。

以NFT为例,开发者可能创建一个系统,通过链上验证机制证实某个NFT的所有权转移涉及特定的钱包组。开发者可以预设包含大量交易历史的输入数据集,让程序能找到对应的所有者信息。虽然这只是一个例子,实际应用可以多种多样。

另一个例子是,开发者可能开发一个ZK程序来验证某个密钥对签名是否来自指定的密钥对集,而不暴露任何公钥信息。如果这种程序被许多其他Dapps采用,那么它的创作者可以从中获得小额的使用费。由于高效性能是关键,开发者会被激励优化他们的程序以吸引运营商使用。并且,如果其他开发者想要使用该程序,他们需要修改程序来满足自己的需求,这种机制虽然不是绝对安全,但能够一定程度上确保创新者得到应有的回报。

Bonsol 架构

让我们探索Bonsol平台的架构、激励机制和操作流程。以下情景描绘了一个用户通过Dapp进行可验证计算的过程:

用户发起一个包含ZK程序详情、输入数据、验证时限及激励费用(即中继节点的报酬)的执行请求。该请求由中继节点接手,他们需要迅速判断是否接受此任务并开始验证过程。中继节点会根据自身的处理能力和激励的价值,决定是否接受任务。一旦他们决定接受并能首先成功认领任务,他们提交的证明便被暂时接受。如果他们未能在规定时间内提交证明,其他节点则有机会接手此任务。中继节点为了认领任务,需要支付一定的保证金(相当于激励费用的一半),如果验证失败,这部分保证金将被扣除。

Bonsol是基于一个观点构建的:计算处理将越来越多地转移到链上进行验证,而Solana将成为实现VC和ZK技术的首选平台。Solana的快速交易处理、低成本的计算能力及日益增长的用户群体,使其成为测试这些概念的理想场所。

构建Bonsol简单吗?并非如此!

在Solana上验证Risco0证明的过程中,我们面临的主要挑战是如何在不损害安全性的前提下减小其大小。我们采用了Circom工具,并将Risc0 Stark包装在Groth16证明中,这种包装方式固定输出为256字节。虽然Risc0提供了一些早期工具,但这大大增加了系统的复杂度和依赖性。

当我们开始构建 Bonsol 并使用现有工具将 Stark 与 Snark 包装起来时,我们寻求减少依赖性和提高速度的方法。 Circom 允许将 Circom 代码编译为 C++ 或 wasm。我们首先尝试将 Circcom 电路编译为 LLVM 生成的 wasmu 文件。这是使 Groth16 工具便携且快速的最快、最有效的方法。我们选择 wasm 是因为它的可移植性,因为 C++ 代码依赖于 x86 cpu 架构,这意味着新的 Macbook 或基于 Arm 的服务器将无法使用它。但这在我们必须合作的时间表上成为了我们的死胡同。因为我们的大多数产品研究实验都有时间限制,直到证明其价值,所以我们有 2-4 周的开发时间来测试这个想法。 llvm wasm 编译器无法处理生成的 wasm 代码。通过更多的工作,我们本可以克服这个问题,但我们尝试了许多优化标志和方法来让 llvm 编译器作为 wasmer 插件工作,以将此代码预编译到 llvm 中,但我们没有成功。因为 Circcom 电路大约有 150 万行代码,所以可以想象 Wasm 的数量变得巨大。然后,我们将目光转向尝试在 C++ 和 Rust 中继代码库之间创建一座桥梁。这也很快遭到失败,因为 C++ 包含一些我们不想摆弄的 x86 特定汇编代码。为了让系统向公众开放,我们最终只是以使用 C++ 代码但删除了一些依赖项的方式引导系统。未来,我们希望扩展我们正在研究的另一条优化路线。那就是获取 C++ 代码并将其实际编译成执行图。这些来自 Circcom 编译的 C++ 工件大多只是对有限域 用一个非常非常大的素数作为生成器。这为更小、更简单的 C++ 工件展示了一些有希望的结果,但需要做更多的工作才能使其与 Risc0 系统一起运行。这是因为生成的 C++ 代码大约有 700 万行代码,并且图形生成器似乎达到了堆栈大小限制,并且引发这些问题似乎会产生我们还没有时间确定的其他错误。尽管其中一些途径没有成功,但我们能够为 OSS 项目做出贡献,并希望在某个时候这些贡献将被上游化。

接下来的设计挑战更为复杂。这个系统的核心在于能处理私有数据输入。这些数据必须有可靠的来源,但由于时间限制,我们未能加入高级的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)计划,你将有机会与Anagram团队一道验证你的想法、创办公司,并挑战最大的问题。我们欢迎你的任何贡献和问题。

声明:

1.本文转载自[Anagram],所有版权归原作者[austbot]所有。若对本次转载有异议,请联系Gate Learn,团队会根据相关流程尽速处理。

2、免责声明:本文所表达的观点和意见仅代表作者个人观点,不构成任何投资建议。

3.文章其他语言版本由Gate Learn团队翻译。除非另有说明,否则禁止复制、传播或抄袭经翻译文章。

今すぐ始める
登録して、
$100
のボーナスを獲得しよう!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.