零知识证明：其在 Solana 上的应用

<!--StartFragment-->

介绍

这是零知识证明入门系列的第二篇文章。我强烈建议在阅读本文之前先阅读《零知识证明：基础知识介绍》，因为它提供了本文分析所需的基础理论、数学和密码学背景。本文假设您已经了解这些知识，因此，如果您不熟悉零知识证明，我强烈建议您先阅读本文。本文的目的是让您掌握必要的知识，为 Solana 上的零知识证明讨论做出贡献，甚至走上开发新的创新零知识原语的道路。

因此，有了这些新知识，我们终于可以问一下什么是零知识证明？它们在 Solana 上是如何使用的？

那么，什么是零知识证明？

<!--EndFragment--> <!--StartFragment-->

现在我们终于掌握了必要的理论、数学和密码学知识，我们应该问：零知识证明到底是什么？

零知识证明是一种加密过程，其中一方能够向另一方证明某个陈述是真实的，而无需透露除该陈述确实真实之外的任何其他信息。这些证明必须在统计上合理、完整且不会泄露信息。

在零知识证明中，有两种类型的陈述需要证明。从高层次上讲，

• 关于事实的陈述（例如，这个特定的图表有三种颜色）
• 关于知识的陈述（例如，我知道N的因式分解）

第一个陈述最终涉及宇宙的某些内在属性——某些基本事实，例如 1 + 1 = 2。第二个陈述被称为知识证明。也就是说，它超越了单纯证明某事为真的范畴，并依赖于证明者所知道的内容。

如前所述，为了证明这些陈述，我们的证明可以是交互式的，也可以是非交互式的。在交互式零知识证明中，证明者和验证者进行一系列轮次，直到验证者确信无疑。Zcash[使用]非交互式零知识证明来允许用户进行匿名交易。 

相比之下，非交互式零知识证明的证明是离线传递的，证明者和验证者之间没有任何直接通信。在这里，证明者生成一个封装所有必要信息的证明，验证者可以独立验证该证明，而无需任何进一步的交互。Filecoin[使用]非交互式零知识证明来证明用户存储了数据，而无需透露数据本身。 

 zk-SNARK 和电路

<!--EndFragment-->

<!--StartFragment-->

zk-SNARK 是一种简洁的非交互式AR知识证明。这些零知识证明特别高效、紧凑，或者*说简洁。如果证明的大小和验证它所需的时间都比要验证的计算速度慢，*则认为证明是简洁的。因此，如果我们想要一个简洁的证明，我们就不能让验证者在每轮哈希处理中做一些工作，否则验证时间将与计算成正比。简洁的证明是可能的，这要归功于多项式和 Fiat-Shamir 启发式方法。**

无论试图证明的陈述有多复杂，zk-SNARK 都能保持较小的证明大小，并且验证速度相对较快。这就是 zk-SNARK 对汇总如此有吸引力的原因；在这里，我们有一种方法可以证明给定 L2 的所有交易都是有效的，并且证明足够小，可以在 L1 上进行验证。像Mina这样的协议更进一步，使用递归证明，这使它们能够使用恒定大小的证明来验证链的整个历史。Pickles是 Mina 的新证明系统和相关工具包，它是第一个能够在没有受信任设置的情况下进行递归组合的部署的 zk-SNARK。请注意，我们所说的递归组合指的是电路。

电路描述了您想要证明的计算。它们是一系列数学运算，需要一些输入来产生输出。电路用于零知识证明，以表示已正确执行的计算，而无需透露计算的输入。一般工作流程如下：

• 编写和编译电路— 我们需要编写和编译电路。这可能很简单，只需在由素数p = 7和计算x * y = z定义的有限域上创建一个算术电路即可。这里的一般思想是将要证明的计算表示为变量之间的一组约束，将这些约束简化为多项式方程，并编写代码将所有值单向映射到新的代数结构（即[同态])）。编译过程将输出几个工件，包括由电路定义的一组约束以及要在后续步骤中使用的脚本或二进制文件
• 可信设置仪式——根据用于生成证明和验证密钥的 zk-SNARK 类型，可能需要运行仪式
• 执行电路— 必须使用编译期间生成的脚本或二进制文件来执行电路，就像它是某种类型的程序一样。用户将输入公共和私有输入，然后计算所有中间变量和输出变量的值。见证（也称为跟踪）是所有计算步骤的记录
• 生成证明——在第二步中给出证明密钥，在第三步中给出见证，证明者可以生成零知识证明，证明电路中定义的所有约束均成立，同时仅显示输出值。此证明将发送给验证者
• 验证证明——验证者使用提交的证明和验证密钥验证其公开输出的证明是否正确

某些类型的 zk-SNARK（例如[Groth16]）要求每个电路都有一个可信设置。这可能会妨碍您，因为您需要为每个新程序运行一个新的仪式。其他 zk-SNARK（例如[PlonK])）只需要一个通用的可信设置，从而简化了整个过程。而其他类型的零知识证明（例如 zk-STARK）则完全消除了对可信设置的需要。

<!--EndFragment--> <!--StartFragment-->

零知识证明

zk-STARK 是一种可扩展的透明AR**知识证明。zk -STARK 由**[StarkWare]发明，并[于 2018 年的一篇论文中首次提出])作为 zk-SNARK 的替代方案。本质上，它们允许区块链将计算转移到单个链下 STARK 证明器，并使用链上 STARK 验证器验证这些计算的完整性。 

zk-STARK 被认为是零知识，因为链下证明者使用的输入不会暴露给区块链，从而保护了用户的隐私。zk-STARK 具有可扩展性，因为将计算转移到链下可显著降低 L1 验证成本。它们的证明也呈线性扩展，而 zk-SNARK 仅呈准线性扩展。此外，zk-STARK 不依赖于复杂的可信设置仪式，他们认为这些仪式容易受到有毒废物的影响——如果仪式没有正确进行，验证者可能会接受无效证明。相反，zk-STARK 使用可公开验证的随机性来设置证明者和验证者之间的交互。并且，这些证明只能由实际执行计算的链下证明者及其所需的辅助输入生成。

<!--EndFragment--> <!--StartFragment-->

zk-STARK 通过可扩展、透明的知识论证解决了 zk-SNARK 的局限性。它们还带有更简单的加密假设，完全避免了对椭圆曲线等元素的需求。相反，它们纯粹依赖于哈希和[信息论]，使其[具有抗量子性]。然而，证明的大小在几百千字节的范围内，这可能会限制它们在带宽或存储有限的环境（如区块链）中的可行性。

请注意，一些更复杂的证明设置和 zkVM 将使用将 zk-STARK 递归证明到 zk-SNARK 的组合，仅用于最后的验证步骤。 <!--EndFragment--> <!--StartFragment-->

ZK 压缩

国家增长问题

Solana 最紧迫的问题之一是状态增长问题。为了将这个问题具体化，Solana 的状态存储在帐户数据库中完整节点的磁盘上。这是一个键值存储，数据库中的每个条目称为一个帐户。每个帐户的地址为 32 字节，帐户可以存储的数据量在 0 到 10 MB 之间。目前，存储 10 MB 的数据大约需要 70 SOL，无论这些数据分布在一个 10 MB 的帐户还是一千个 10 KB 的帐户中。根据 Toly 关于状态增长问题的帖子，每天大约有100 万个新帐户添加到链中，这使总状态超过 5 亿个帐户。随着 Solana 的不断发展，这将带来若干挑战，即无限制的快照大小、PCI 带宽限制、帐户索引以及昂贵的内存和磁盘管理。 

当前的完整快照大小约为 70 GB，在当前硬件条件下是可以管理的。但是，持续增长将不可避免地导致状态管理效率低下和潜在瓶颈。随着快照大小的增加，硬件故障后[冷启动]新系统所需的时间会显著变长，这在网络重启的情况下可能会造成不利影响。 

[外围组件互连 (PCI)]带宽是指 CPU 与外围设备（如显卡、网卡和存储设备）之间的数据传输速率。PCI [Express (PCIe)]是一种高速接口标准设计，旨在取代旧的 PCI 标准并提供更高的数据传输速率。最新的 PCI 带宽可以达到 1 TB 或[128 GB/s]的速度。虽然这听起来很多，但这并不在 Solana 的范围内。如果一笔交易读取或写入 128 MB，那么 128 GB/s 的 PCI 带宽会将 Solana 限制为每秒 1000 笔交易 (TPS)。但是，大多数交易访问的都是已经加载并缓存到验证器 RAM 中的最新内存。尽管如此，高效的状态内存对于确保在 Solana 扩展时保持高吞吐量至关重要，否则这种带宽很快就会成为限制因素。

每个验证者都需要维护所有现有帐户的索引。这是因为创建新帐户需要证明该帐户尚不存在。由于总状态超过 5 亿个帐户，即使是最小索引（即每个条目 32 字节密钥和 32 字节数据哈希）也需要大约 32 GB 的 RAM。这种状态存储非常昂贵，需要谨慎管理以防止性能下降。随着 Solana 的状态不断增长，使用快速、昂贵的内存（即 RAM）进行某些操作与使用较慢、较便宜的内存（即磁盘）之间的区别变得至关重要。

<!--EndFragment-->

<!--StartFragment-->

交易和状态增长

每笔 Solana 交易都需要指定其读取和写入的所有帐户。交易目前上限为 1232 字节，并且必须包含以下内容：

• 标头（3 个字节）
• 签名（每个 64 字节）
• 账户地址（每个 32 字节）
• 指令数据（任意大小）
• 最近的区块哈希（32 字节）

执行事务时会发生以下情况：

• 健全性检查——只有最近的交易才有效，并且对交易进行重复数据删除、结构验证、费用和签名检查
• 程序加载——根据程序地址加载程序字节码，并实例化 Solana 虚拟机 (SVM)
• 账户加载——检查交易引用的所有账户，并将其从存储中加载到内存中，然后传递给 SVM
• 执行——执行程序字节码
• 同步——所有修改过的账户都会同步回存储

随着状态的不断增长，此生命周期带来了一些挑战。即，链上状态成本高昂，在磁盘上存储更多账户会导致更大的快照和索引。此外，并非所有账户都会被频繁访问，因此持续在这些账户上花费资源成本是低效的。

<!--EndFragment--> <!--StartFragment-->

使用 ZK 压缩简化状态管理

交易可以将账户数据作为交易负载的一部分传递，而不是将所有账户存储在磁盘上并在需要时读取它们。我们可以通过使用 Merkle 树来确保提交交易的用户提供正确的状态。Merkle 证明是一种提交某些数据的方式。这样，可以根据承诺验证证明，以验证是否已传递正确的状态，以及用户是否对提供的状态不诚实。 

虽然这些证明是安全的，但它们可能非常大。例如，如果一棵树包含 10 万个账户，则证明大小将为 544 字节。为多个账户提供证明可能会很快超过 1232 字节的交易大小限制。幸运的是，我们可以通过使用更高效的证明系统来规避这个问题。使用恒定证明大小承诺（例如 KZG 或 Pedersen 承诺）将减少证明大小，从而使在交易大小限制内包含证明变得更加可行。

*[ZK 压缩只是一种解决 Merkle 证明大小问题的机制 —— 它是一种通过利用 Solana 的分类账]来证明某些计算已正确完成的方法，而无需相关的链上存储成本*。

<!--EndFragment--> <!--StartFragment-->

什么是 ZK 压缩？

ZK 压缩是一种新原语，允许开发人员压缩链上状态，以将状态成本降低几个数量级，同时保持安全性、性能和可组合性。例如，创建 100 个代币账户目前需要花费 \~0.2 SOL，而使用 ZK 压缩，成本将降低 5000 倍至 \~0.00004。 

ZK Compression 利用零知识证明来验证状态转换，而无需暴露底层数据。它通过将多个账户分组到链上存储的单个可验证 Merkle 根来实现这一点，而底层数据存储在账本上。有效性证明是简洁的零知识证明，用于证明n个账户作为m 个状态树中的叶子而存在，同时保持恒定的 128 字节证明大小。这些证明是在链下生成的，并在链上验证，从而减轻了 Solana 的整体计算负担。ZK Compression 使用[Groth16]（一种著名的[基于配对的]zk-SNARK）作为其证明系统。

但这些账户并不是常规的 Solana 账户。相反，它们是压缩账户。

<!--EndFragment--> <!--StartFragment-->

压缩账户模型

ZK 压缩状态存储在压缩账户中。这些账户与常规 Solana 账户类似，但有几个关键区别，可以提高效率和可扩展性：

• 哈希识别——每个压缩账户都可以通过其哈希来识别
• 写入时哈希值发生变化——对压缩账户的任何写入操作都将改变其哈希值
• 可选地址——可以选择将地址设置为压缩帐户的永久唯一 ID。这对于某些用例很有用，例如 NFT。此字段是可选的，是为了避免计算开销，因为压缩帐户可以通过其哈希引用
• 稀疏状态树——所有压缩账户都存储在 Merkle 树中，只有树的状态根（即 Merkle 根）存储在链上账户空间中。更具体地说，[状态树是基于 Poseidon 哈希的并发 Merkle 树] <!--EndFragment-->

<!--StartFragment-->

压缩程序派生地址 (PDA) 可通过其唯一、持久的地址来识别。它们遵循与常规 PDA 帐户类似的布局，具有数据、Lamports、所有者和地址字段。但是，与常规 PDA 不同的是，数据字段包含带有鉴别器、数据和数据哈希字段的 AccountData 结构。

节点

不同类型的节点在支持 ZK Compression 方面发挥着至关重要的作用。任何人都可以运行 Photon RPC 节点、Prover 节点或 Light Forester 节点来连接到 Devnet 和 Mainnet-Beta。对于本地开发，[ZK Compression CLI ]test-validator命令会启动一个单节点 Solana 集群，其中包含所有相关节点（即 Photon RPC 和 Prover）以及系统程序、帐户和运行时功能。

[Photon RPC 节点]索引压缩程序。这使客户端能够读取和构建与压缩状态交互的事务。​​规范的压缩索引器名为[Photon]，由 Helius 提供。这种类型的节点可以在本地以最少的设置运行，并且需要将其指向现有的 RPC。 

[证明者节点]用于生成状态包含的有效性证明。ZK [Compression RPC API 规范]的[getValidityProof端点]可用于获取证明。证明者节点可以作为独立节点运行，也可以与另一个 RPC 捆绑运行。请注意，规范的 Photon RPC 实现包含一个证明者节点。

[Light Forester 节点]管理共享和程序拥有的状态树的创建、滚动和更新。这适用于可能希望选择由 Light Forester 节点网络提供服务的程序拥有的状态树的开发人员。

<!--EndFragment--> <!--StartFragment-->

信任假设

任何人都可以运行上述节点之一，并存储生成证明和提交交易所需的原始数据。这引入了一个信任假设，影响压缩状态的活跃度。也就是说，如果数据丢失或延迟，除非数据是个人存储的，否则无法提交交易。由于只需要一个诚实的节点来提供数据，并且证明是可自我验证的，因此问题在于其活跃度和潜在的审查，而不是安全性。

此外，验证压缩账户的程序目前可升级，这又引入了另一个信任假设。这样一来，就可以修改程序以修复任何问题或进行调整以满足新的要求。但是，一旦达到稳定和安全的状态，就可以将其设为不可变或冻结。

另一个活跃信任假设是使用 Forester 节点。这些节点通过清空状态根并异步推进状态根来维护状态根推进并管理无效队列。在这里，帐户哈希被替换为零以使其无效。这种推进和无效的分离确保了压缩状态转换的即时最终性，同时将交易保持在 Solana 的大小限制内。由于无效队列具有恒定的大小，因此 Forester 节点对于协议活跃性至关重要。满队列会导致关联状态树的活跃性失败。值得庆幸的是，Forester 节点通过清空队列来防止这种情况。但是，人们仍然需要运行这些节点来帮助协议的完整性和活跃性。如果没有这些节点，ZK Compression 只能支持大约两千个帐户/地址。

<!--EndFragment--> <!--StartFragment-->

限制 

即使不需要隐藏某些东西，零知识证明也会将需要多个计算步骤的问题转变为只需验证一个证明即可知道计算是否正确执行的问题。这些计算不必与特定叶子是否属于给定树有关——它们可以是任意计算。然而，这是有代价的。

在使用 ZK 压缩之前，请考虑以下事项：

• 交易规模更大——ZK 压缩需要 128 个字节来证明有效性，以及发送链上读写数据所需的字节数
• 更高的计算单元使用率——ZK 压缩显著增加了计算单元 (CU) 的使用率，因为它需要 \~100k CU 进行有效性证明验证，\~100k CU 供系统使用，以及每个压缩帐户读取或写入 \~6k CU
• 每笔交易状态成本——每次写入操作都会产生少量网络成本，因为它必须使之前的压缩帐户状态无效并将新的压缩状态附加到状态树中。因此，如果需要进行大量状态更新，单个压缩帐户的生命周期成本完全有可能超过未压缩帐户

如果符合以下情况，最好使用常规帐户：

<!--EndFragment--> <!--StartFragment-->

• 该帐户经常更新
• 账户的终身写入次数将很大（即 >1000 次）
• 该账户存储了大量必须在链上交易中访问的数据

<!--EndFragment--> <!--StartFragment-->

ZK Compression 是一种可扩展、安全、高效且灵活的原语，可直接解决 Solana 的状态增长问题，并支持广泛的应用程序和用例。可以说，它最显着的优势是降低了状态成本。ZK Compression 允许应用程序轻松扩展到数百万用户，方法是将状态安全地存储在更便宜的账本空间上，同时通过状态指纹将链上存储保持在最低限度。以创建 10,000 个代币账户为例，假设 SOL 价格为 130 美元，这样做大约需要花费 2,600 美元。ZK Compression 将这一成本降低到不到五十美分。

ZK Compression 也很好地融入了当前的 Solana 规范。例如，压缩账户的结构几乎与常规 Solana 账户相同。它还支持 Solana 特有的创新，例如并行性。也就是说，同一状态树（即承诺）下访问不同压缩账户的任何两个交易都可以并行执行。此外，ZK Compression 支持同步原子可组合性。例如，列出n 个压缩账户和m 个常规账户的交易是完全有效的配置。引用压缩账户的指令可以调用引用常规账户的另一条指令或程序。即使账户在不同的状态树下压缩，也是如此。如果一条指令失败，则整个交易将回滚，并且一条指令到下一条指令的更改是可见的。这与 ZK rollups 不同，在 ZK rollups 中，除非它们采用锁定，否则它们无法同步或原子地相互调用。自然，这值得对 ZK Compression 和 rollups 进行比较。

<!--EndFragment-->

<!--StartFragment-->

ZK 压缩不是 rollup。虽然两者依赖相同的技术，但实现方式不同。rollup 有两种类型：

• 乐观汇总——假定所有交易在给定的时间段内有效，并使用欺诈证明来证明此时间范围内的虚假交易
• 零知识汇总——使用有效性证明立即证明交易有效或无效

零知识 Rollup 的整个状态在基础层（即以太坊）上表示为单个根。这导致许多人声称 ZK Compression 实际上是一个 Rollup。然而，两者之间存在一些关键差异。

考虑一个涉及 ZK Rollup 上的 500 笔交易的场景。在这种情况下，整个 Rollup 被视为单个电路。所有 500 笔交易一起验证，产生一个单一的证明，确认状态根已从A更改为B。验证此证明后，管理 L1 和 L2 之间交互的智能合约会相应地更新状态根。相比之下，使用 ZK Compression，500 笔交易中的每一笔都会生成自己的证明来验证帐户数据的正确性。这些交易由 SVM 本身执行，并且一旦每个证明都得到验证，这些帐户就会被视为“常规”帐户。

如果我们将 ZK 压缩归类为 rollup，则意味着存储在 Solana 上的任何 Merkle 根都可以被视为基于有效性的 rollup。如果我们查看 Solana 上当前所有压缩的 cNFT 根，[那么大约有 4-5k 个基于有效性的 rollup，具体取决于我们是否计算具有零铸币的 Merkle 树]。

因此，很明显，ZK Compression 是为 Solana 架构量身定制的独特解决方案。它是一种新颖的原语，不同于 ZK Rollups，它增强了可扩展性和效率，而没有 Rollups 的复杂性和分离性。

<!--EndFragment--> <!--StartFragment-->

Solana 上的 ZK 现状

我在 Helius 的第一项写作任务是介绍[Solana 的 v1.16 更新]。我非常高兴了解到对零知识证明更好的运行时支持，并在文章中介绍了它。然而，这些改进被推迟了。我犯了一个错误，在[v1.17 更新文章]中再次更详细地介绍了这些改进，因为这些改进再次被推迟了。我甚至懒得在[v1.18 更新文章]中介绍它们。自然，我很失望，[其他人也表达了沮丧]。 

尽管存在这种情绪，但 Solana 上有一个新兴的 ZK 开发者社区，尽管规模很小。最初，[Light Protocol]专注于[以 PSP（私有 Solana 程序）的形式执行私有程序]，之后他们开始专注于 ZK 压缩。Dark [protocol])也是一个基于 Solana 构建的[未来]隐私协议。它缺乏一个通过提案做出贡献的中央团队。Arcium ，原名[Elusiv ][，正在使用多方计算执行环境 [MXE]) 为其自己的并行化机密计算网络提供支持。Bonsol是一个零知识“协处理器”，允许开发人员运行任何[risc0 映像]并在 Solana 上验证它（即可验证的链下计算）。[教程]和[零知识证明相关链接列表]也已流传开来。

最值得注意的是，[ZK 代币证明程序]验证了几个零知识证明，这些证明专门用于与[Pedersen 承诺]和[curve25519]上的[Twisted ElGamal 加密]配合使用。它支持[机密传输]，机密传输使用零知识证明来加密 SPL 代币的余额和交易金额。目标是保密而不是匿名。[同态加密]允许对加密数据执行计算而无需解密。为此，机密传输使用 Twisted ElGamal 加密对密文进行隐藏的数学运算，并使用[Sigma 协议]来验证这些传输而不泄露敏感信息。只有拥有解密密钥的帐户持有者才能查看他们的加密余额。但是，[全球审计系统]允许通过单独的解密密钥进行选择性读取访问，以实现合规性和审计。

然而，形势开始逆转。随着这些改进最终在 Devnet 和 Mainnet-Beta 上实现，Solana 有望成为 ZK 巨头。[目前 Solana 上有三个ZK 系统调用]。

Poseidon 系统调用

[Poseidon]是专为零知识证明设计的哈希函数系列，用于 Zcash、Mina 和 Light Protocol 等项目。与[SHA-256]等传统通用哈希函数相比，Poseidon 在零知识证明方面的计算效率更高。 

Poseidon 哈希函数是零知识友好的，因为它们：

• 高效地执行算术运算
• 由于其算术友好的设计、优化的[S 盒]和较少的轮数，需要更少的步骤来生成证明（即具有较低的电路复杂度）
• 使用可处理任意长度的位序列的算法，使其用途极为广泛

过去，在一次交易中计算 Poseidon 哈希的成本过于高昂。然而，随着 epoch 644 和[Poseidon 系统调用]的激活（即，系统调用接受 2D 字节切片输入并计算相应的 Poseidon 哈希作为其输出），这种情况发生了变化。这令人兴奋，因为 ZK Compression 依赖 Poseidon 哈希来处理其状态树。

Poseidon 系统调用使用具有以下参数的[BN254 曲线计算哈希值：]

• S 盒— x 5 个替换盒
• 输入— 1 ≤ n ≤ 12
• 宽度— 2 ≤ t ≤ 13
• 轮次— 8 个完整轮次和部分轮次，具体取决于t : [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

[其输出将是以指定的字节]顺序编码为 32 个字节的 Posiedon 哈希结果。

请注意，此处用于系统调用的特定变体是 Poseidon，它具有x 5 S 盒和针对 BN254 曲线定制的参数。light [-poseidon包]将有助于计算这些哈希值。该包本身经过[审核]并与[Circom]兼容。

alt_bn128 系统调用

alt_bn128 指的是 Barreto-Naehrig (BN-128) 椭圆曲线的实现，这是一种配对友好型曲线，可实现高效的 zk-SNARKs 证明和计算。该曲线对于各种零知识证明系统都至关重要，包括 Groth16，ZK Compression 正是依靠 Groth16 来验证状态转换。此系统调用显著减少了每个证明所需的空间，为高效的链上证明提供了至关重要的空间和时间优化。 

[sol_alt_bn128_group_op]系统[调用]在 alt_bn128 曲线上计算操作，包括 G1 中的点加法（G1 只是指给定椭圆曲线上的一组点）、G1 中的标量乘法以及配对：

• 输入- 大端格式的序列化点和标量
• 运算— G1 中的点加法、G1 中的标量乘法、配对（G1 中的 1 个点和 G2 中的 1 个点）
• 输出- G1 中的点或配对结果序列化为 256 位整数

[sol_alt_bn128_compression]系统[调用]在 alt_bn128 曲线上压缩或解压缩 G1 或 G2 组中的点，并以标准大端格式返回这些点。

这些系统调用目前在测试网上运行，[一旦加载程序重新编译阶段的错误得到解决，它们似乎就会在 Devnet 上可用]，如[SIMD-0075: Secp256r1 预编译]。该提案旨在简化 alt_bn128 系统调用以及 Poseidon 系统调用的错误代码，确保一致性并降低由于验证器返回的不同错误代码导致共识失败的风险。

alt_bn128 系统调用可用于固定证明大小的常规向量承诺，例如 KZG 承诺。因此，它们可与任何配对友好曲线配合使用，并且不需要 ZK 证明器电路。 

互操作性

Solana 是一条 ZK 链。它是一条高性能的第 1 层区块链，费用低廉，运行时支持椭圆曲线操作。零知识证明相关系统调用的实现和支持促进了创新，允许在 Solana 之上构建新颖的原语和应用程序，例如 ZK Compression。

引入 alt_bn128 系统调用缩小了 Solana 与基于 Solidity 的合约之间的可组合性差距，这些合约依赖于[EIP-196]、[EIP-197]中指定的椭圆曲线操作的预编译合约。这些操作有助于在以太坊的 gas 限制内进行 zk-SNARK 证明验证。因此，依赖这些椭圆曲线操作的 Solidity 合约现在可以更轻松地过渡到 Solana，甚至 与Solana 互操作。

SIMD-0075 对于互操作性解决方案至关重要。一旦全面实施，此 SIMD 将使即将推出的（将 DA 从 Celestia 传输到 Solana）等项目能够使用链下证明生成和链上验证来存储 Merkle 承诺。如果没有这些系统调用，就不可能在 Solana 上验证 Groth16 证明。此外，这些系统调用增强了信任最小化的桥接和互操作性，允许其他区块链无缝且安全地与 Solana 交互。  

Toly 是对的——有了 Solana 运行时的所有这些增强，Solana 就成为了以太坊 L2。很快，没有什么能阻止你将 Solana 的所有区块提交到以太坊上的某个数据验证桥接合约中。相反，没有什么能阻止你将以太坊的所有区块提交到 Solana 上的某个数据验证桥接程序中。通过零知识证明而不是过时的桥接来加速的双向互操作性，是 Solana 光明而崭露头角的未来。

结论

毫无疑问，零知识证明是密码学家开发的最强大的原语之一（如果不是最强大的原语的话）。通过研究第一篇文章中这一概念背后的理论、数学和密码学，从第一原理开始，这一点变得不言而喻。潜在的应用是无穷无尽的，从链上游戏的真正战争迷雾到证明 L2 上的一组交易导致了特定的状态转换。

本系列文章分为两部分，本可以再写 50 多页，涵盖同态加密的复杂性、Circom 中的编码电路以及对不同承诺方案的分析。然而，这些文章的目的是让读者了解零知识证明的基础知识，以便他们可以利用这些新知识并将其应用于 Solana。 

Solana 正在成为 ZK 巨头。从 ZK 压缩的发布到不久的将来上线的各种系统调用，其重要性不容小觑。虽然像 ZK 压缩这样的原语为普通开发人员抽象出了零知识证明的所有复杂性，但了解基础知识对于进一步讨论和 Solana 的开发至关重要。 

<!--EndFragment--> 作者：https://t.me/gtokentool