关于 Solana v1.17 更新，你需要知道的一切
本文讲什么？
随着 Solana Labs 验证者客户端最新版本 1.17 获得绝对多数采用，Solana 网络迎来了一个重要里程碑。在近期网络中断后，验证者使用 1.17.20 版本重启。截至撰写本文时，~68.6% 的验证者正在运行 1.17.21，~31.3% 正在运行 1.17.20。这个新版本带来了一系列增强功能，旨在提升网络效率、可扩展性和应用场景。从零知识证明的开创性进展到 Gossip 协议的优化，v1.17 是 Solana 持续发展过程中的关键一步。
本文涵盖关于 Solana Labs 验证者客户端 1.17 版本更新你需要知道的一切。我们将探讨 v1.17 背后的严格测试、近期网络中断事件，以及此次更新实现的新功能。
v1.17 是如何测试的？
v1.17 自 2023 年 10 月 3 日起一直在测试网运行，并定期接受高交易负载压力测试。Solana Labs 还在主网 Beta 上部署了少量运行 v1.17 的金丝雀节点，以监控该版本在真实环境中的稳定性。过去几个月里，这些节点一直保持稳定。你可以前往 Solana Tech Discord 的 #canaries-monitoring 频道查看这些金丝雀节点的历史活动和进展。此外，从 2023 年 12 月 4 日起，一小部分自愿参与的主网 Beta 节点升级到了 v1.17。
团队开发了多个运行时模糊测试工具，用于执行部分随机化的交易，以发现边界情况或低频竞态条件。这些交易会在多个版本上执行，以确保性能一致。v1.17 已多次接受外部审计，相关报告会在可用后发布到 Solana 安全审计 GitHub 仓库。
2 月网络中断
2024 年 2 月 6 日 9:53 UTC，主网 Beta 发生中断，区块最终确认暂时停止。网络活动中断约五小时，直到 14:55 UTC 恢复共识。这次中断可追溯到一个与网络编译和缓存程序执行代码方式有关的错误，旧版程序加载器尤其受到影响。
根本原因在于验证者处理常用程序的即时编译（JIT）输出的方式。一个旨在优化此流程的新缓存系统无意中引入了这个致命错误。对于某些旧版程序，该系统可能陷入无限重新编译循环。由于大多数验证者都遇到了这个问题，无法继续处理交易，Solana 的共识机制因此停滞。
由于该错误与近期开发网中断存在许多相似之处，根本原因很快得到确认。1.17.20 经过修改以直接解决该问题，验证者随后协同重启网络。修复分为两部分：短期方案是弃用两个可能触发无限循环的旧版加载器，从而禁止触发该循环；更全面的方案则是调整新的程序缓存系统，防止未来出现类似问题。
ZK Token Proof Program
ZK Token Proof Program 原计划随 1.16 更新发布。但由于需要进行大规模审计，其激活被推迟。功能门激活计划将该程序标记为等待测试网激活，最低版本为 1.17.12。
机密转账
随着 ZK Token Proof Program 激活，机密转账终于可用。机密转账使用零知识证明加密 SPL 代币的余额和转账金额。其总体目标是保密，而非匿名。同态加密允许直接对加密数据执行计算，无需先解密。例如，余额可以直接相加或相减，无需对操作中的指定金额先解密再重新加密。因此，这些计算可以像处理明文一样完成，同时始终保持加密状态。
机密转账使用 Twisted ElGamal Encryption 和 Sigma Protocols 实现安全、私密的交易，且不会泄露敏感信息。
顺带说明：
- Twisted ElGamal Encryption 是标准 ElGamal 加密方案的一种简单变体，其中密文被拆分为加密消息的 Pedersen 承诺和解密句柄，从而可以对密文执行隐藏的数学运算
- Sigma Protocols 用于验证机密转账。它们是一类特殊的零知识证明，允许一方（即证明者）向另一方（即验证者）证明自己掌握某些信息，而无需披露这些信息
机密转账只允许持有解密密钥的账户查看其加密余额。全局审计者系统适用于需要第三方审查的场景（例如合规检查或审计）。该系统允许账户持有人通过独立的解密密钥，选择性地向特定账户授予读取权限，同时为代币铸造加入“审计者加密密钥”，以支持安全审计。
交易会为发送方、接收方和审计者金额使用加密参数，并配合证明来确保隐私和完整性。账户余额被拆分为“待处理”和“可用”，以防止抢跑攻击。否则，恶意用户可以向某个账户发送代币，使基于加密余额生成的证明失效。
需要注意的是，机密转账必须使用新的密钥对。
命令行支持
现在也可以通过 spl-token crate 使用机密转账的命令行界面（CLI）支持。激活后，create-token 命令得到扩展，加入了 –enable-confidential-transfers auto 标志。用户因此可以铸造启用了机密转账扩展的代币。此外还有许多其他实用命令，例如：
configure-confidential-transfer-account- 为已有账户配置机密转账。只有账户所有者可以为该账户配置机密转账deposit-confidential-tokens- 将代币从非机密账户存入机密账户。请注意，存入的代币将不再存在于账户的非机密余额中，因为它们已完全转入机密余额apply-pending-balance- 将余额从“待处理”移至“可用”。每当账户通过转账或存款收到机密代币时，余额都会出现在账户的“待处理”余额中，因此必须执行此操作。用户无法立即使用这些资金，需要应用待处理余额transfer（启用–confidential标志） - 将代币转入另一个已配置机密转账的账户。请注意，此操作可能比常规代币转账耗时更长，因为它需要执行多笔相互依赖的交易withdraw-confidential-tokens- 将代币从账户的机密余额提取到非机密余额。运行此命令提取所有预期代币前，请确保已应用所有待处理余额update-confidential-transfer-settings- 更新指定代币铸造的机密转账配置。它提供了自动设置机密转账审批策略（即–aprove-policy标志）以及设置审计者公钥（即–auditor-pubkey标志）的选项。它还提供其他标志，用于指定区块哈希、机密转账权限、配置文件、手续费支付方详情、JSON RPC URL、nonce 账户详情、输出格式和代币程序 ID
兼容性
请注意，以下扩展组合要么无法工作，要么不适合与机密转账结合使用：
- 机密转账 + 不可转让
- 机密转账 + 手续费（1.18 之前无法使用）
- 机密转账 + 转账钩子（因为这些转账只能看到源账户或目标账户，因此无法根据转账金额执行操作）
审计
机密转账以及更广泛的 Token-2022 Program 已接受多家公司的全面审计，包括 Halborn、Zellic、Trail of Bits、NCC Group 和 OtterSec（两次——第一次审计侧重于 Token-2022，第二次审计则专门侧重于机密转账）。
Poseidon 系统调用
Poseidon 是一个适合零知识证明的哈希函数族。大多数基于 ZK 的区块链项目都使用 Poseidon 哈希函数，包括 Zcash、Mina 和 Solana 的 Light Protocol。目前，在 Solana 上计算 Poseidon 哈希的成本太高，无法在一笔交易中完成。Poseidon 系统调用有望改变这一点。它们目前计划随 v1.17.5 发布，等待测试网激活。
通俗解释
想象一下，你正在使用一台高级计算器，它能高效解决安全通信中使用的特定类型谜题。这台计算器会接收多段信息，将其切分，再以独特方式混合。信息经过混合后，原始内容会被完全隐藏，但仍可验证。
这个混合过程使用一种特殊方法，对预先确定的特定数字集合中的数进行加法和指定幂次运算。该方法确保每次都能彻底且一致地完成混合。
Poseidon 的工作方式与这台高级计算器完全相同。这类哈希函数非常适合创建零知识电路。电路本质上是一组数学运算。它们以数学方式表示一方（证明者）向另一方（验证者）证明自己掌握某些信息，而不披露这些信息。一般来说，可以把它理解为：不开启密封盒子，也能证明你知道盒子里有什么。你可以通过一系列敲击或步骤，向封盒子的人证明这一点。这些敲击或步骤不会泄露盒内物品或开盒方式的任何细节，只有真正打开过盒子的人才能理解。
这对区块链很有帮助，因为在保持交易私密的同时验证其真实性至关重要。
适合 ZK 的特性
Poseidon 哈希函数被认为适合零知识证明，主要有以下几个原因：
- Poseidon 经过专门设计，可以高效执行零知识证明计算中常见的算术运算（即加法、乘法和幂运算）
- 零知识证明系统需要将计算逻辑转化为密码学证明。得益于适合算术运算的设计、优化的 S-box、可自定义参数以及较少的轮数（即以迭代方式对输入数据或哈希函数内部状态应用的一系列操作），Poseidon 的电路复杂度低于其他哈希函数。这意味着为给定数据生成证明所需的步骤更少
- Poseidon 哈希函数基于海绵结构。也就是说，Poseidon 采用一类算法进行设计，这些算法可以接收任意长度的比特序列，并生成任意长度的输出。因此，将 Poseidon 哈希函数集成到不同的零知识应用中非常容易。
与传统哈希函数的对比
与 SHA-256 等传统哈希函数执行的通用、高计算量操作相比，Poseidon 针对零知识证明优化的计算效率具有明显优势。
传统哈希函数虽然安全可靠，但往往会在零知识证明中产生规模更大、更加复杂的电路。这是因为这些哈希函数最初并非针对零知识证明系统的特定约束而设计。在区块链上，零知识证明的计算在有限域内进行。有限域是一组数字，其中所有算术运算（加、减、乘、除）都以一个质数为模进行。这会使数值在集合内“循环”，并确保每次运算都不会超出这组数字。
SHA-256 等传统哈希函数高度依赖位运算和预先确定的操作序列。这些功能与有限域中使用的算术运算并不直接兼容。在有限域环境中实现这些操作需要额外步骤，最终会增加电路复杂度。
此外，传统哈希函数通常使用以 2 的幂为基础的模算术。这不同于零知识证明所用有限域中的模算术，后者通常以质数为基础。这种不兼容性需要更多步骤，从而增加电路的规模和复杂度。
构建零知识证明的目标，是创建计算逻辑的数学表示，在不披露信息的情况下证明掌握了某些信息。高效、简洁地表示这些知识，对此类证明的可扩展性至关重要。Poseidon 哈希函数族通过在有限域内使用高效运算直接满足这些需求，显著减少创建电路所需的步骤，从而生成规模更小、复杂度更低的电路。传统哈希函数并非专门用于满足电路构建需求，而是为通用场景设计。
在 v1.17 中集成 Poseidon 系统调用，代表着 Solana 开始使用专用密码学工具来简化零知识证明的生成和验证。这能加快交易处理、降低成本，并增强零知识计算的可扩展性。结合 Poseidon 的灵活性和可自定义性，在 Solana 上生成和验证零知识证明变得容易得多。
具体实现
v1.17 引入了 sol_poseidon 系统调用。这是一个接收二维字节切片输入，并计算相应 Poseidon 哈希作为输出的系统调用。它使用 BN254 曲线，并采用以下 Poseidon 参数：
- x^5 S-box（即替换盒）
- 输入满足 1 ≤ n ≤ 12
- 宽度满足 2 ≤ t ≤ 13
- 8 个完整轮次，以及根据 t 确定的部分轮次：[56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]
这些 Poseidon 哈希将通过 light-posiedon crate 计算。该 crate 已通过审计，并与 Circom 兼容。
请注意，下一节将讨论新增 alt_bn128 系统调用。BN254 通常也称为 BN128（取自安全位数），还称为 alt_bn128 或 alt_bn_128。这里指的是同一条曲线。
alt_bn128 系统调用
v1.16 提议增强运行时对零知识计算的支持，尤其是 128 位椭圆曲线运算。高效生成证明所必需的 alt_bn128 系统调用原计划随 v1.16 发布，但最终被推迟。功能门激活计划目前安排 alt_bn128 系统调用随 v1.17.15 推出并等待主网 Beta 激活，alt_bn128 压缩则随 v1.17.15 推出并等待测试网激活。
顺带为更感兴趣的读者说明，alt_bn128 指 Barreto-Naehrig（BN-128）椭圆曲线的实现。它是一种支持高效 zk-SNARK（零知识简洁非交互式知识论证）的特定配对友好型椭圆曲线。它被视为“配对友好”，因为它能更高效地完成某些零知识计算和证明。在 Solana 中，alt_bn128 系统调用让程序能够利用这条曲线简化零知识证明验证，从而增强安全性和隐私。添加 alt_bn128 g1 和 g2 系统调用有助于实现 Groth16 证明压缩。这能显著减少每个证明所需的空间，为 Solana 程序高效优化空间使用。
引入 alt_bn128 系统调用，有助于缩小 Solana 与基于 Solidity 的合约之间的兼容性差距。后者依赖预编译合约执行 EIP-196、EIP-197 和 EIP-198 中规定的椭圆曲线运算。这些运算（bn256Add、bn256ScalarMult、bn256Pairing）可在 Ethereum 的 gas 限制内完成 zk-SNARK 验证。依赖这些椭圆曲线运算的 Solidity 合约现在可以更轻松地迁移到 Solana，甚至与其互操作。
Gossip 改进
v1.17 通过增强推送消息传播并减少对拉取请求的依赖，提高了 Gossip 消息的传播效率。精简 Gossip 协议的运行方式，有助于降低共识验证者的资源使用量。
作为背景，Solana 的 Gossip 服务对于验证者之间交换信息至关重要。这些信息包括账本高度、联系信息和共识投票等。它通过“推送”和“拉取”消息，在整个网络中共享并验证信息。这套消息系统可确保所有节点保持同步。
以往，AccountsHashVerifier 会将账户哈希推送到 Gossip。然而，没有任何网络组件会拉取这些数据，因此这一流程是多余的。随着 EpochAccountsHash 引入，将 Gossip 中的账户哈希与已知验证者的值进行比较等历史操作已被移除。getHealth RPC 方法也已重写，不再依赖 Gossip 中的账户哈希——下一节将对此进行深入介绍。因此，从 v1.17 开始，不再有任何组件从 Gossip 拉取账户哈希。AccountsHashVerifier 已修改，不再向 Gossip 推送账户，负责向 Gossip 推送和拉取账户哈希的函数也已移除。
getHealth
过去，getHealth RPC 调用可能会反映指定节点的错误状态。这是因为 solana catchup CLI 命令与 getHealth RPC 调用之间存在差异，导致一个节点可能同时显示已追上进度和落后。这可能造成健康节点被错误标记为不健康，并可能从 RPC 池中移除。
最初，系统通过将 Gossip 中发布的本地账户哈希 slot 与其他节点的值进行比较来判断健康状态，默认比较值为 100 个 slot。这可能不够精确，尤其对于配置值超过 100 个 slot 的节点。getHealth 已重写，改为使用集群最新的乐观确认 slot（即所有验证者均已处理、获得绝对多数确认，但尚未最终确认的最后一个 slot）。这种方式可以将集群已确认的 slot 与最新的乐观确认 bank 进行比较，以确定节点落后多少，因此比较结果更加准确。此次更改提供了更细粒度的检查，降低了假阴性（即将健康节点标记为不健康）的概率，并能隔离影响已知验证者的问题，防止产生多米诺效应。
此外，还为 wait-for-restart-window 和 exit 命令添加了 –skip-health-check 标志，以解决 getHealth 的问题。验证者可借此跳过节点健康检查。
QUIC
v1.17 新增了使用 QUIC 广播 shred 和执行修复的能力。Turbine 和修复 QUIC 端点目前处于禁用状态，因为在测试网完全迁移到 QUIC 之前还不需要它们。不过，这为将这些协议迁移到 QUIC 奠定了基础。多个引入底层功能的 PR 已合并，包括：
异步 TPU 连接
v1.17 引入了异步 TPU 客户端连接，显著改进了连接缓存机制。此次更新支持在后台建立连接，默认连接池大小为 4，旨在降低交易延迟。异步 TPU 客户端连接无需承受同步连接必需的等待时间，可确保交易处理更加顺畅。
简化验证者启动并更新快照格式
v1.17 通过引入新标志并更新支持的快照文件格式，简化了验证者启动流程。这能缩短验证者启动时间，而减少停机时间也有助于增强网络韧性，因此意义重大。
v1.17 引入了新的 –use-snapshot-archives-at-startup 标志。验证者可以在本地快照、磁盘上的本地状态之间进行选择，或自动选择两者中更新的一项，从而加快启动流程。当磁盘状态更新时，该标志无需处理快照，因此可以缩短重启时间。
此前，Solana 为快照支持多种压缩格式，包括 bz2、gzip、zstd、lz4、tar 和无压缩归档格式。然而，最新更新将选项缩减为 zstd 和 lz4，以提升效率并降低支持复杂度。–snapshot-archive-format 参数已弃用其他格式，但验证者仍可读取这些格式的现有快照，以确保向后兼容。这也从根本上简化了 solana-validator 和 solana-ledger-tool 的命令行界面。
结论
凭借众多新功能的实现和对近期网络中断的快速解决，Solana v1.17 更新实现了重大飞跃。随着 ZK Token Program、Poseidon 系统调用和 alt_bn128 系统调用发布，此次更新带来了前所未有的零知识支持与能力。加上验证者和网络效率方面的改进，这次更新为下一版本奠定了坚实基础。此次更新规模小于 v1.16，也符合每三个月发布一个新版本的目标。你可以在此处查看 1.18 的发布时间表。
如果你读到了这里，感谢你，匿名朋友！记得在下方输入邮箱地址，这样就不会错过 Solana 的任何新动态。准备进一步深入探索了吗？立即阅读 Helius 博客上的最新文章，继续你的 Solana 之旅。
其他资源
订阅 Helius
及时了解 Solana 开发的最新动态，并在我们发布新内容时收到更新