SLV 完成 Solana v4 支持，带来 XDP 与面向 Alpenglow 的 BLS

ELSOUL LABO B.V.（总部：荷兰阿姆斯特丹；CEO：川崎文武）与 Validators DAO 在此宣布，开源 Solana 运维工具 SLV 已完成对 Solana v4（Agave 4.x）的支持。

通过本次更新，性能最高的 Solana 验证者所依赖的优化 — Anza 的 XDP Turbine 再传输加速，以及 SIMD-0387 中定义的面向 Alpenglow 的 BLS 公钥注册工作流 — 如今任何运营者都可以通过同一套经过验证的运维方案来运行，途径是与 AI 智能体对话，或直接进行 CLI 操作。过去需要深厚的 Linux 与 Solana 专业知识才能完成的高级调优，如今被集约进了 SLV，使得即便没有这种专业背景的运营者，也能仅凭对话加以复现。

SLV 官方网站: https://slv.dev/zh SLV GitHub: https://github.com/validatorsDAO/slv

让顶级验证者运维走向普惠 — 让世界一流的优化人人都能复现

SLV 是一项开源探索，旨在与 AI 智能体一同运营 Solana 验证者，以更低的成本，在世界任何地方，交付最高品质的运维。

在 Solana 上，验证者的原始性能与其背后的运维知识之间的差距一直在扩大。低延迟网络设计、内核与 NIC 调优、为协议升级所做的周密准备 — 这些通向顶级验证者性能的运维工作，都要求对 Linux 与 Solana 有深厚的专业知识，以及持续的动手投入。结果是，最高水平的运维往往只能被一小群拥有这种专业能力的运营者所触及。

SLV 的存在正是为了弥合这一差距。通过将世界一流的验证者运维所积累的运维知识集约成供 AI 智能体使用的技能，任何人都能仅凭对话来复现同一套运维方案。本次 Solana v4 支持，正是把这一理念直接应用到了最新的优化之上：XDP 与 BLS — 这些正是性能最高的验证者所采用的技术 — 如今向每一位使用 SLV 的运营者开放，而无需放弃他们自己对客户端或环境的选择。

Solana v4 支持带来了什么 — XDP、BLS 与重启安全性，全部为你打理

Solana v4（Agave 4.x）是 Anza 为主网推荐的最新一代验证者客户端，它在提升核心性能的同时，也让网络为更大的区块以及即将到来的 Alpenglow 共识升级做好准备。SLV 的 v4 支持涵盖了对于迁移到这一基线的运营者而言最为重要的三个方面。

XDP Turbine 再传输加速 — 对加速区块传播的高性能网络路径进行开箱即用的启用。
面向 Alpenglow 的 BLS 公钥注册（SIMD-0387）— 提前准备好注册工作流，使验证者在 Alpenglow feature gate 激活后即可完成注册。
Agave 4.1+ 的重启安全性 — 调整端口范围，并对仅用于集群重启的标志进行门控，使得迁移到新客户端不会引入本可避免的启动失败。

以上每一项都通过同一套 SLV 工作流来处理 — 与 AI 智能体对话或使用 CLI — 因此迁移到 Solana v4 不会变成一项手工的、易出错的工程。最新的 SLV 版本将上述全部内容作为 v2026.6.6 系列的一部分提供 — BLS、XDP 与重启安全性修复率先发布，而 Firedancer 与 RPC 的健壮性增强则作为同一系列的后续跟进。

什么是 XDP — 一条加速 Turbine 的 Linux 内核快速路径

XDP（eXpress Data Path）是一项 Linux 内核技术，让高性能网络代码能够绕过内核通常的大部分数据包处理路径。通过削减数据拷贝与上下文切换，它以远低于标准网络栈的开销来处理数据包。

在 Agave 中，XDP 被应用于 Turbine，即在验证者网络间传播区块的协议。接收到的 shred 由一个附着在网络接口卡（NIC）附近的 eBPF 程序处理，并通过 AF_XDP 映射到用户空间缓冲区；而发送的 shred 则使用 XDP_TX 直接送出 — 从而消除热路径上的系统调用与拷贝。Anza 在 Agave 3.x 系列（自 v3.0.9 起）为 Turbine 引入了 XDP，并将其延续到了 Agave 4.0 基线。

根据 Anza 的安装指南，借助 XDP，大型验证者的出站数据包可接近每秒 150,000。Anza 将 XDP 定位为让验证者为 100M-CU 区块做好准备、并推进 IBRL（Increase Bandwidth, Reduce Latency）路线图的余量的一部分，并为采用它的运营者发布了官方安装指南。

Anza Agave XDP Setup Guide: https://www.anza.xyz/blog/agave-xdp-setup-guide

SLV 让 XDP 开箱即用 — 仅凭对话和若干清单变量即可启用

手动采用 XDP 并不简单。它需要较新的内核（igb 驱动需 6.14+，其他需 6.8+）、一块支持 XDP 的 NIC、为验证者进程配置正确的 systemd capabilities，以及正确的启动标志 — 而 CPU 核心绑定（包括 PoH 核心）必须正确选择，该路径才能发挥性能。这正是那种长期把高级优化挡在许多运营者门外的专业工作。

SLV 把这变成了一个开箱即用的步骤。XDP 再传输加速通过每主机的清单变量来选择性启用 — xdp_enabled、xdp_interface、xdp_cpu_cores、xdp_zero_copy 以及 xdp_poh_pinned_cpu_core。一旦启用，SLV 会自动应用适配目标 Agave/Jito 版本的 XDP 启动标志，并授予所需的 systemd capabilities（CAP_NET_RAW、CAP_NET_ADMIN、CAP_BPF、CAP_PERFMON）。这些变量适用于 Agave 与 Jito 验证者；Firedancer 原生使用 XDP，无需单独启用。（XDP 在 Agave 各个版本中逐步成熟 — 自 Agave 4.1 起它已不再是实验性的，相应的标志名称也在此过程中有所变化 — 因此由 SLV 为每个版本追踪正确的标志，运营者无需操心。）

从运营者一侧来看，这一切都可以完全通过对话来驱动。启动 AI Console 并说一句类似“在这台验证者上启用 XDP 再传输加速”，AI 智能体便会选择并应用所需的配置。对于偏好 CLI 的用户，也提供了相应的命令，因此不涉及 AI 智能体的工作流同样得到完整支持。性能最高的验证者所使用的同一套网络优化，如今成为任何 SLV 运营者都能开启的东西。

面向 Alpenglow 的 BLS 注册 — 对 SIMD-0387 的前瞻性支持

Alpenglow 是 Solana 的下一代共识协议。为了高效地聚合验证者的投票 — 例如，简洁地证明 60% 的验证者投票跳过某个 slot — Alpenglow 将投票所用的签名从当前的 ed25519 替换为 BLS（Boneh–Lynn–Shacham）聚合签名方案。SIMD-0387 定义了验证者如何在其 vote account 中注册一个 BLS 公钥，以便在 Alpenglow 启用后即可投票。

根据 SIMD-0387，只有在该提案的 feature gate 激活之后，注册 BLS 公钥才成为可能；并且每个验证者都必须在 Alpenglow 上线之前，在其 vote account 中拥有一个 BLS 公钥，才能继续投票。BLS 密钥对由 vote authority 密钥（若不存在则由 identity 密钥）派生，注册在链上连同一份 Proof of Possession（PoP）一并完成 — 这是一份将该密钥绑定到 vote account、用以防止 rogue-key 攻击的密码学证明。目前，SIMD-0387 处于审查阶段，其 feature gate 在主网上尚未激活（已被纳入 devnet 激活的跟踪计划），因此主网上尚无法注册任何 BLS 密钥；今天真正重要的是，让工作流在 gate 开启时已经就绪。

这正是早做准备的意义所在。一旦 Alpenglow 上线，未注册 BLS 密钥的 vote account 将表现得如同未质押一般。提前把注册工作流准备到位，而不是在 gate 开启时手忙脚乱，才能让运维在整个过渡期间保持安全。

SLV 的 register:bls — 在部署时自动完成准备

SLV 替你把这项准备工作落实到位。全新的 slv v register:bls 命令，正是在 feature gate 激活后，将从 authorized-voter 或 identity 密钥派生的 BLS 公钥注册到每个 vote account 上的工作流。它还会在 slv v deploy 的末尾自动运行，因此通过 SLV 构建或更新的验证者，会作为常规流程的一部分走完这一步。

该操作被设计为在任何时候运行都是安全的。在 feature gate 尚未启用的集群上，它会作为一个 no-op 安全地通过；一旦 gate 激活，同一套工作流便会注册该密钥。它是幂等的，因此提前运行不会带来任何风险，也无需相对于升级精确地把握时机。与 XDP 一样，这一步骤同样既可通过与 AI 智能体对话来驱动，也可通过 CLI 来驱动。决定一台验证者能否在 Alpenglow 过渡期间继续投票的根基，无需手动密钥管理，便已提前打好。

强化 Agave 4.1+ 的重启安全性

迁移到新一代客户端可能会暴露出一些隐蔽的启动失败，而 SLV 的 v4 支持直接应对了这些问题。针对 Agave 4.1+（以及基于同一基线的 Jito 验证者），动态端口范围被拓宽到至少 27 个端口（8000–8030 / 8900–8930），从而解决了 Agave/Jito 4.1.0+ 在启动时以 "Port range is too small" 拒绝较窄范围的情况 — 这一失败曾让验证者和 RPC 节点陷入崩溃循环。该修复覆盖了所有 validator、RPC 与 pythnet 启动脚本，以及 init 与清单的默认值。

此外，仅用于集群重启的标志现已被门控：--wait-for-supermajority 与 --expected-bank-hash 仅在被显式设置时才会附加，因此在普通重启中，过期的 slot 或 bank hash 再也无法让节点挂起，或因 bank-hash 不匹配而 panic。这些正是那种若靠手工处理就会把例行升级变成一场事故的细节 — 如今由 SLV 作为标准方案的一部分加以打理。

这种健壮化贯穿整套方案。一次后续发布把同样的运维健壮性扩展到了 Firedancer 与 RPC 路径 — 网络感知的 Firedancer 版本处理、一次 Jito 构建冲突的清理，以及 RPC 启动脚本的修正 — 从而使得无论运营者运行的是哪种客户端，迁移到最新基线都能保持顺畅。

消除重复造轮子 — 把顶级运维知识集约进 AI 智能体

在 Solana 生态中，许多项目都在运营验证者和节点这一共通的工作上花费时间，而这与开发其真正的产品是相分离的。构建、部署、监控、更新、迁移客户端 — 对每一个项目而言，这些都是同一批任务相似的重复，是某种意义上的重复造轮子。

XDP 的启用以及面向 Alpenglow 的 BLS 注册，正是绝佳的例子。它们都很高级、容易出错，且本来每个运营者都不得不各自独立去研究并重新推导。通过将这些运维知识集约成供 AI 智能体使用的 SLV 技能，同一套经过验证的方案便能被任何人仅凭对话加以复现 — 运维的人力成本也随之在结构上下降。随着本次发布，AI 智能体所依据的知识 — SLV 验证者技能 — 已针对 BLS（SIMD-0387）与 XDP 进行了更新，因此该智能体应用的是当前正确的流程，而非过时的流程。这就是“以更低的成本提供最高品质的运维”在实践中的含义。

SLV 将继续与 SLV AI 一起，逐一化解 Solana 各项目共通的运维负担 — 让每一个项目都能专注于其自身产品的本质开发。

CLI 与 AI 智能体兼备 — 稳定性支撑着两者

SLV 不仅作为 AI 智能体，作为 CLI 也能稳定运行。对于那些不愿依赖 AI 智能体，或希望将 SLV 集成进脚本化自动化流程的用户而言，SLV 依然是一个实用的运维基础。

而这种 CLI 层面的稳定性，正是支撑 AI 智能体运营可靠性的根基。SLV 的每一项功能都兼容 MCP（Model Context Protocol），AI 智能体通过 MCP 调用的，正是 CLI 所调用的同一套接口。当 CLI 稳定时，AI 智能体也稳定 — 这一设计原则支撑着 SLV AI 智能体运营的可靠性。XDP 的启用与 register:bls 同样如此，在同一 MCP 基础之上，既可从 CLI、也可从 AI 智能体以相同方式处理。

一个支撑性能追求的运维基础 — Epics DAO 验证者达到世界第 3

作为 ERPC 的 SWQoS 端点与 Epic Shreds 配发来源运营的 Epics DAO 验证者，在全体 Solana 验证者中，已于 Shinobi Performance Pool 达到了世界综合第 3（评分 99.93），其投票相关评分超过 99%。

这一成绩是多项改进累积的成果：硬件选型、内核参数优化、网络栈调优、IRQ 亲和性调整、DoubleZero 的采用，以及恰如 XDP 所代表的那类网络优化。SLV 将这些运维知识集约进 AI 智能体，并以任何人都能作为同一套运维方案复现的形式加以交付。此处所述的优化并非纸上谈兵 — 它们源自已经登顶网络的实际运营。

与 ERPC 平台相结合

SLV 的 Solana v4 支持可在任何环境中运行，而它与 ERPC 平台尤为相配。ELSOUL LABO 以 RIPE NCC 授予的自有 ASN（AS200261）运营着一座 Solana 专用数据中心，作为 ERPC 平台的一部分 — 在那里，你可以把 v4 优化、SLV 的运维自动化与 ERPC 平台一并使用。

ERPC 通过将配发来源验证者、接收端点与处理节点置于 Solana 验证者高密度集聚的优质数据中心内部，在设计阶段就抑制了由距离引起的延迟。Solana RPC、WebSocket、Solana Geyser gRPC、Solana Shredstream、Direct UDP Stream（Raw Shreds）、VPS、裸金属服务器、SWQoS、Pyth 兼容的 Price API，以及 Jet Analytics & Indexed RPC，都可以在同一平台上组合使用。在 ERPC 平台上运行一台用 SLV 构建的 v4 验证者，让你能在同一环境中，把 SLV 的优化与 ERPC 设计层面的速度结合起来。

ERPC 官方网站: https://erpc.global/zh