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系统的运作机制
目前,VC和ZK功能主要在替代性计算层上实现,包括Rollups、侧链、中继、预言机或辅助处理器等,它们通过智能合约运行时的回调提供服务。为了优化这一流程,许多L1链都在开发旨在绕过智能合约运行时的快捷方式,如系统调用或预编译,以执行那些在链上成本过高的操作。
现有的VC系统主要采用四种验证模式。除了最后一种模式外,ZK证明通常都在链下完成,但其优势在于证明的验证地点和时间的选择上。
全链上验证模式
对于能够生成较小证明的VC和ZK证明系统,如Groth16或某些Plonk变体,这些证明会被提交到链上,并使用预先部署的代码进行验证。这类系统目前已相当普遍,使用Circom和Groth16验证器在Solana或EVM上进行实验是个不错的选择。不过,这些系统的缺点在于运行速度较慢,且通常需要学习新的编程语言。例如,在Circom中验证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智能合约通过验证这些证明并允许后续操作执行,在构建这种信任机制中扮演了关键角色。
应用场景二:模块化ZK程序平台
Bonsol平台允许开发者创建基础功能模块供其他系统使用。开发者可以编写特定的零知识证明(ZK)程序并部署到Bonsol网络中。网络运营商会评估每个ZK程序执行请求的经济性,包括计算需求、输入数据大小和请求者提供的激励金额等因素。
开发者可以设置ZK程序所需的输入数据类型和顺序,甚至预配置输入集,使这些基础模块能够验证处理大型数据集时的计算过程。
以NFT系统为例,开发者可以创建通过链上验证机制证实NFT所有权转移涉及特定钱包组的系统。开发者可以预设包含大量交易历史的输入数据集,让程序能找到对应的所有者信息。这只是其中一个应用场景,实际可能性多种多样。
另一个例子是开发验证密钥对签名是否来自指定密钥对集而不暴露任何公钥信息的ZK程序。如果这种程序被众多Dapp采用,创作者可以从中获得小额使用费。由于性能是关键,开发者有动力优化程序以吸引运营商使用。其他开发者若想使用该程序,需要修改以满足自身需求,这种机制虽非绝对安全,但能在一定程度上确保创新者获得应有回报。
Bonsol架构解析
让我们深入了解Bonsol平台的架构、激励机制和操作流程。以下场景展示了用户通过Dapp进行可验证计算的典型过程:

用户发起包含ZK程序详情、输入数据、验证时限及激励费用(中继节点报酬)的执行请求。中继节点接手请求后,需要快速判断是否接受任务并开始验证过程。他们根据处理能力和激励价值决定是否接受。首个成功认领任务的节点提交的证明会被暂时接受。如果未能在规定时间内提交证明,其他节点有机会接手。为认领任务,中继节点需支付相当于激励费用一半的保证金,验证失败则扣除保证金。
Bonsol基于一个核心观点构建:计算处理将越来越多地转移到链上进行验证,而Solana将成为实现VC和ZK技术的首选平台。Solana的快速交易处理、低成本计算能力及不断增长的用户基础,使其成为测试这些概念的理想环境。
Bonsol开发挑战
在Solana上验证Risc0证明的过程中,我们面临的主要挑战是如何在不损害安全性的前提下减小证明大小。我们采用Circom工具,将Risc0 Stark包装在Groth16证明中,这种包装方式固定输出为256字节。虽然Risc0提供了一些早期工具,但这显著增加了系统复杂度和依赖性。
在构建Bonsol并使用现有工具将Stark与Snark包装时,我们寻求减少依赖性和提高速度的方法。Circom允许将代码编译为C++或wasm。我们首先尝试将Circom电路编译为LLVM生成的wasm文件,这是使Groth16工具便携且快速的最有效方法。选择wasm是因为其可移植性,而C++代码依赖x86架构,无法在新的Arm架构设备上运行。这成为了开发时间表上的瓶颈,因为我们大多数产品研究实验都有2-4周的时间限制来验证概念价值。
LLVM wasm编译器无法处理生成的wasm代码。通过更多工作本可以解决这个问题,但我们尝试了多种优化方法让llvm编译器作为wasmer插件工作,均未成功。考虑到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)计划,与团队一起验证想法、创办公司并解决重大挑战。我们期待您的贡献和问题。
声明:
1.本文转载自[Anagram],所有版权归原作者[austbot]所有。若对本次转载有异议,请联系Gate Learn,团队会根据相关流程尽速处理。
2、免责声明:本文所表达的观点和意见仅代表作者个人观点,不构成任何投资建议。
3.文章其他语言版本由Gate Learn团队翻译。除非另有说明,否则禁止复制、传播或抄袭经翻译文章。
声明:文章不代表CHAINTT观点及立场,不构成本平台任何投资建议。投资决策需建立在独立思考之上,本文内容仅供参考,风险 自担!转载请注明出处:https://www.chaintt.cn/13568.html