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/ja 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 対応は、この基盤へ移行するオペレーターにとって特に重要な 3 つの領域をカバーします。

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 は Turbine 向けの XDP を Agave 3.x 系（v3.0.9 から）で導入し、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 の再送高速化は、per-host のインベントリ変数 — 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 エージェントが必要な設定を選択し、適用します。CLI 派のユーザー向けにも対応するコマンドが提供されており、AI エージェントを使わない運用にも対応しています。最もパフォーマンスの高いバリデータが使うのと同じネットワーク最適化が、SLV を使うどのオペレーターでも有効にできるものになります。

Alpenglow に向けた BLS 登録 — SIMD-0387 への先行対応

Alpenglow は、Solana の次期コンセンサスプロトコルです。バリデータの投票を効率的に集約するため — たとえば、バリデータの 60% がスロットのスキップに投票したことを簡潔に証明するため — Alpenglow は、投票に用いる署名を、現行の ed25519 から BLS（Boneh–Lynn–Shacham）集約署名方式へと置き換えます。SIMD-0387 は、バリデータが Alpenglow 有効化後に投票できるよう、vote account に BLS 公開鍵を登録する方法を定義しています。

SIMD-0387 では、BLS 公開鍵の登録は、その提案の feature gate が有効化されて初めて可能になり、各バリデータは 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 は、unstaked であるかのように振る舞います。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 バリデータ）向けに、dynamic_port_range を 27 ポート以上（8000–8030 / 8900–8930）に拡張しました。Agave/Jito 4.1.0+ は狭いレンジを起動時に「Port range is too small」として拒否し、バリデータや RPC ノードが起動時に crash-loop に陥っていました。本修正はこれを解消し、すべての validator / RPC / pythnet の start script と、init・インベントリの既定値をカバーします。

さらに、クラスター再起動専用のフラグをゲート化しました。--wait-for-supermajority と --expected-bank-hash は、明示的に設定された場合にのみ付与されるようになり、古くなった slot や bank hash が通常の再起動でノードをハングさせたり、bank-hash 不一致で panic させたりすることがなくなりました。これらは、手作業で扱えば日常的なアップグレードを障害に変えかねない類の細部であり、SLV はそれを標準のレシピの一部として引き受けます。

この堅牢化は、レシピ全体に及んでいます。後続のリリースでは、同じ運用上の堅牢性を Firedancer と RPC の経路にも広げました — ネットワークを意識した Firedancer のバージョン処理、Jito のビルド競合のクリーンアップ、RPC start script の修正 — これにより、どのクライアントを運用していても、最新の基盤への移行がスムーズに保たれます。

車輪の再発明をなくす — トップ級のノウハウを AI エージェントに集約する

Solana エコシステムでは、多くのプロジェクトが、本来のプロダクト開発とは別に、バリデータやノードの運用という共通の作業に時間を割いています。クライアントのビルド、デプロイ、監視、アップデート、移行 — これらは、どのプロジェクトにとっても似たような作業の繰り返しであり、いわば車輪の再発明です。

XDP の有効化や、Alpenglow に向けた BLS 登録は、その典型です。いずれも高度で、間違えやすく、本来は各オペレーターが個別に調べ、再導出しなければなりません。この運用ノウハウを SLV のスキルとして AI エージェントに集約することで、同じ実証済みのレシピを、誰もが対話だけで再現でき、運用の人的コストは構造的に下がります。今回のリリースでは、AI エージェントが参照する SLV バリデータスキルを BLS（SIMD-0387）と XDP に向けて更新しており、エージェントは古い手順ではなく、現行の正しい手順を適用します。「最高品質のメンテナンスを、コストを抑えて」とは、実際にはこういうことです。

SLV は、これからも Solana プロジェクトに共通する運用の負担を、SLV AI とともに一つずつ解消し、各プロジェクトが自分たちのプロダクトの本質的な開発に集中できる環境を整えてまいります。

CLI と AI エージェントの両対応 — 安定性が両者を支える

SLV は AI エージェントだけでなく、CLI としても安定して動作します。AI エージェントによる運用を好まないユーザーや、スクリプト化された自動化フローに組み込みたいユーザーにとっても、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）に到達しています。vote 関連のスコアは 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 を同一プラットフォーム上で組み合わせて利用できます。SLV で構築した v4 バリデータを ERPC プラットフォーム上で運用することで、SLV の最適化と、ERPC の設計レベルの速さを、同じ環境で組み合わせられます。

ERPC 公式サイト: https://erpc.global/ja

SLV AI トークンで今すぐ始められる

SLV の AI エージェントは、SLV AI トークンを利用して動作します。5€ の Authorization を行うことで 100,000 トークンを無料で利用開始でき、XDP の有効化、BLS 登録の準備、そして Solana v4 バリデータの運用を、AI エージェントとの対話で体験するのに十分なボリュームです。

ERPC SLV AI Plans: https://erpc.global/ja/price/

ChatGPT および Claude の API トークンを利用した接続にも対応しているため、お客様自身の API キーで SLV AI を動作させることも可能です。

フィードバックをお寄せください

SLV は、ご利用者の皆様からのフィードバックによって日々改良されています。今回の Solana v4 対応も、Validators DAO 公式 Discord に寄せられた声と、ネットワークの頂点でバリデータを運用する中から形になりました。実際にお試しいただき、ご意見・ご要望を Validators DAO 公式 Discord までお寄せください。

いつもありがとうございます。これからも SLV と ERPC をよろしくお願いいたします。

お問い合わせ

SLV および ERPC に関するお問い合わせは、Validators DAO 公式 Discord にてサポートチケットを作成ください。

Validators DAO 公式 Discord: https://discord.gg/C7ZQSrCkYR

リンク一覧

SLV 公式サイト: https://slv.dev/ja
SLV Getting Started: https://slv.dev/ja/doc/general/getting-started/
SLV GitHub: https://github.com/validatorsDAO/slv
Anza Agave XDP Setup Guide: https://www.anza.xyz/blog/agave-xdp-setup-guide
SIMD-0387 (BLS Pubkey Management in Vote Account): https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0387-bls-pubkey-management-in-vote-account.md
ERPC 公式サイト: https://erpc.global/ja
ERPC SLV AI Plans: https://erpc.global/ja/price/
Epics DAO 公式サイト: https://epics.dev/ja
Validators DAO 公式 Discord: https://discord.gg/C7ZQSrCkYR

SLV が Solana v4 対応を完了 — XDP による Turbine 高速化と Alpenglow 先行対応の BLS 登録を、AI エージェントとの対話で誰でも再現できる運用レシピとして提供