SLV が Solana v4 対応を完了—XDP による Turbine 高速化と Alpenglow 先行対応の BLS 登録を、AI エージェントとの対話で誰でも再現できる運用レシピとして提供
トップ級のバリデータ運用を、AI エージェントとともに、コストを抑えて、世界中で。
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は、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）のロードマップを前進させる余力の一部と位置づけており、導入するオペレーター向けに公式のセットアップガイドも公開しています。
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の設計レベルの速さを、同じ環境で組み合わせられます。
SLV AIトークンで今すぐ始められる
SLVのAIエージェントは、SLV AIトークンを利用して動作します。5€のAuthorizationを行うことで100,000トークンを無料で利用開始でき、XDPの有効化、BLS登録の準備、そしてSolana v4バリデータの運用を、AIエージェントとの対話で体験するのに十分なボリュームです。
ChatGPTおよびClaudeのAPIトークンを利用した接続にも対応しているため、お客様自身のAPIキーでSLV AIを動作させることも可能です。
フィードバックをお寄せください
SLVは、ご利用者の皆様からのフィードバックによって日々改良されています。今回のSolana v4対応も、Validators DAO公式Discordに寄せられた声と、ネットワークの頂点でバリデータを運用する中から形になりました。実際にお試しいただき、ご意見・ご要望をValidators DAO公式Discordまでお寄せください。
いつもありがとうございます。これからもSLVとERPCをよろしくお願いいたします。
お問い合わせ
SLVおよびERPCに関するお問い合わせは、Validators DAO公式Discordにてサポートチケットを作成ください。
リンク一覧
すべての画像
