关于Solana v1.17更新的所有信息
- Helius
- 发布于 2024-06-03 11:11
- 阅读 18
文章详细介绍了Solana v1.17更新的内容，包括零知识证明的引入、Gossip协议的改进、系统调用的优化等，旨在提升网络效率、安全性和可扩展性。
17分钟阅读
2024年6月1日
这篇文章是关于什么的？
Solana网络达到了一个成功的里程碑，1.17版——Solana Labs验证者客户端的最新版本，已被超级多数接纳。在最近的网络宕机后，验证者们使用版本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还部署了一些运行v1.17的mainnet-beta预警节点，以监控该版本在真实环境下的稳定性。这些节点在过去几个月内保持稳定。过去的活动和进展可以通过访问Solana Tech Discord中的#canaries-monitoring频道查看。此外，从2023年12月4日开始，一小部分志愿者操作的mainnet-beta节点升级到了v1.17。
开发了多个运行时模糊测试工具，以执行部分随机交易，以捕捉边缘案例或不常见的竞态条件。这些交易在多个版本间执行，以确保性能一致。v1.17已经多次接受外部审计，审计结果将随着可用性的提升发布到Solana Security Audits GitHub存储库。
二月宕机
在2024年2月6日UTC时间9:53，mainnet-beta经历了一次停机，暂时中断了区块的最终确认。这次中断持续了大约五个小时，直到UTC时间14:55时恢复共识。这次宕机的原因可以追溯到一个与网络如何编译和缓存程序代码执行相关的错误，具体影响了旧版本的程序加载器。
根本原因源于验证者如何处理即时编译(JIT)的输出，尤其是针对经常使用的程序。新的缓存系统旨在优化这一过程，不慎引入了致命的bug。这个新系统可能会让某些遗留程序进入无限重新编译循环。这使得Solana的共识机制停滞不前，因为大多数验证者遇到了这个问题，无法继续处理交易。
这一根本原因被迅速确定，因为该bug与最近的开发网络宕机有相似之处。1.17.20已经修改以直接解决这个问题，验证者协调网络重新启动。修复方法分为两部分：短期解决方案是通过弃用可能触发无限循环的两个遗留加载器来禁用触发机制，更全面的调整是修改新的程序缓存系统，以防止将来发生类似问题。
ZK代币证明程序
ZK Token Proof Program本计划与1.16更新一起发布。然而，其激活因广泛审计而推迟。根据Feature Gate Activation Schedule，该程序标记为待测试网激活，底线为1.17.12。
保密转账
随着ZK Token Proof Program的激活，保密转账终于得以实现。保密转账使用零知识证明来加密SPL代币的余额和转账金额。整体目标是保密性而非匿名性。同态加密允许对加密数据进行计算，而无需解密。例如，可以在不解密和重新加密操作中指定的金额的情况下对余额进行相加或相减。因此，这些计算的加密方式和采用明文时是相同的。
保密转账使用扭曲的ElGamal加密和Σ协议进行安全私密交易，而无需泄露敏感信息。
顺便提一下：
- 扭曲的ElGamal加密是标准ElGamal加密方案的一个简单变体，其中一个密文被分为Pedersen承诺的加密消息和解密处理Handle，以实现密码得以执行隐藏的数学操作
- Σ协议用于验证保密转账。它们是一类特殊的零知识证明，其中一方（即证明者）可以向另一方（即验证者）证明它知道某个信息，而无须公开该信息
保密转账仅允许持有解密密钥的账户查看其加密余额。为需要第三方审查的情况（例如合规检查或审计）实现了全球审计系统。该系统允许账户持有人通过单独的解密密钥授予对特定帐户的选择性读取访问，并包括“审计员加密密钥”以便于安全审计。
交易使用加密参数代表发送者、接收者和审计员的金额，以及确保隐私和完整性的证明。账户余额被切分为“待处理”和“可用”，以防止前置攻击。否则，恶意用户可能会向某个账户发送代币，以使生成的证明失效。
需注意的是，保密转账需要使用新密钥对。
命令行支持
通过spl-token库，保密转账的命令行界面(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、随机账户详细信息、输出格式和代币程序ID的附加标志
兼容性
请注意以下扩展组合要么不适用，要么与保密转账组合不合理：
- 保密转账 + 不可转让
- 保密转账 + 费用（在1.18之前不适用）
- 保密转账 + 转账钩子（因为这些转账只能看到源账户或目标账户，因此无法针对转账金额进行操作）
审计
保密转账和更一般的Token-2022程序，已被Halborn、Zellic、Trail of Bits、NCC Group及两次由OtterSec审计（第一次审计专注于Token-2022，而第二次审计则专注于保密转账）。
Poseidon系统调用
Poseidon是一系列对零知识证明友好的哈希函数。Poseidon哈希函数被大多数基于零知识的区块链项目使用，包括Zcash、Mina和Solana的Light Protocol。目前，在Solana上计算Poseidon哈希在一次交易中成本过高。Poseidon系统调用即将改变这一状况。目前，预计与版本1.17.5待测试网激活一起发布。
外行的解释
想象一下使用一种先进的计算器，这种计算器能够有效地解决用于安全通信的特定类型的难题。这种计算器的工作原理是接收机器信息，将其切成碎片，并以独特的方式混合在一起。该信息混合得非常巧妙，以至于原始内容完全被隐藏，但仍然可验证。
这种混合过程使用了一种特殊的方法，可以对信息进行加法和提升到特定指数，这些数值属于提前确定的特定数值集合。这种方法确保每次混合的同时，也确保充分且一致。
Poseidon正好和这台高级计算器做的事情是一样的。这些类型的哈希函数在创建零知识电路方面非常擅长。电路本质上是一系列数学运算。它们从数学上表示一方（证明者）向另一方（验证者）证明他们知道某个信息而不泄露信息的过程。一般来说，可以将其理解为，在不实际打开的情况下，证明你知道密封盒子里有什么。你可以通过一系列的“打击”或步骤向给你密封盒子的人证明这一点。这些步骤旨在在不透露盒子里有什么或如何打开盒子的详细信息的情况下进行，只有当你打开它时才能理解。
这对于区块链而言非常重要，因为在能够验证真实性的同时确保交易私密是件大事。
ZK友好特征
Poseidon哈希函数因以下几个原因被认为是对零知识友好的。
- Poseidon被设计为有效进行零知识证明计算中常见的算术操作（即加法、乘法和指数运算）
- 零知识证明系统需要将计算逻辑转化为密码证明。Poseidon的设计导致其电路复杂性低于其他哈希函数，因为它的算术友好设计、优化的S-box、可定制参数以及较少的轮次（即施加于输入数据或哈希函数内部状态的操作序列，过程是迭代性的）。这意味着生成给定数据的证明所需的步骤更少
- Poseidon哈希函数基于海绵结构。即，在设计时使用了一类算法，该算法可以接受任意长度的比特序列并产生任何长度的输出。这使得将Poseidon哈希函数集成到不同的零知识应用中变得极为容易。
与传统哈希函数的比较
Poseidon的计算效率专门针对零知识证明，提供了与传统哈希函数（如SHA-256）相比的显著优势，后者执行的是更通用、计算密集的操作。
虽然传统哈希函数安全可靠，但通常会导致零知识证明中的电路更大、更加复杂。这是因为这些哈希函数并未以零知识证明系统的特定约束为设计初衷。在区块链中，零知识证明在有限域内进行计算。一个有限域是一组数，所有算术运算（加、减、乘和除）都以某个质数为模进行。这导致它们在集合内“环绕”，确保每个操作都保持在这组数内。
传统的哈希函数例如SHA-256，强烈依赖于按位操作和预定的操作序列。这些功能与有限域中使用的算术操作不直接兼容。在有限域中实施这些操作将需要额外的步骤，从而导致电路复杂性增加。
此外，传统哈希函数通常使用模运算基于2的幂。这与零知识证明中使用的有限域的模运算不同，后者通常以质数为基础。这种不兼容性将需要更多步骤，从而增加电路的大小和复杂性。
构建零知识证明的目标是创建计算逻辑的数学表示，该表示证明对某些信息的知识而不透露这些信息的内容。以高效、简洁的方式呈现这种知识对这些证明的可扩展性至关重要。Poseidon系列哈希函数直接满足这些需求，利用有限域中的有效操作，显著减少所需电路创建步骤。这导致较小、较少复杂的电路。传统哈希函数并不是专门针对直接构建电路所需的，它们旨在实现通用功能。
在v1.17中集成Poseidon系统调用代表了一个转变，旨在利用专门的密码工具，为在Solana上生成和验证零知识证明提供简化方案。这将导致更快的交易处理、降低成本以及增强零知识计算的可扩展性。结合Poseidon的灵活性和可定制性，在Solana上生成和验证零知识证明变得异常容易。
具体实现
v1.17引入了sol_poseidon系统调用——一个系统调用，接受2D字节切片输入，并计算相应的Poseidon哈希作为输出。它采用了BN254曲线，并接受以下Poseidon参数：
- x^5 S-boxes（即替换箱）
- 输入数量1 ≤ n ≤ 12
- 宽度2 ≤ t ≤ 13
- 8个完整轮次和根据t进行的部分轮次：[56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]
计算这些Poseidon哈希将通过light-posiedon crate完成，该库是经过审计的，并与Circom兼容。
请注意，在以下部分中，我们讨论了alt_bn128系统调用的新增。在日常用语中，BN254被俗称为BN128（以指代其安全位数），而alt_bn128或alt_bn_128指的正是同一条曲线。
alt_bn128系统调用
v1.16提议增强零知识计算的运行时支持，特别是128位椭圆曲线操作。alt_bn128系统调用对高效生成证明至关重要，本应与v1.16一起发布，然而有所延迟。Feature Gate Activation Schedule目前将alt_bn128系统调用定于v1.17.15待mainnet-beta激活，alt_bn128压缩定于v1.17.15待测试网激活。
顺便提一下，alt_bn128指的是Barreto-Naehrig（BN-128）椭圆曲线的实现。这是一条特定配对友好的椭圆曲线，允许高效的zk-SNARKs（零知识简洁非交互知识论证）。它被认为是“配对友好的”，因为它使得某些零知识计算和证明可以更高效地进行。在Solana中，alt_bn128系统调用使程序能够利用这条曲线，以简化零知识证明验证，增强安全性和隐私。添加alt_bn128g1和g2系统调用有助于促进Groth16证明的压缩。这大幅减少每个证明所需的空间，优化Solana程序的空间利用。
引入alt_bn128系统调用有助于缩小Solana与依赖于预编译合约进行椭圆曲线操作的Solidity合约之间的兼容性差距，后者在EIP-196、EIP-197和EIP-198中进行了规定。这些操作（bn256Add、bn256ScalarMult、bn256Pairing）旨在在以太坊的gas限制内促进zk-SNARK的验证。依赖这些椭圆曲线操作的Solidity合约现在更容易过渡到Solana，甚至实现互操作。
Gossip改进
v1.17改进了Gossip消息传播的效率，通过增强推送消息传播并减少对拉取请求的依赖，使之更加高效。简化gossip协议的操作有助于减少共识验证者的资源使用。
为了说明，Solana的Gossip服务对验证者之间的信息交换至关重要，包括分类账高度、联系信息和共识投票等信息。它使用“推送”和“拉取”消息在网络中共享和验证信息。这个消息系统确保所有节点保持同步。
传统上，AccountsHashVerifier会将其账户哈希推送到gossip中。然而，网络组件从未拉取过这些数据，使这个过程变得多余。引入EpochAccountsHash后，比较gossip中的账户哈希与已知验证者的值等历史操作被移除。与此同时，getHealth RPC方法 也被重写，不再依赖于gossip中的账户哈希——我们将在下一部分深入探讨。因此，从v1.17开始，没有任何内容从gossip中拉取账户哈希。AccountsHashVerifier被修改为停止将账户推送到gossip，并且负责任推送和拉取账户哈希的函数也被移除。
getHealth
在过去，getHealth RPC调用可能会反映给定节点的错误状态。这是由于solana catchup CLI命令与getHealth RPC调用之间存在差异，导致一个节点同时看起来已更新且滞后。这可能导致健康节点被错误标记为不健康，从而潜在地从RPC池中移除。
健康检查最初是通过比较在gossip中发布的本地账户哈希槽与其他节点的账户哈希来确定的，默认比较值为100个槽。对于配置为超过100个槽的节点而言，这可能不够精确。getHealth被重写为使用来自集群的最新乐观确认槽(即所有验证者都已处理和确认的最后一个槽，经过超级多数，但尚未最终确定)。这提供了一种更精确的比较，而集群确认的槽可以与最新的乐观确认银行相比较，以确定节点的滞后程度。这项变化提供了更细致的检查，减少了误报（即标记为不健康的健康节点）的可能性，并使节点免受影响已知验证者的任何问题导致的连锁反应。
–skip-health-check标志也被添加到wait-for-restart-window和exit命令，以解决与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.dev/blog/all-you-...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
