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 Agent 對話或直接使用 CLI 操作來執行。過去需要深厚 Linux 與 Solana 專業知識的進階調校，如今已彙整進 SLV，即使不具備該專業背景的營運者，也能僅透過對話再現。

SLV 官方網站：https://slv.dev/zh-tw SLV GitHub：https://github.com/validatorsDAO/slv

將頂級驗證者營運民主化 — 讓任何人都能再現世界級的最佳化

SLV 是一項開源計畫，旨在與 AI Agent 一同營運 Solana 驗證者，以低成本在世界各地提供最高品質的維運。

在 Solana 上，驗證者原始性能與其背後營運訣竅之間的差距一直在擴大。低延遲網路設計、核心與 NIC 的調校、為協定升級所做的周密準備 — 通往頂級驗證者性能的營運，需要對 Linux 與 Solana 的深厚專業知識，以及持續的親力勞動。其結果是，最高水準的營運往往只有具備該專業的有限營運者群體才能接觸。

SLV 的存在正是為了縮小這道差距。藉由將世界級驗證者營運所累積的營運訣竅彙整為 AI Agent 的技能，任何人都能僅透過對話再現同一套營運配方。本次 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 Agent 對話或 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 — 以 opt-in 方式啟用。啟用後，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 Agent 便會選擇並套用必要的設定。同時也為偏好 CLI 的使用者提供了對應的指令，因此不涉及 AI Agent 的工作流程也獲得完整支援。最高性能驗證者所使用的同一套網路最佳化，成為任何 SLV 營運者都能開啟的功能。

Alpenglow 先行對應的 BLS 註冊 — 對 SIMD-0387 的先行支援

Alpenglow 是 Solana 的次世代共識協定。為了有效率地彙整驗證者的投票 — 例如，簡潔地證明有 60% 的驗證者投票跳過某個 slot — Alpenglow 將投票所用的簽章，從目前的 ed25519 替換為 BLS（Boneh–Lynn–Shacham）彙整簽章方案。SIMD-0387 定義了驗證者如何在其 vote account 中註冊 BLS 公鑰，以便在 Alpenglow 啟用後即可投票。

依據 SIMD-0387，註冊 BLS 公鑰在該提案的 feature gate 啟用後才有可能進行，且每個驗證者都必須在 Alpenglow 上線前於其 vote account 中擁有一個，才能持續投票。BLS 金鑰對由 vote authority 金鑰（若無則使用 identity 金鑰）導出，而註冊則於鏈上連同 Proof of Possession（PoP）一併執行 — 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 啟用後，於每個 vote account 上註冊 BLS 公鑰（由 authorized-voter 或 identity 金鑰導出）的工作流程。它也會在 slv v deploy 的最後自動執行，因此透過 SLV 建置或更新的驗證者，會把這個步驟當作正常流程的一部分通過。

此操作設計為可在任何時間安全執行。在 feature gate 尚未啟用的叢集上，它會作為 no-op 安全通過；一旦 gate 啟用，同一套工作流程便會註冊金鑰。它具備冪等性，因此提早執行不帶任何風險，也無需針對升級精準地拿捏時機。如同 XDP，這個步驟同樣可以透過與 AI Agent 對話或透過 CLI 來驅動。決定驗證者能否在 Alpenglow 過渡期間持續投票的基礎工作，會事先就位，且無需手動的金鑰管理。

為 Agave 4.1+ 強化重啟安全性

遷移到新世代用戶端可能會浮現細微的啟動失敗，而 SLV 的 v4 支援直接針對這些問題加以處理。對於 Agave 4.1+（以及採用相同基礎的 Jito 驗證者），dynamic_port_range 被拓寬至至少 27 個連接埠（8000–8030 / 8900–8930），解決了 Agave/Jito 4.1.0+ 在啟動時以「Port range is too small」拒絕較窄範圍的情況 — 這項失敗曾使驗證者與 RPC 節點陷入 crash-loop。此修正涵蓋所有 validator、RPC 與 pythnet 啟動腳本，連同 init 與盤點預設值。

此外，僅供叢集重啟使用的旗標如今已被閘控：--wait-for-supermajority 與 --expected-bank-hash 只在明確設定時才會輸出，因此過時的 slot 或 bank hash 不再會在一般重啟時使節點掛起，或因 bank-hash 不一致而使其 panic。這些正是那類若以手動處理便會把例行升級變成事故的細節 — 而 SLV 如今將其作為標準配方的一部分加以處理。

這項強健化貫穿整套配方。後續的版本將同樣的營運強健性延伸到 Firedancer 與 RPC 路徑 — 具網路意識的 Firedancer 版本處理、Jito 建置衝突清理，以及 RPC 啟動腳本修正 — 使得無論營運者運行哪一種用戶端，遷移到最新基準都能保持順暢。

消除重複造輪 — 將頂級訣竅彙整進 AI Agent

在 Solana 生態系中，許多專案在開發其實際產品之外，還要花時間在營運驗證者與節點這類共通工作上。建置、部署、監控、更新與遷移用戶端 — 對每個專案而言，這些都是相同任務的類似重複，是一種重複造輪。

XDP 啟用與 Alpenglow 先行對應的 BLS 註冊正是絕佳的例子。它們既進階又容易出錯，否則每位營運者都必須各自研究並重新推導。藉由將這套營運訣竅彙整為 AI Agent 的 SLV 技能，同一套經過驗證的配方便能由任何人僅透過對話再現 — 而營運的人力成本也隨之結構性地下降。在本次版本中，SLV 驗證者技能 — 也就是 AI Agent 所依據的知識 — 已針對 BLS（SIMD-0387）與 XDP 加以更新，因此 Agent 會套用當前正確的程序，而非過時的程序。「以低成本提供最高品質的維運」在實務上的意義正是如此。

SLV 將持續與 SLV AI 一同，逐一解決 Solana 各專案共通的營運負擔 — 讓每個專案都能專注於其自身產品的本質開發。

CLI 與 AI Agent 兼備 — 穩定性支撐兩者

SLV 不僅作為 AI Agent，作為 CLI 也能穩定運作。對於不偏好依賴 AI Agent，或想將 SLV 整合進腳本化自動化流程的使用者而言，SLV 依然是實用的營運基礎。

這種 CLI 層級的穩定性，正是支撐 AI Agent 營運可靠性的基礎。SLV 的每一項功能皆相容於 MCP（Model Context Protocol），而 AI Agent 透過 MCP 呼叫與 CLI 相同的介面。當 CLI 穩定時，AI Agent 便穩定 — 這項設計原則支撐著 SLV AI Agent 營運的可靠性。XDP 啟用與 register:bls 同樣可以在相同的 MCP 基礎上，從 CLI 與 AI Agent 兩者以相同方式處理。

支撐對性能堅持的營運基礎 — Epics DAO 驗證者達到世界第 3 名

作為 ERPC 的 SWQoS 端點與 Epic Shreds 配送來源所營運的 Epics DAO 驗證者，在所有 Solana 驗證者之中，於 Shinobi Performance Pool 已達到世界總合第 3 名（分數 99.93），且 vote 相關分數超過 99%。

這項成果是多項改善累積的結果：硬體選型、核心參數最佳化、網路堆疊調校、IRQ 親和性調整、採用 DoubleZero，以及正是 XDP 所代表的那類網路最佳化。SLV 將這套營運知見彙整進 AI Agent，並以任何人都能作為同一套營運配方再現的形式提供。此處所述的最佳化並非紙上談兵 — 它們源自已抵達網路頂點的營運。

與 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-tw