零知识证明：其在 Solana 上的应用
特别感谢 Matt、Porter、Nick、Swen 和 bl0ckpain 审阅本系列文章。
引言
这是零知识证明入门系列的第二篇文章。强烈建议你先阅读零知识证明：基础原理简介，因为它介绍了本文分析所需的底层理论、数学和密码学背景。本文假设读者已经掌握这些知识。因此，如果你还不了解零知识证明，强烈建议先阅读上一篇文章。本文旨在帮助你掌握必要知识，以便参与 Solana 上有关零知识证明的讨论，甚至进一步开发新颖、创新的零知识原语。
有了这些新知识，我们终于可以开始探讨：零知识证明究竟是什么？它们如何用于 Solana？
什么是零知识证明？
现在，我们终于掌握了必要的理论、数学和密码学知识，自然要问：零知识证明究竟是什么？
零知识证明是一种密码学过程，其中一方可以向另一方证明某个陈述为真，而不会泄露除该陈述确实为真之外的任何其他信息。这些证明必须在统计意义上可靠、完备，并且能够防止信息泄露。
人们通常希望用零知识证明两类陈述。概括而言：
- 关于事实的陈述（例如，这个特定图存在三着色）
- 关于知识的陈述（例如，我知道 N 的因式分解）
第一类陈述最终涉及宇宙的某种内在属性，即类似 1 + 1 = 2 这样从根本上成立的事实。第二类陈述称为知识证明。也就是说，它不只是证明某件事为真，还取决于证明者所掌握的知识。
如前所述，为证明这些陈述，我们可以采用交互式或非交互式证明。在交互式零知识证明中，证明者与验证者会进行多轮交互，直到验证者在合理怀疑之外确信陈述成立。Zcash 使用非交互式零知识证明，让用户可以进行匿名交易。
相比之下，在非交互式零知识证明中，证明会离线交付，证明者和验证者之间无需直接通信。证明者生成包含全部必要信息的证明，验证者无需进一步交互即可独立验证该证明。Filecoin 使用非交互式零知识证明来证明用户已经存储数据，同时不披露数据本身。
zk-SNARK 与电路
zk-SNARK 是简洁（S）、非交互式（N）的知识论证（ARK）。这类零知识证明尤其高效、紧凑，也就是所谓的简洁。如果证明大小和验证所需时间的增长速度都低于待验证计算的增长速度，该证明就被视为简洁证明。因此，如果我们希望得到简洁证明，就不能让验证者为每轮哈希执行一些工作，否则验证时间将与计算量成正比。多项式和 Fiat-Shamir 启发式方法让简洁证明成为可能。
无论待证明陈述多么复杂，zk-SNARK 都能保持较小的证明大小和相对较快的验证速度。这正是 zk-SNARK 对 rollup 极具吸引力的原因：我们可以证明某个 L2 上的所有交易均有效，而且证明足够小，可以在 L1 上验证。Mina 等协议更进一步，使用递归证明，以恒定大小的证明验证整条链的历史。Pickles 是 Mina 的新证明系统及相关工具包，也是首个已部署且无需可信设置即可进行递归组合的 zk-SNARK。注意，这里的递归组合指的是电路。
电路用于描述你想要证明的计算。它由一系列数学运算组成，接收若干输入并生成输出。在零知识证明中，电路用于表示某项计算已被正确执行，同时不泄露计算输入。一般工作流程如下：
- 编写并编译电路 — 我们需要编写和编译电路。它可以很简单，例如在由素数 p = 7 定义的有限域上创建一个算术电路，计算 x * y = z。总体思路是：将待证明的计算表示为变量之间的一组约束，把这些约束化简为多项式方程，再编写代码，以一致方式将所有值映射到新的代数结构（即同态）。编译过程会输出多个产物，包括电路定义的约束集合，以及后续步骤要使用的脚本或二进制文件
- 可信设置仪式 — 根据用于生成证明密钥和验证密钥的 zk-SNARK 类型，可能需要举行可信设置仪式
- 执行电路 — 必须使用编译期间生成的脚本或二进制文件，将电路像某种程序一样执行。用户输入公开和私有输入，随后系统计算所有中间变量和输出变量的值。见证也称为轨迹，是计算所有步骤的记录
- 生成证明 — 利用第二步中的证明密钥和第三步中的见证，证明者可以生成零知识证明，证明电路中定义的所有约束均成立，同时只披露输出值。该证明随后会发送给验证者
- 验证证明 — 验证者使用提交的证明和验证密钥，验证该证明对于其公开输出是否正确
某些类型的 zk-SNARK（例如 Groth16）要求每个电路分别进行可信设置。这可能构成阻碍，因为每个新程序都需要举行一次新的仪式。其他 zk-SNARK（例如 PlonK）只需一次通用可信设置，从而简化整个流程。还有一些零知识证明类型（例如 zk-STARK）则完全不需要可信设置。
zk-STARK
zk-STARK 是可扩展（S）、透明（T）的知识论证（ARK）。zk-STARK 由 StarkWare 发明，并在这篇 2018 年的论文中首次提出，作为 zk-SNARK 的替代方案。本质上，它允许区块链把计算交给单个链下 STARK 证明者，并使用链上 STARK 验证者来验证这些计算的完整性。
zk-STARK 被视为零知识证明，是因为链下证明者使用的输入不会暴露给区块链，从而保护用户隐私。zk-STARK 具有可扩展性，因为将计算移至链下会显著降低 L1 验证成本。其证明也会线性扩展，而 zk-SNARK 只能实现准线性扩展。此外，zk-STARK 不依赖复杂的可信设置仪式。其支持者认为，此类仪式容易产生有毒废料：如果仪式未正确执行，验证者可能接受无效证明。相反，zk-STARK 使用可公开验证的随机性来建立证明者和验证者之间的交互。而且，只有真正执行了计算并掌握所需辅助输入的链下证明者才能生成这些证明。
zk-STARK 通过提供可扩展、透明的知识论证，解决了 zk-SNARK 的局限。它采用的密码学假设也简单得多，完全不需要椭圆曲线等元素。相反，它完全依赖哈希和信息论，因此具备抗量子能力。不过，其证明大小通常为数百 KB，这可能限制其在区块链等带宽或存储受限环境中的可行性。 需要注意的是，一些更复杂的证明设置和 zkVM 会结合多种方案：先将 zk-STARK 递归证明到一个 zk-SNARK 中，仅在最终验证步骤使用后者。
ZK Compression
状态增长问题
Solana 最紧迫的问题之一是状态增长问题。为了说明这一问题，Solana 的状态存储在全节点磁盘上的 Accounts DB 中。这是一个键值存储，数据库中的每个条目称为一个账户。每个账户的地址为 32 字节，可存储的数据量介于 0 到 10 MB。目前，无论是存储在一个 10 MB 账户中，还是分散到一千个 10 KB 账户中，存储 10 MB 数据的成本都约为 70 SOL。根据 Toly 关于状态增长问题的帖子，每天大约会有一百万个新账户加入链上，使状态总量超过 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）或较慢但便宜的存储（即磁盘）变得至关重要。
交易与状态增长
每笔 Solana 交易都需要指定它要读取和写入的所有账户。目前，交易大小上限为 1232 字节，必须包含以下内容：
- 头部（3 字节）
- 签名（每个 64 字节）
- 账户地址（每个 32 字节）
- 指令数据（任意大小）
- 近期区块哈希（32 字节）
执行交易时会发生以下过程：
- 健全性检查 — 只有近期交易才有效，并且系统会对交易执行去重、结构验证、费用和签名检查
- 程序加载 — 根据程序地址加载程序字节码，并实例化 Solana 虚拟机（SVM）
- 账户加载 — 检查交易引用的所有账户，将其从存储加载到内存中，再传递给 SVM
- 执行 — 执行程序字节码
- 同步 — 将所有被修改的账户同步回存储
随着状态持续增长，这一生命周期会带来多项挑战。具体而言，链上状态成本高昂，磁盘中存储的账户越多，快照和索引就越大。此外，并非所有账户都会频繁访问，持续为它们支付资源成本并不高效。
使用 ZK Compression 简化状态管理
交易不必将所有账户存储在磁盘上并在需要时读取，而是可以把账户数据作为交易载荷的一部分传入。我们可以使用 Merkle 树，确保提交交易的用户提供正确状态。Merkle 证明是对某些数据作出承诺的一种方式。这样，系统便可针对承诺验证证明，以确认传入的状态正确，并确保用户没有虚报所提供的状态。
这些证明虽然安全，但可能相当大。例如，如果一棵树包含 10 万个账户，证明大小将达到 544 字节。为多个账户提供证明，很快就会超过 1232 字节的交易大小限制。幸运的是，我们可以使用更高效的证明系统来规避这一问题。使用 KZG 或 Pedersen 承诺等恒定证明大小的承诺方案，可以缩小证明，使其更适合纳入交易大小限制之内。
ZK Compression 本质上是一种解决 Merkle 证明大小问题的机制。它利用 Solana 的账本，在无需承担相关链上存储成本的情况下，证明某项计算已正确完成。
什么是 ZK Compression？
ZK Compression 是一种新的原语，允许开发者压缩链上状态，在保留安全性、性能和可组合性的同时，将状态成本降低数个数量级。例如，目前创建 100 个代币账户大约需要 ~0.2 SOL，而使用 ZK Compression 后，成本可降低 5000 倍，降至 ~0.00004。
ZK Compression 利用零知识证明来验证状态转换，而不暴露底层数据。它将多个账户归入单个可验证的 Merkle 根，该根存储在链上，而底层数据存储在账本中。有效性证明是一种简洁零知识证明，用于证明 n 个账户作为叶节点存在于 m 棵状态树中，同时将证明大小恒定保持在 128 字节。这些证明在链下生成、链上验证，从而降低 Solana 的总体计算负担。ZK Compression 的证明系统使用 Groth16，这是一种著名的基于配对的 zk-SNARK。
不过，这些账户并非常规 Solana 账户，而是压缩账户。
压缩账户模型
经过 ZK Compression 压缩的状态存储在压缩账户中。这些账户与常规 Solana 账户相似，但存在几项关键差异，可以提高效率和可扩展性：
- 哈希标识 — 每个压缩账户都可以通过其哈希来标识
- 写入时哈希变化 — 对压缩账户执行任何写入操作都会改变其哈希
- 可选地址 — 可以选择将某个地址设为压缩账户的永久唯一 ID。这对 NFT 等特定用例非常有用。该字段之所以可选，是为了避免计算开销，因为压缩账户可以通过其哈希引用
- 稀疏状态树 — 所有压缩账户都存储在 Merkle 树中，链上账户空间只存储树的状态根（即 Merkle 根）。更具体地说，状态树是一种基于 Poseidon 哈希的并发 Merkle 树
压缩程序派生地址（PDA）可通过其唯一且持久的地址进行标识。其布局与常规 PDA 账户类似，都包含 Data、Lamports、Owner 和 Address 字段。不过，与常规 PDA 不同，Data 字段内置了 AccountData 结构，其中包含 Discriminator、Data 和 DataHash 字段。
节点
不同类型的节点在支持 ZK Compression 方面发挥着关键作用。任何人都可以运行 Photon RPC 节点、Prover 节点或 Light Forester 节点，以连接 Devnet 和 Mainnet-Beta。对于本地开发，ZK Compression CLI test-validator 命令会启动一个单节点 Solana 集群，其中包含所有相关节点（即 Photon RPC 和 Prover），以及系统程序、账户和运行时功能。
Photon RPC 节点会为压缩程序建立索引。这使客户端能够读取并构建与压缩状态交互的交易。标准压缩索引器名为 Photon，由 Helius 提供。这类节点只需少量设置即可在本地运行，但需要将其指向现有 RPC。
Prover 节点用于生成状态包含关系的有效性证明。可以使用 ZK Compression RPC API 规范中的 getValidityProof 端点获取证明。Prover 节点既可作为独立节点运行，也可与另一个 RPC 捆绑运行。请注意，标准 Photon RPC 实现中包含 Prover 节点。
Light Forester 节点负责管理共享状态树和程序自有状态树的创建、轮换和更新。它适合希望由 Light Forester 节点网络为其程序自有状态树提供服务的开发者。
信任假设
任何人都可以运行上述任一种节点，也可以存储生成证明和提交交易所需的原始数据。这引入了一项影响压缩状态活性的信任假设。具体而言，如果数据丢失或延迟，除非用户自行存储了数据，否则交易将无法提交。由于只需一个诚实节点提供数据，而且证明可以自行验证，因此问题主要在于活性和潜在审查，而非安全性。
此外，用于验证压缩账户的程序目前仍可升级，这又引入了一项信任假设。这样做是为了能够修改程序以修复问题，或使其适应新的要求。不过，一旦程序达到稳定且安全的状态，未来可以将其设为不可变或冻结。
另一项有关活性的信任假设来自 Forester 节点。这些节点负责推进状态根，并通过清空无效化队列和异步推进状态根来管理队列。在此过程中，账户哈希会被替换为零，从而使其失效。将推进和无效化分离，可以在确保交易符合 Solana 大小限制的同时，让压缩状态转换立即获得最终性。由于无效化队列大小固定，Forester 节点对协议活性至关重要。队列一旦填满，就会导致相关状态树失去活性。所幸，Forester 节点会通过清空队列来避免这种情况。不过，仍然需要有人运行这些节点，帮助维护协议的完整性和活性。没有这些节点，ZK Compression 只能支持大约两千个账户/地址。
局限性
即使不需要隐藏任何内容，零知识证明也能将需要多个计算步骤的问题转化为只需验证单个证明的问题，以确认计算已正确执行。而且，这些计算不必局限于判断某个特定叶节点是否属于某棵树，还可以是任意计算。不过，这会带来成本。
使用 ZK Compression 前，请考虑以下因素：
- 交易大小更大 — ZK Compression 的有效性证明需要 128 字节，还需发送要在链上读取/写入的数据
- 计算单元用量更高 — ZK Compression 会显著增加计算单元（CU）用量：有效性证明验证约需 ~100k CU，系统使用约需 ~100k CU，每次读取或写入压缩账户约需 ~6k CU
- 每笔交易的状态成本 — 每次写入操作都会产生少量网络成本，因为它必须使先前的压缩账户状态失效，并将新的压缩状态追加到状态树中。因此，如果一个压缩账户需要多次更新状态，其整个生命周期成本完全可能超过未压缩账户
在以下情况下，使用常规账户可能更合适：
- 账户更新频繁
- 账户生命周期内的写入次数很多（即 >1000x）
- 账户存储了大量必须在链上交易中访问的数据
优势
ZK Compression 是一种可扩展、安全、高效且灵活的原语，可以直接解决 Solana 的状态增长问题，并支持广泛的应用和用例。其最明显的优势可以说是降低状态成本。ZK Compression 将状态安全地存储在成本更低的账本空间中，并通过状态指纹将链上存储降至最低，让应用可以轻松扩展至数百万用户。以铸造 10,000 个代币账户为例，假设 SOL 价格为 130 美元，成本约为 2,600 美元。ZK Compression 可将其降至不到五十美分。
ZK Compression 也能很好地兼容现有 Solana 规范。例如，压缩账户的结构与常规 Solana 账户几乎完全相同。它还支持并行处理等 Solana 特有创新。也就是说，同一状态树（即承诺）下访问不同压缩账户的任意两笔交易都可以并行执行。此外，ZK Compression 还增强了同步原子可组合性。例如，一笔列出 n 个压缩账户和 m 个常规账户的交易是完全有效的配置。引用压缩账户的指令可以调用另一个引用常规账户的指令或程序。即使这些账户压缩在不同状态树下，情况也是如此。如果一条指令失败，整笔交易都会回滚，而且一条指令产生的更改对下一条指令可见。这与 ZK rollup 不同，除非加锁，否则多个 rollup 无法同步或原子化地相互调用。自然，这值得我们比较 ZK Compression 与 rollup。
ZK Compression 不是 Rollup
ZK Compression 不是 rollup。尽管两者依赖相同的技术，但其实现方式不同。rollup 分为两类：
- Optimistic Rollup — 在给定时间段内，所有交易均被假定为有效，并使用欺诈证明来证明该时限内的无效交易
- 零知识 Rollup — 使用有效性证明即时证明交易有效或无效
零知识 rollup 的完整状态在基础层（即 Ethereum）上表示为单个根。因此，许多人声称 ZK Compression 实际上就是 rollup。然而，两者存在多项关键差异。
假设一个 ZK rollup 中包含 500 笔交易。在这种情况下，整个 rollup 会被视为单个电路。全部 500 笔交易会一起验证，最终生成一个证明，确认状态根已从 A 变为 B。验证该证明后，负责管理 L1 和 L2 交互的智能合约会相应更新状态根。相比之下，使用 ZK Compression 时，500 笔交易中的每一笔都会分别生成证明，以验证账户数据的正确性。这些交易由 SVM 本身执行，每个证明通过验证后，相关账户就会被视为“常规”账户。
如果将 ZK Compression 归类为 rollup，就意味着 Solana 上存储的任何 Merkle 根都可视为基于有效性的 rollup。如果查看 Solana 上当前所有压缩 cNFT 的根，那么根据是否统计铸造量为零的 Merkle 树，大约存在 4,000 至 5,000 个基于有效性的 rollup。
因此可以明确看出，ZK Compression 是专为 Solana 架构设计的独特解决方案。它是一种不同于 ZK rollup 的新型原语，无需引入 rollup 的复杂性和隔离性，即可提高可扩展性和效率。
Solana 上 ZK 与互操作性的未来
Solana 上 ZK 的现状
我加入 Helius 后的首批写作任务之一，就是介绍 Solana v1.16 更新。得知运行时将更好地支持零知识证明时，我非常兴奋，并在文章中对此进行了介绍。但这些改进后来被推迟了。之后，我又犯了同样的错误，在 v1.17 更新文章中更详细地介绍了这些改进，结果它们再次延期。到了 v1.18 更新文章，我甚至懒得再提。自然，我感到很失望，其他人也表达了不满。
尽管如此，Solana 上仍在形成一个规模虽小但不断成长的 ZK 开发者社区。Light Protocol 最初专注于以 PSP（Private Solana Programs）形式执行私有程序，后来将重点调整为 ZK Compression。Dark protocol 也是一个构建在 Solana 上的未来主义治理隐私协议。它没有中心化团队，贡献通过提案完成。Arcium 的前身是 Elusiv，它使用多方计算执行环境（MXE）为自己的并行保密计算网络提供支持。Bonsol 是一种零知识“协处理器”，允许开发者运行任意 risc0 镜像并在 Solana 上进行验证（即可验证的链下计算）。社区中也出现了相关教程和零知识证明相关链接列表。
其中最值得关注的是，ZK Token Proof Program 可以验证多种零知识证明，这些证明专门用于配合 Pedersen 承诺和 curve25519 上的扭曲 ElGamal 加密。它为保密转账提供支持，后者使用零知识证明加密 SPL 代币的余额和交易金额，目标是保密性而非匿名性。同态加密允许直接对加密数据执行计算，无需先将其解密。为此，保密转账使用扭曲 ElGamal 加密对密文执行隐藏的数学运算，并使用 Sigma 协议在不泄露敏感信息的情况下验证这些转账。只有持有解密密钥的账户持有人才能查看其加密余额。不过，全局审计员系统允许通过单独的解密密钥授予选择性读取权限，以满足合规和审计要求。
由于 SIMD-0153：ZK ElGamal Proof Program 获得通过，ZK Token Proof Program 目前是被阻止启用的功能。这项新 SIMD 旨在弃用专为 SPL Token 程序设计的现有 ZK Token Proof 程序，并以不依赖任何特定应用的通用零知识证明程序取代它。该 SIMD 已合并，并获得 Anza 和 Firedancer 团队的支持。
然而，形势正在转变。随着这些改进最终登陆 Devnet 和 Mainnet-Beta，Solana 正在崛起为 ZK 巨头。目前已有三个 ZK syscall 在 Solana 上线。
Poseidon Syscall
Poseidon 是专为零知识证明设计的一系列哈希函数，已用于 Zcash、Mina 和 Light Protocol 等项目。对于零知识证明而言，Poseidon 的计算效率高于 SHA-256 等传统通用哈希函数。
Poseidon 哈希函数对零知识证明友好，原因包括：
- 能够高效执行算术运算
- 由于其算术友好型设计、经过优化的 S-box 和较少的轮数，生成证明所需步骤更少（即电路复杂度更低）
- 使用可处理任意长度比特序列的算法，通用性极强
过去，在一笔交易中计算 Poseidon 哈希的成本过高。但随着 epoch 644 到来并启用 Poseidon syscall，情况发生了变化。该系统调用接收二维字节切片输入，并计算相应的 Poseidon 哈希作为输出。这令人振奋，因为 ZK Compression 的状态树依赖 Poseidon 哈希。
Poseidon syscall 使用 BN254 曲线和以下参数计算哈希：
- S-box — x5 代换盒
- 输入 — 1 ≤ n ≤ 12
- 宽度 — 2 ≤ t ≤ 13
- 轮数 — 8 个完整轮，以及取决于 t 的部分轮：[56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]
其输出是按照指定字节序编码为 32 字节的 Poseidon 哈希结果。
请注意，此 syscall 使用的具体变体是采用 x5 S-box 且参数针对 BN254 曲线定制的 Poseidon。light-poseidon crate 将用于计算这些哈希。该 crate 本身已经审计，并与 Circom 兼容。
alt_bn128 Syscall
alt_bn128 指 Barreto-Naehrig（BN-128）椭圆曲线的实现。它是一种配对友好型曲线，可高效执行 zk-SNARK 证明和计算。该曲线对多种零知识证明系统至关重要，其中包括 Groth16，而 ZK Compression 正是依靠它来验证状态转换。此 syscall 显著减少了每个证明所需的空间，为高效链上证明提供关键的空间和时间优化。
sol_alt_bn128_group_op syscall 用于计算 alt_bn128 曲线上的运算，包括 G1 中的点加法（G1 只是指给定椭圆曲线上的一组点）、G1 中的标量乘法和配对：
- 输入 — 采用大端格式序列化的点和标量
- 运算 — G1 中的点加法、G1 中的标量乘法、配对（G1 中 1 个点与 G2 中 1 个点）
- 输出 — G1 中的点，或序列化为 256 位整数的配对结果
sol_alt_bn128_compression syscall 用于压缩或解压 alt_bn128 曲线上 G1 或 G2 群中的点，并以标准大端格式返回这些点。
这些 syscall 目前已在 testnet 上线，并且根据 SIMD-0075：Secp256r1 Precompile，在已加载程序重新编译阶段的错误得到解决后，似乎就会在 Devnet 上可用。该提案旨在简化 alt_bn128 syscall 和 Poseidon syscall 的错误代码，确保一致性，并降低验证者返回不同错误代码所导致的共识失败风险。
alt_bn128 syscall 可用于 KZG 承诺等恒定证明大小的常规向量承诺。因此，它们可配合任何配对友好型曲线使用，而且不需要 ZK 证明者电路。
互操作性
Solana 是一条 ZK 链。它是一条高性能、低费用的 Layer 1 区块链，其运行时支持椭圆曲线运算。零知识证明相关 syscall 的实现和支持将促进创新，让 ZK Compression 等新型原语和应用可以构建在 Solana 之上。
alt_bn128 syscall 的引入缩小了 Solana 与基于 Solidity 的合约之间的可组合性差距。此类合约依赖预编译合约执行 EIP-196、EIP-197 和 EIP-198 中规定的椭圆曲线运算。这些运算使 zk-SNARK 证明能够在 Ethereum 的 gas 限制内完成验证。因此，依赖这些椭圆曲线运算的 Solidity 合约如今可能更容易迁移到 Solana，甚至与 Solana 实现互操作。
SIMD-0075 对互操作性解决方案至关重要。全面实施后，blobsream-solana 等即将推出的项目（它将把 Celestia 的 DA 流式传输到 Solana）将能够使用链下证明生成和链上验证来存储 Merkle 承诺。没有这些 syscall，就无法在 Solana 上验证 Groth16 证明。此外，这些 syscall 还会增强信任最小化的跨链桥和互操作性，让其他区块链能够与 Solana 无缝、安全地交互。
Toly 说得没错——随着 Solana 运行时获得这些增强功能，Solana 就是 Ethereum L2。很快，你将可以把 Solana 的所有区块提交到 Ethereum 上某个验证数据的桥接合约中，不再有任何阻碍。反过来，你也可以把 Ethereum 的所有区块提交到 Solana 上某个验证数据的桥接程序中。由零知识证明而非过时跨链桥加速的双向互操作性，为 Solana 展现了光明且蓬勃发展的未来。
结论
毫无疑问，零知识证明是密码学家开发出的最强大原语之一，甚至可能是最强大的原语。在第一篇文章中，我们从第一性原理出发，研究了这一概念背后的理论、数学和密码学后，这一点不言自明。其潜在应用无穷无尽，从为链上游戏实现真正的战争迷雾，到证明 L2 上的一组交易产生了特定状态转换。
这个分为两部分的系列本可以再写五十多页，深入讨论同态加密的复杂细节、使用 Circom 编写电路，以及分析不同的承诺方案。不过，这些文章的目标是帮助读者掌握零知识证明的基础知识，以便将新获得的知识应用到 Solana 上。
Solana 正在崛起为 ZK 巨头。从 ZK Compression 的发布，到各种 syscall 即将在近期上线，其重要性不容低估。ZK Compression 等原语为普通开发者抽象掉了零知识证明的全部复杂性，但理解基础原理对于推进 Solana 上的相关讨论与开发仍然具有不可估量的价值。
如果你读到了这里，谢谢你，匿名朋友！别忘了在下方输入电子邮箱，这样就不会错过 Solana 的任何最新动态。准备好深入探索了吗？立即浏览 Helius 博客上的最新文章，继续你的 Solana 之旅。
其他资源
订阅 Helius
及时了解 Solana 开发的最新动态，并在我们发布新内容时收到更新