零知识证明：在 Solana 上的应用
非常感谢 Matt、Porter、Nick、Swen 和 bl0ckpain 审阅本系列文章。
引言
这是零知识证明入门系列的第二篇文章。在阅读本文之前，我强烈建议先阅读零知识证明：基础原理入门，因为它介绍了本文分析所需的底层理论、数学和密码学背景。本文假定你已掌握这些知识。因此，如果你还不了解零知识证明，我强烈建议先读完前一篇文章。本文旨在帮助你掌握参与 Solana 零知识证明讨论所需的知识，甚至进一步开发新颖、创新的零知识原语。
有了这些新知识，我们终于可以问：零知识证明究竟是什么？它们如何用于 Solana？
什么是零知识证明？
既然我们终于掌握了必要的理论、数学和密码学知识，自然应该问：零知识证明究竟是什么？
零知识证明是一种密码学过程，其中一方能够向另一方证明某个陈述为真，却不会泄露该陈述确实为真之外的任何额外信息。这些证明必须在统计意义上可靠、完备，并能防止信息泄露。
人们通常希望以零知识方式证明两类陈述。概括来说：
- 关于事实的陈述（例如，这个特定图存在三着色）
- 关于知识的陈述（例如，我知道 N 的因式分解）
第一类陈述最终涉及宇宙的某种内在属性，即某个从根本上成立的事实，例如 1 + 1 = 2。第二类陈述称为知识证明。也就是说，它不仅证明某件事为真，还依赖证明者掌握的知识。
如前所述，为了证明这些陈述，我们可以使用交互式或非交互式证明。在交互式零知识证明中，证明者与验证者会进行多轮交互，直至验证者在排除合理怀疑后确信证明成立。Zcash 使用非交互式零知识证明，让用户能够进行匿名交易。
相比之下，在非交互式零知识证明中，证明会离线提交，证明者与验证者之间无需直接通信。证明者生成一份包含所有必要信息的证明，验证者则可以独立验证，无需进一步交互。Filecoin 使用非交互式零知识证明来证明用户已存储数据，同时不披露数据本身。
zk-SNARKs 与电路
zk-SNARK 是简洁（Succinct**）非交互式（Non-interactive）知识（Knowledge）论证（ARgument）**。这类零知识证明尤其高效、紧凑，也就是所谓的简洁。如果证明大小和验证所需时间的增长速度都低于待验证计算的增长速度，就可以认为该证明是简洁的。因此，如果希望获得简洁证明，就不能让验证者在每轮哈希中执行额外工作，否则验证时间将与计算量成正比。多项式和 Fiat-Shamir 启发式方法让简洁证明成为可能。
无论待证明陈述多么复杂，zk-SNARKs 都能保持较小的证明体积和较快的验证速度。这正是 zk-SNARKs 对 rollup 极具吸引力的原因：我们可以用它证明某个 L2 的所有交易均有效，而且证明足够小，能够在 L1 上验证。Mina 等协议更进一步，采用递归证明，以固定大小的证明验证整条链的全部历史。Pickles 是 Mina 的新证明系统及配套工具包，也是首个已部署、无需可信设置即可进行递归组合的 zk-SNARK。请注意，这里的递归组合指的是电路。
电路描述你希望证明的计算。它由一系列数学运算组成，接收输入并产生输出。在零知识证明中，电路用于表示某项计算已被正确执行，同时不披露计算输入。一般工作流程如下：
- 编写和编译电路 — 我们需要编写并编译电路。它可以很简单，例如在由素数 p = 7 定义的有限域上创建一个算术电路，并执行 x * y = z 计算。这里的基本思路是：将待证明的计算表示为变量之间的一组约束，将这些约束化为多项式方程，再编写代码，以某种方式把所有值映射到新的代数结构（即同态）。编译过程会输出多个构件，包括电路定义的约束集，以及后续步骤中使用的脚本或二进制文件
- 可信设置仪式 — 根据用于生成证明密钥和验证密钥的 zk-SNARK 类型，可能需要举行设置仪式
- 执行电路 — 必须像运行某种程序一样，使用编译时生成的脚本或二进制文件执行电路。用户输入公开输入和私有输入，随后系统计算所有中间变量和输出变量的值。见证也称为轨迹，是全部计算步骤的记录
- 生成证明 — 利用第二步中的证明密钥和第三步中的见证，证明者可以生成零知识证明，证明电路定义的所有约束均成立，同时只披露输出值。该证明会发送给验证者
- 验证证明 — 验证者使用提交的证明和验证密钥，验证该证明对于其公开输出是否正确
某些类型的 zk-SNARK（如 Groth16）要求每个电路都进行一次可信设置。这可能带来阻碍，因为每个新程序都需要举行新的设置仪式。其他 zk-SNARK（如 PlonK）只需要一次通用可信设置，从而简化整个流程。还有一些零知识证明类型（如 zk-STARKs）则完全不需要可信设置。
zk-STARKs
zk-STARK 是可扩展（Scalable**）透明（Transparent）知识（Knowledge）论证（ARgument）**。zk-STARKs 由 StarkWare 发明，并在这篇 2018 年的论文中首次提出，作为 zk-SNARKs 的替代方案。其本质是让区块链将计算转移给单个链下 STARK 证明者，再通过链上 STARK 验证者验证这些计算的完整性。
zk-STARKs 被视为零知识证明，是因为链下证明者使用的输入不会向区块链公开，从而保护用户隐私。zk-STARKs 具备可扩展性，因为将计算移至链下能显著降低 L1 的验证成本。其证明规模呈线性增长，而 zk-SNARKs 仅能实现准线性扩展。此外，zk-STARKs 不依赖复杂的可信设置仪式。他们认为，这类仪式容易受到有毒废料影响：如果仪式执行不当，验证者可能会接受无效证明。相反，zk-STARKs 使用可公开验证的随机性建立证明者与验证者之间的交互。并且，只有真正执行了计算并掌握所需辅助输入的链下证明者才能生成这些证明。
zk-STARKs 通过提供可扩展、透明的知识论证，解决了 zk-SNARKs 的局限。它们采用的密码学假设也简单得多，完全不需要椭圆曲线等元素，而是完全依赖哈希和信息论，因此具备抗量子能力。不过，其证明大小通常达到数百 KB，这会限制它们在带宽或存储空间有限的环境（如区块链）中的可行性。 请注意，一些更复杂的证明设置和 zkVM 会将 zk-STARKs 递归证明到 zk-SNARK 中，仅在最终验证步骤使用后者。
ZK Compression
状态增长问题
Solana 最紧迫的问题之一是状态增长问题。为理解这个问题，Solana 的状态存储在全节点磁盘上的 Accounts DB 中。这是一个键值存储，其中数据库的每个条目称为一个账户。每个账户都有一个 32 字节地址，可存储的数据量介于 0 到 10 MB 之间。目前，存储 10 MB 数据的成本约为 70 SOL，无论这些数据存储在一个 10 MB 账户中，还是分散在一千个 10 KB 账户中。根据 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 根，而底层数据则存储在账本中。有效性证明是一种简洁的零知识证明，用于证明 m 棵状态树中有 n 个账户作为叶节点存在，同时将证明大小恒定保持在 128 字节。这些证明在链下生成、链上验证，从而降低 Solana 的整体计算负担。ZK Compression 的证明者系统采用 Groth16，这是一种知名的基于配对的 zk-SNARK。
不过，这些账户并非常规 Solana 账户，而是压缩账户。
压缩账户模型
ZK 压缩状态存储在压缩账户中。这些账户与常规 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 可将其降至不到 50 美分。
ZK Compression 也与当前 Solana 规范高度兼容。例如，压缩账户的结构与常规 Solana 账户几乎相同。它还支持并行执行等 Solana 特有创新。也就是说，同一状态树（即承诺）下访问不同压缩账户的任意两笔交易都可以并行执行。此外，ZK Compression 还增强了同步原子可组合性。例如，一笔列出 n 个压缩账户和 m 个常规账户的交易是完全有效的配置。引用压缩账户的指令可以调用引用常规账户的另一条指令或程序。即使账户压缩在不同状态树下，也是如此。如果一条指令失败，整笔交易都会回滚，而且一条指令造成的更改对下一条指令可见。这与 ZK rollup 不同；除非加锁，否则 rollup 之间无法同步或以原子方式相互调用。因此，自然有必要比较 ZK Compression 与 rollup。
ZK Compression 不是 Rollup
ZK Compression 不是 rollup。虽然两者依赖相同技术，但实现方式不同。rollup 分为两类：
- Optimistic Rollups — 在给定时间段内，所有交易都被假定为有效，并通过欺诈证明在该时间窗口内证明虚假交易
- 零知识 Rollups — 使用有效性证明即时证明交易有效或无效
零知识 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 上的 Twisted ElGamal 加密使用的零知识证明。它为机密转账提供支持，使用零知识证明加密 SPL 代币的余额和交易金额。其目标是保密性，而非匿名性。同态加密允许在无需解密的情况下对加密数据执行计算。为此，机密转账使用 Twisted ElGamal 加密对密文执行隐藏的数学运算，并使用 Sigma 协议验证这些转账，而不泄露敏感信息。只有持有解密密钥的账户持有者才能查看其加密余额。不过，全局审计员系统允许通过独立的解密密钥，为合规和审计提供选择性读取权限。
Solana 上的可编程私有余额现已作为 Solana Privacy Rings 推出。
由于 SIMD-0153：ZK ElGamal Proof Program 已获通过，ZK Token Proof Program 目前是被阻止启用的功能。这一新 SIMD 旨在弃用专为 SPL Token 程序设计的现有 ZK Token Proof program，并将其替换为不依赖任何特定应用的通用零知识证明程序。在 Anza 和 Firedancer 团队的支持下，该 SIMD 已合并。
不过，形势正在转变。随着这些改进终于进入 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-boxes — 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-SNARKs 证明和计算。该曲线对包括 Groth16 在内的多种零知识证明系统至关重要，而 ZK Compression 正是依靠 Groth16 验证状态转换。这一 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 预编译，加载程序重新编译阶段的错误得到解决后，它们似乎就会在 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 中规定的椭圆曲线运算。这些运算支持在 Ethereum 的 gas 限制内验证 zk-SNARK 证明。因此，依赖这些椭圆曲线运算的 Solidity 合约现在或许可以更轻松地迁移到 Solana，甚至与 Solana 实现互操作。
SIMD-0075 对互操作性解决方案至关重要。全面实施后，blobsream-solana 等即将推出的项目（该项目将 DA 从 Celestia 流式传输到 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 上相关讨论和开发仍然极具价值。
如果你读到了这里，谢谢你，anon！记得在下方输入电子邮件地址，这样就不会错过 Solana 的任何最新动态。准备好深入探索了吗？立即阅读 Helius 博客上的最新文章，继续你的 Solana 之旅。
其他资源
订阅 Helius
及时了解 Solana 开发的最新动态，并在我们发布新内容时收到更新