Agave 2.3 版本是 Solana 协议的又一个重要里程碑。主要亮点包括新的 TPU 客户端 (tpu-client-next) 的发布、通过 AccountsDB 优化显著减少了磁盘 I/O、增强的快照性能、对 Gossip 网络的改进以及更快的 epoch 转换和启动时间。这些更新共同使网络更加健壮,同时改善了开发人员和验证者运营商的体验。
Agave 验证器客户端的 v2.3 版本标志着 Solana 的又一次重大进展。与之前的更新一样,这个新版本引入了关键的改进,旨在提高网络性能和开发者体验。
本文的每个部分都是独立的,读者可以轻松地跳到与他们最相关的主题。无论你是验证器运营商、开发者还是参与用户,这份全面的 Agave 2.3 指南都应该为你提供充分利用最新改进所需的关键见解。
Anza 正在加速 Agave 版本的发布。在 2.2 版本发布不到三个月后,2.3 版本已经上线,目前总质押量的 13% 运行着新客户端的版本。预计未来几周采用率将迅速增长。与此同时,主网 Feature gate 激活 在推出期间已暂时暂停,并将很快作为计划激活序列的一部分恢复。
Agave 2.3 引入了 Transaction Processing Unit (TPU) 客户端的新实现,取代了之前的 ConnectionCache。此 TPU 客户端负责使用 QUIC 协议通过网络将序列化的交易发送给验证器。这个名为 tpu-client-next 的新设计是一次完整的重构,旨在显著提高性能,减少资源使用并简化整体架构。
TPU 客户端用于两种主要场景:在 ForwardingStage 中,验证器将交易转发给即将到来的领导者;在 SendTransactionService 中,RPC 使用它将交易转发给领导者。
之前的实现 ConnectionCache 旨在支持 UDP 和 QUIC 协议,这使其不必要地复杂。ConnectionCache 依赖于内部异步队列来存储交易,而不是显式通道,并且包括发送空数据包的缓存预热逻辑。它还存在与 Quinn(即 QUIC 的 Rust 实现)端点管理相关的持久性问题。
新的 tpu-client-next 通过简化的异步设计解决了这些问题。在内部,它遵循基于代理的模型,其中单个工作任务处理每个 QUIC 连接。这些工作者使用异步通道与中央 ConnectionWorkersScheduler 通信。
当调度程序收到一批交易时,会根据配置的策略将其广播到相应的工作者集合。该架构完全消除了多流,从而减少了流量碎片。连接也是预先建立的,这消除了在发送时打开新流的延迟。
tpu-client-next 展示了明显的性能提升。
tpu-client-next 是完全向后兼容的,现在是 Agave 节点的默认实现。如果出现问题,运营商可以使用 --use-connection-cache 标志启动其节点以恢复到之前的行为,从而恢复旧的实现。
总而言之,tpu-client-next 提供了:
作为 Agave 2.3 发布周期的一部分,Solana 将激活 SIMD-0180: 使用投票账户地址作为 Leader Schedule 的 Key。此更改会改变网络确定哪些验证器计划生成区块的方式,从使用验证器身份地址转移到使用投票账户地址作为 Leader Schedule 中的主键。
此迁移解决了 Solana 协议中长期存在的歧义:无法可靠地将生成区块的验证器与特定权益相关联。在当前设计下,Leader Schedule 由验证器身份地址键控。但是,多个投票账户可以委托给同一个验证器身份,从而难以将特定插槽的区块生产追溯到特定的一组委托权益。
通过改为将 Leader Schedule 键控到投票账户地址,此更改在委托权益和验证器的领导角色之间建立了清晰直接的联系。这个看似微小的修改解锁了几个重要的功能。
首先,它为区块奖励分配提供了必要的基础,如 SIMD-0123 中所述,该提案已在 3 月份通过了正式的治理投票。这使验证器可以设置区块费用的佣金率,并在委托者之间按比例分配剩余收入。此系统与已用于通货膨胀 Staking 奖励的奖励共享模型类似,从而更好地协调了验证器及其 Staker 之间的经济激励。
其次,使用投票账户地址作为 Leader Schedule 的键对于启用程序化惩罚至关重要,该机制会惩罚通过提交重复区块或在多个分支上投票来违反网络规则的验证器。这使我们很好地过渡到下一个更新。
惩罚是一种通过验证链上不当行为并燃烧其委托权益的一部分来惩罚恶意验证器的机制。它可以有效地阻止威胁网络安全或稳定性的行为。
有两种主要的惩罚模型:
社会惩罚(Solana 上的当前系统)
Solana 当前依赖于手动、社区驱动的共识方法,称为社会惩罚。在此模型下,如果验证器的行为具有恶意性,例如通过损害网络的活性或安全性,诚实的参与者可以离线协调以启动硬分叉,重新启动网络并惩罚违规者的权益。虽然此方法可以实现灵活的、个案判断,但它会带来大量的协调开销,并且本质上是被动的。
程序化惩罚(协议内惩罚)
相反,程序化惩罚完全在链上强制执行。如果验证器违反协议规则,则可以将违规的加密证明提交给专用程序,然后该程序会自动触发惩罚。此模型减少了对人工协调的依赖,并可以在不中断网络运营的情况下对较小的违规行为进行强制执行,从而为可扩展的、去中心化的问责制铺平了道路。
惩罚涉及两个关键步骤:
作为 Agave 2.3 发布周期的一部分,Solana 将激活 惩罚程序 的 Feature gate,如 SIMD 中所述:SIMD-0204: Slashable Event Verification。这标志着在 Solana 上启用程序化惩罚的第一步,重点是故障检测和归因。它引入了一个链上程序,允许任何人报告和记录可惩罚的行为,为未来的自动化执行奠定基础。
此程序不会改变权益或奖励;它仅验证和记录违规行为,作为验证器不当行为的链上记录。早期程序原型已 部署在 Testnet 上(例如,示例 DuplicateBlockProof 交易)。
该程序最初将专注于检测和记录重复区块生产,未来计划支持其他违规行为,例如双重投票。至关重要的是,程序化惩罚仅限于可以明确证明的不当行为。因此,对于更主观或系统性问题的执行,例如故意缓慢的区块生产或 MEV 提取,难度要大得多,并且不太可能通过惩罚程序来解决。
提交的证明包括同一插槽的两个冲突的 Shred,均由同一验证器签名。惩罚程序通过确保 Shred 形成有效的重复区块证明,确认它们属于同一插槽并且由违规验证器正确签名来验证该证明。此逻辑与 Solana 的 Gossip 协议中用于处理分叉选择过程中重复区块证明的方法类似。
一旦成功验证了证明,结果将存储在程序派生地址 (PDA) 中以供将来参考。这使得通过在惩罚程序上简单地运行 getProgramAccounts 可以轻松构建显示与惩罚相关的数据的仪表板。验证器可以使用它来检查他们是否已被报告违规行为,并根据需要采取纠正措施。
未来的 SIMD 将解决惩罚的经济执行问题,包括各种违规行为的权益惩罚等参数。由于这些决定会影响运行 Solana 验证器的经济性,因此任何拟议的变更都需要通过完整的治理投票获得批准。
Agave 2.3 引入了对 Epoch 转换速度 的重大改进。Epoch 奖励计算现在在 500 毫秒内完成。这导致跳过的槽更少,在 Epoch 边界附近更可靠的交易落地。
此外,如果跳过了新 Epoch 的第一个 Leader Slot,Agave 2.3 可确保不会重新运行奖励计算。相反,将重用先前计算的结果,从而消除冗余计算并实现更平滑的新 Epoch 启动。
此版本中存储效率得到了显著提高。磁盘 I/O 使用量减少了约 75%,修复请求量减少了约 85%。总而言之,这些优化带来了更一致和可靠的节点性能,尤其是在网络负载较高期间。
在 Agave 2.3 中,现在默认启用 Greedy Scheduler。由于对交易进行排序和构建依赖关系图所需的时间,以前的中央调度程序通常在繁重的网络负载下成为瓶颈。更新的 Greedy 方法通过简化的逻辑和更小的批大小显著加快了交易调度。
读者可以在我们 之前的 Helius 博客文章 中了解有关 Greedy Scheduler 的更多信息。
Agave 2.3 引入了 Gossip 网络中更严格的 Shred 版本匹配强制执行。现在仅允许节点在其 Shred 版本与集群的 Shred 版本匹配时建立入站 Gossip 连接,从而有助于尽早拒绝配置错误的节点。
以前,间谍节点可以在不匹配集群的 Shred 版本的情况下加入网络。通过此更改,所有节点(包括间谍模式的节点)都必须从集群入口点获取正确的 Shred 版本,或者通过命令行显式设置它。
此更新建立在近期减少 Gossip 开销的努力之上。由于弃用了三种 Gossip 消息类型以及从未 Staking 的验证器中删除了 Epoch Slot 广告,最近几个月,入口 Gossip 流量减少了约 61%。
为了提高交易资源使用情况的可见性,已将一个新字段添加到默认的 `simulateTransaction` RPC 方法:`loadedAccountsDataSize`。此字段报告模拟期间加载的账户数据的总字节数。
此添加使开发人员可以更准确地估算交易成本并微调优先级费用。加载账户数据会消耗计算单元 (CU),速率为每 32 KB 8 个 CU,这是基于 Solana 的堆页面分配大小。通过显示此指标,开发人员可以在构建和发送交易时更好地优化成本效率。
快照充当定期保存点,允许节点恢复其状态。节点不断生成这些快照,并随着时间的推移用新版本替换旧版本。
此版本对快照行为引入了多项质量方面的改进:
延长快照间隔的一个额外好处是 更平滑的磁盘性能,减少了 IOPS 峰值(每秒输入/输出操作)。
Agave 2.3 为使用 SBPF 工具链的开发人员引入了多项质量方面的升级:
此版本中包含的其他更新:
Agave 2.3 标志着 Solana 协议的又一个关键里程碑。主要亮点包括启动新的 TPU 客户端 (`tpu-client-next`)、通过优化 AccountsDB 显著减少磁盘 I/O、增强快照性能、改进 Gossip 网络以及更快的 Epoch 转换和启动时间。总而言之,这些更新使网络更强大,同时改善了开发人员和验证器运营商的体验。
Solana 继续朝着强大的多客户端网络稳步前进,超过 8% 的总权益在运行 Firedancer 并且还在攀升。近一年半的不间断运行时间反映了网络核心软件日益成熟和稳定。与此同时,主要版本和次要版本的发布速度都在加快。
接下来:Agave 3.0!
- 原文链接: helius.dev/blog/agave-v2...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!