关于 Solana v1.18 更新的所有信息
- AI 翻译官
- 更新于 2024-06-26 14:43
- 阅读 825
Solana 1.18 更新：引入了一个中央调度器。这个新调度器旨在简化交易处理并确保更准确和高效的优先级计算。
非常感谢 Rex St. John 和 Mike MacCana 审阅这篇文章。
介绍
超多数采用的 Solana 1.18 更新的是一个重要的里程碑。它带来了许多旨在提高网络性能、可靠性和效率的改进和新功能。其中最显著的变化之一是引入了一个中央调度器。这个新调度器旨在简化交易处理并确保更准确和高效的优先级计算。其他对运行环境和程序部署的改进，例如，帮助在网络负载高峰期提供更可靠的性能。
本文探讨了 1.18 版本带来的更新和改进。我们将探讨这些变化背后的动机、这些新功能的具体细节及其对改善网络的预期影响。无论你是验证器操作员、开发人员还是普通的 Solana 用户，这篇 1.18 更新的全面概述将为你提供必要的信息，以理解和利用这些新改进的好处。
我们首先必须讨论 Anza，这是一家新成立的开发公司，推动了这些变化，并在 Solana 的持续发展中扮演了重要角色。
什么是 Anza？
Anza 是一家由前 Solana Labs 高管和核心工程师创建的新成立的软件开发公司。它的成立代表了一项加强 Solana 生态系统的战略举措，旨在提高其可靠性、去中心化和网络强度。Anza 的成立是为了通过开发关键基础设施、贡献关键协议和促进新工具的创新来增强 Solana 的生态系统。
创始团队包括 Jeff Washington、Stephen Akridge、Jed Halfon、Amber Christiansen、Pankaj Garg、Jon Cinque 以及几位来自 Solana Labs 的核心工程师。
Anza 专注于开发和改进 Solana 的验证器客户端，并创建了 Agave ——一个 Solana Labs 验证器客户端 的分支。Anza 的雄心不仅限于开发他们的验证器客户端，还致力于整个生态系统的改进。这包括开发 Token Extensions 和一个定制的 Rust / Clang 工具链。通过促进协作和开放的开发方法，Anza 致力于加速和改进 Solana 生态系统。
什么是 Agave？
如前一节简要提到的，Agave 是由 Anza 主导的 Solana Labs 验证器客户端的一个分支。在这种情况下，“分支”一词指的是 Anza 的开发团队从 Solana Labs 的代码库中获取现有代码，并开始一条与原始代码库分开的新开发路径。这使得 Anza 能够在 Solana Labs 客户端上实现自己的改进、功能和优化。
迁移过程
客户端向 Anza 的 GitHub 组织的迁移 从 3 月 1 日开始。最初，Agave 将镜像 Solana Labs 的代码库，以便社区有时间进行调整。在此期间，Anza 将负责关闭拉取请求（PR）并将相关问题迁移到 Agave 的代码库。Agave 和 Solana Labs 客户端 1.17 和 1.18 版本在功能上将是相同的。Anza 计划在今年夏天发布 Agave v2.0，其中包括归档 Solana Labs 客户端并建议 100%的网络迁移到新的 Agave 客户端。
Solana Labs 到 Agave 的 迁移过程在他们的 GitHub 上公开跟踪。
Agave 运行时
Agave 运行时继承了 Solana 虚拟机（SVM） 的基础架构，是执行 Sealevel 运行时 定义的核心功能的支柱。
Solana 协议将运行时定义为处理交易和更新账户数据库状态的关键组件。这个规范已被 Agave 和 Firedancer 客户端采用并进一步改进。SVM 的本质在于其能够并行执行所有 Solana 程序并修改账户状态。
银行的概念是处理交易和理解 1.18 中变化的关键。一个 银行 既是一个逻辑片段，也是一个特定时间点 账本 状态的表示。它充当一个复杂的控制器，管理账户数据库，监督跟踪客户端账户，管理程序执行，并维护 Solana 账本的完整性和进展。银行封装了包含在给定区块中的交易所产生的状态，作为该时间点账本的快照。
每个银行都配备了执行交易所需的缓存和引用，允许它们从先前的快照或创世区块初始化。在 银行阶段 中，验证器处理交易，银行用于组装区块并随后验证其完整性。这个生命周期包括加载账户、处理交易、冻结银行以最终确定状态，并最终使其成为根状态，确保其永久性。
作为一般概述，Agave 运行时内的交易处理引擎负责加载、编译和执行程序。它使用 即时编译（JIT），缓存已编译的程序以优化执行效率并减少不必要的重新编译。程序在部署前被编译为 eBPF 格式。运行时然后使用 rBPF 工具包 创建一个 eBPF 虚拟机，该虚拟机从 eBPF 到 x86_64 机器代码指令进行 JIT 编译，充分利用可用硬件。这确保了程序的高效执行。
1.18 更新引入了一个中央交易调度器，这与 Agave 运行时引入的操作效率密切相关。通过改进交易的编译、执行和通过银行管理的方式，1.18 更新实现了更简化和高效的调度过程。这反过来导致了更快的交易处理时间和增强的吞吐量。新的 Agave 运行时及其客户端是这些改进的基础，因此在深入了解新调度器的复杂性之前，我们必须对其有一个大致的了解。
如果你想了解更多关于 Agave 运行时的信息，我推荐阅读 Joe Caulfield 的 文章。它详细介绍了相关内容，并提供了有用的代码片段。
更高效的交易调度器
当前实现
来源: 改编自 Andrew Fitzgerald 的文章 Solana Banking Stage and Scheduler
在交易处理流水线中，交易包首先通过数据包入口进入系统。这些数据包在 SigVerify 阶段 进行签名验证。此步骤确保每笔交易都是有效的，并由发送方授权。
.jpg)
签名验证后，交易被发送到银行阶段。银行阶段有六个线程——两个专门处理来自 交易处理单元 (TPU) 或 Gossip 的投票交易，四个专注于非投票交易。每个线程是独立的，并从共享通道接收数据包。也就是说，SigVerify 会以数据包批次发送数据包，每个线程将从共享通道中提取交易并将其存储在本地缓冲区中。
本地缓冲区接收交易，确定其优先级，并相应地排序。此队列是动态的，不断更新以反映交易状态和网络需求的实时变化。随着交易被添加到队列中，它们的顺序会重新评估，以确保优先级最高的交易首先准备好处理。
这个过程是连续进行的，这些交易包的处理取决于验证者在 领导者计划 中的位置。如果验证者在近期内没有被安排为 领导者，他们将把数据包转发给即将成为领导者的节点并丢弃它们。当验证者接近其预定的领导者 slot （约 20 个 slot ），它将继续转发数据包但不再丢弃它们。这是为了确保这些数据包可以包含在他们自己的区块中，如果其他领导者没有处理它们。当验证者距离成为领导者还有 2 个 slot 时，它开始持有数据包——接受它们但不做任何处理，以便在验证者成为领导者时处理它们。
在区块生产期间，每个线程从其本地队列中取出前 128 笔交易，尝试获取锁，然后检查、加载、执行、记录和提交交易。如果锁获取失败，交易将稍后重试。让我们详细说明每个步骤：
- 锁定: 此步骤检查线程可以获取哪些交易的锁。每笔交易将读取和写入一些账户，因此验证者需要确保没有冲突
- 检查: 此步骤检查交易是否过旧或已处理。请注意，银行有一个状态缓存，跟踪最近 150-300 个 slot 的交易
- 加载: 此步骤加载执行给定交易所需的账户。此步骤还检查费用支付者是否确实能够支付费用，以及调用的程序是否为有效程序。基本上，此步骤加载账户并进行一些初步设置
- 执行: 此步骤执行每笔交易
- 记录: 执行交易的结果被发送到历史证明服务进行哈希处理 。这是交易签名被发送出去的地方
- 提交: 如果记录步骤成功，交易将被提交。此步骤还将更改传播回账户系统，以便未来在此或后续 slot 的交易将具有每个账户的更新视图
- 解锁: 第一步中为每个账户放置的锁被解除
银行阶段使用多迭代器方法来创建这些交易批次。多迭代器是一种编程模式，允许在多个序列中同时遍历数据集。可以将其视为有几个读者在阅读同一本书，每个读者从不同的章节开始，协调以确保他们不会同时阅读同一页，如果他们对内容的理解可能会相互干扰。在银行阶段，这些“读者”是迭代器，而“书”是等待处理的交易集合。多迭代器的目标是高效地筛选交易，将它们分组成可以在没有任何锁冲突的情况下处理的批次。
最初，交易根据优先级序列化为一个向量。这为多迭代器提供了一个结构化的序列，以将这些交易分段为无冲突的批次。多迭代器从序列化向量的开始处开始，在交易不冲突的地方放置迭代器。这样，它创建了 128 笔交易的批次，没有任何读写或写写冲突。如果某笔交易与当前形成的批次冲突，它将被跳过并保持未标记状态，允许其包含在后续批次中，在那里冲突不再存在。随着交易的继续处理，这个迭代过程会动态调整。
成功形成批次后，交易将被执行，如果成功，它们将被记录在历史证明服务中并广播到网络。
当前实现的问题
当前实现有几个方面可能会影响性能，导致交易处理中的潜在瓶颈和不一致的优先级。这些挑战主要源于银行阶段的架构和系统内交易处理的性质。
一个基本问题是，处理非投票交易的四个独立线程在各自的线程中有各自的交易优先级视图。这种差异可能导致交易排序中的抖动或不一致。当所有高优先级交易发生冲突时，这些差异会更加明显。由于数据包基本上是由每个线程从 SigVerify 的共享通道中随机提取的，每个线程将拥有所有交易的随机集合。在竞争性事件中，例如流行的 NFT 铸造，许多高优先级交易可能会出现在多个银行阶段线程中。这是有问题的，因为它可能导致线程间的锁定冲突。这些线程在处理这些高优先级交易时，可能会相互竞争，导致由于锁定尝试失败而浪费处理时间。
将银行阶段想象成一个管弦乐队，每个线程是一个不同的部分——弦乐、铜管、木管和打击乐。理想情况下，指挥会协调这些部分以确保和谐的演出。然而，当前的系统更像是一个没有指挥的乐队在尝试演奏一首复杂的曲子。每个部分都在演奏自己的曲调，经常互相冲突。高优先级的交易是所有部分试图同时演奏的独奏部分，导致混乱。这种缺乏协调的情况突显了需要一个集中“指挥”来确保 Solana 交易处理的效率和和谐，就像指挥领导乐队一样。
新的交易调度器
1.18 更新引入了一个中央调度线程，取代了之前的四个独立银行线程模型，每个线程管理自己的交易优先级和处理。在这个修订的结构中，中央调度器是 SigVerify 阶段交易的唯一接收者。它构建了一个优先级队列，并部署了一个依赖图来管理交易优先级和处理。
这是一个交易依赖图。箭头表示“依赖于”。例如，交易 A 依赖于交易 B，而交易 B 依赖于交易 C 和交易 D
这个依赖图被称为 prio-graph。它是一个有向无环图 ，在添加新交易时懒惰评估 。交易被插入图中以创建执行链，然后按时间优先级顺序弹出。当处理冲突交易时，首先插入的交易总是具有更高的优先级。在上面的例子中，我们有交易 A 到 H。注意，交易 A 和 E 在各自的链中具有最高优先级且不冲突。调度器从左到右移动，按批次处理交易：
交易 A 和 E 作为第一批处理；然后是 B 和 F；然后是 C、D、G 和 H 作为最后一批处理。如你所见，最高优先级的交易位于图的顶部（即最左边）。当调度器按降序检查交易时，它会识别冲突。如果一个交易与优先级更高的交易冲突，则在图中创建一条边以表示这种依赖关系（例如，C 和 D 与 B 冲突）。
新的调度器模型解决了多迭代器方法固有的几个关键问题：
- 优先级处理的一致性：新系统通过集中交易接收和调度，确保所有交易按一致的优先级顺序处理。这消除了之前由于多个线程对交易优先级的不同看法而导致的抖动
- 减少处理延迟：prio-graph 确保准备执行的批次高度可能在没有锁冲突的情况下成功，简化了处理时间和任何由于锁争用引起的延迟。注意使用“高度可能成功”这一短语——这并不完全正确，因为 prio-graph 创建的批次可能会与投票线程冲突，尽管这是一个非常罕见的边缘情况
- 可扩展性和灵活性：这种新的调度器设计允许增加线程数量，而不会有之前增加锁冲突的担忧。这要归功于锁的集中视图和更受控的交易分配给工作线程
1.18 中引入的中央调度器预计将显著改善交易处理，减少与之前系统相关的复杂性和开销。这可能会导致更快的交易处理时间、增加的吞吐量和更稳定的网络。由于 1.18 发布的延迟，调度器自其诞生以来有所改进。例如， 交易的预编译验证已移至工作线程以提高效率 。此外，CU 限制现在更加合理，估计/实际比率比旧调度器低得多。 新的调度器现在可以使用 CU 来限制调度的工作队列，防止由于账户冲突而导致的过度工作排队 。
注意， 中央调度器默认未启用，必须在启动验证器时使用新的 --block-production-method central-scheduler标志启用 。目前是选择性加入，但将在未来版本中成为默认调度器。还要注意，可以使用--block-production-method thread-local-multi-iterator标志启用旧调度器（这是默认启用的，但请不要在未来版本中这样做——中央调度器更高效并解决了旧调度器的问题）。
更有效的优先级计算
1.18 还改进了交易优先级的确定方式，使过程在资源使用和成本回收方面更加公平和高效。以前，交易优先级主要基于计算预算优先级，有时会导致计算单元定价不佳。这是因为优先级没有充分考虑收取的基本费用，导致资源可能被低估，影响网络的运营效率。
新方法调整了交易优先级计算，考虑了交易费用和相关成本，使用公式Priority = Fees / (Cost + 1)。这里，费用代表与给定交易相关的交易费用，而成本代表由 Solana 成本模型确定的计算和资源消耗。分母中添加“1”是为了防止除以零。
我们可以进一步分解公式，使费用和成本更加明确：
现在，交易的成本是全面计算的，考虑了所有相关的计算和运营成本。这确保了优先级计算反映了交易的真实资源消耗。这意味着如果开发者和用户请求较少的计算单元，他们将获得更高的优先级。这也意味着没有任何优先费用的简单转账将在队列中具有一定的优先级。
改进的程序部署
新更新解决了一个问题，即在一个 epoch 的最后一个 slot 中部署的程序没有正确应用计划用于下一个 epoch 的运行时环境更改。因此，在此过渡期间部署的程序会错误地使用旧的运行时环境。1.18 调整了部署过程，以确保在 epoch 结束时部署的任何程序的运行时环境与即将到来的 epoch 的环境一致。1.18 还解决了无法在部署交易中设置计算单元价格或限制的问题， 通过向 CLI 程序部署命令添加 --with-compute-unit-price 标志 。此标志可与 solana program deploy 和 solana program write-buffer 命令一起使用。计算单元限制是通过模拟每种类型的部署交易并将其设置为消耗的计算单元数量来设置的。
另一个重要的改进涉及如何处理大型程序部署的区块哈希。在 1.18 之前，使用 sign_all_messages_and_send 发送的交易被限制为 100 TPS。对于较大的程序，部署交易的数量将达到数千。这意味着交易可能会被延迟，并且由于许多交易会延迟超过 10 秒，因此存在使用过期区块哈希的风险。1.18 延迟了使用最近的区块哈希签署部署交易，直到节流延迟之后。区块哈希现在每 5 秒刷新一次，因此超过 500 笔交易的部署将受益于使用更新的区块哈希。
此外，1.18 引入了改进网络处理程序部署和验证交易的方式 。以前，由于识别账户状态的错误，一些程序被错误地标记为 FailedVerification。这可能会错误地标记实际上没有失败任何检查的程序。这些程序现在如果不应该处于活动状态，则被正确地标识为 Closed。此更改确保只有有问题的程序被标记为重新检查，并有助于防止不必要的重新验证。
更新程序状态的过程也得到了改进。程序现在可以在部署的同一时间段内从 Closed 状态过渡到活动状态。这意味着程序变得更快更可靠地运行，这在高需求时期至关重要。这些调整有助于更有效地管理网络负载，防止可能减慢交易处理速度的拥堵。
“拥堵补丁”——更好地处理拥堵
测试网版本 1.18.11，被誉为“拥堵补丁，”提出了应对 Solana 最近拥堵的变化。请注意，此版本并不特定于 1.18，并且已回移到 1.17.31。无论如何，我们必须谈论它。
最大的变化是 QUIC 现在在 Stake-Weighted Quality of Service (SWQoS) 中将超级低质押节点视为未质押节点 。这是为了应对质押量非常小的节点可以滥用系统以获得不成比例的带宽的事实。此外，当前的指标无法区分从质押节点和非质押节点发送和节流的包的比例。因此， 添加了这些指标以提高可见性。 如何处理包块也得到了优化 ，通过用 smallvec 替换 vec 实例来节省每个包的分配。这是可能的，因为流是包大小的，所以预期的数量很少。
在银行阶段，以前所有包都被转发到下一个节点。然而，1.18 改变了这一点，使得 只有来自质押节点的包被转发。此更新有效地使质押连接比以往任何时候都更重要，因为它们在计算优先级和转发交易时占据更大的权重。
改进的文档
1.18 更新还显著改进了官方 Solana 文档的翻译支持 ，以确保全球受众更容易访问。更新包括升级 Crowdin CLI 和配置（简化了跨语言文档的同步），并引入了新的 serve 命令，以便通过 Docusaurus 更好地进行本地测试。文档还改进了静态内容的处理方式，通过将 PDF 文件直接链接到 GitHub blobs 以避免翻译构建中的相对路径问题。
对于开发人员，贡献翻译的过程通过更新的 README 进行了澄清，处理了常见问题，如必要的环境变量和典型的构建错误。这得到了持续集成流程改进的补充，现在仅在稳定频道构建中包含翻译。这确保了只有经过验证和稳定的文档才能到达最终用户。这些更改旨在简化贡献，提升官方文档的质量，并为所有用户提供可靠和准确的信息。
结论
由 Anza 推动的 1.18 更新大大改进了交易处理、优先级计算、程序部署、官方文档和整体网络性能。通过引入中央调度器和各种旨在解决最近拥堵问题的修复，Solana 更好地应对高峰负载，并确保高效和可靠的网络行为。Solana 是可扩展区块链的最佳机会，此更新肯定了其潜力。
如果你读到这里，谢谢你，匿名者！请务必在下面输入你的电子邮件地址，这样你就不会错过有关 Solana 最新动态的任何更新。准备好深入了解了吗？探索 Helius 博客 上的最新文章，继续你的 Solana 之旅，今天就开始。
