Agave 4.0アップデート：知っておくべきすべて

はじめに

Agave 4.0では、Solanaの中核バリデータクライアントがさらに進化します。主要なパフォーマンス経路を改善するとともに、より大きなブロックと、待望のAlpenglowコンセンサスアップデートに向けてネットワークを準備します。

Agave 4.0リリースサイクルの主なアップデート

• XDPによるTurbine再送の大幅な高速化
• Replay Stageの低レイテンシ化
• Alpenglow対応：高速なリーダー引き継ぎマーカーと連鎖ブロックID検証*
• 暗号化サポートの拡張：G2演算とBLS12-381 syscall*
• Wincodeによるシリアライズの改善
• Stake Program v5による最低ステーク委任額の引き上げ*
• ZK ElGamal証明プログラムの再有効化*
• SBPFv3プログラムのサポート*

* feature gateで制御されるアップグレード

バリデータ運用者にも開発者にも、本ガイドでは最新の改善を最大限に活用するために必要なアップデートと知見を提供します。各セクションは独立しているため、読者は自分に最も関連するトピックに集中できます。 

執筆時点で、Agave v4.0.0-rc.0はmainnetアップグレード候補（MUC）と見なされており、Anzaはこのリリースをステークの25%まで普及させるための協力者を募っています。バリデータの皆さま、今こそアップグレードするときです！

XDPが広範な導入に対応

XDP（eXpress Data Pathの略）は、AgaveがTurbineを高速化するために使用する高性能ネットワーク経路です。Agaveはネットワークインターフェースカードの近くにeBPFプログラムを読み込めるため、shredトラフィックは標準的なLinuxパケット処理経路の大部分を迂回できます。

Solanaがブロック上限の引き上げを進めるなか、Turbineが主要なボトルネックになるため、これは重要です。リーダーは数百のピアへshredを配信する必要があり、大規模なバリデータでは現状でも送信パケット数が毎秒150,000件近くに達する可能性があります。ネットワークが長年の目標である1億CUブロックへ向かうには、パケット送信と再送のパフォーマンスを実行スループットに合わせて拡張する必要があります。XDPはブロック伝播を大幅に高速化し、そのための余力を生み出します。

Agave 4.0により、XDPはより広範なバリデータへの導入準備が整いました。さまざまな構成でストレステストが行われ、さらに堅牢化され、追加のルーティング改善も施されています。本番環境での結果は非常に有望で、Turbineの再送は桁違いに高速化しています。

Alessandro Decina

@alessandrod

one of the largest validators turbine retransmit from 600ms to ~0.8ms agave 4.0 w/ XDP is going to be the biggest solana upgrade to date https://t.co/cKwqVnpH2g

2026年4月22日 午前5:25

XDPがこれほど大きな改善となる理由について、さらに詳しくは、以前公開したAnzaのエンジニアAlessandro Decina氏へのインタビューをご覧ください。

Replay Stageの高速化

Agave 4.0では、コストの高い2つの検証ステップをリプレイスレッドのクリティカルパスから外すことで、リプレイを高速化しています。v4.0では、エントリ検証とトランザクション署名検証の両方が非同期で実行されます。これにより、バックグラウンドジョブがスロットの有効性を確認している間もリプレイ処理を継続できます。

最初の変更では、PoHエントリ検証をバックグラウンドに移します。以前は、処理を続ける前にリプレイがエントリのハッシュチェーンをインラインで検証していました。2つ目の変更では、同じ考え方をトランザクション署名に適用しますが、重要な分離があります。Agaveはトランザクションのハッシュ／メッセージ検証とEd25519署名検証を分離するようになりました。トランザクションを安全にサニタイズして実行できるように、ハッシュ経路は引き続き先に実行されます。一方、よりコストの高い署名チェックはバックグラウンドで実行され、ブロックが受け入れられる前に合流します。

実際の効果として、Replay Stageのブロック時間が大幅に減ります。特に、署名チェックがトランザクション数に比例して増える混雑したスロットで効果を発揮します。

Wincodeのさらなる採用

WincodeはAnzaが開発したシリアライズおよびデシリアライズ用ライブラリです。インプレース初期化とメモリへの直接書き込みを前提に設計され、中間バッファリングを最小限に抑えます。より一般的なbincodeとの完全な互換性を保ちながら、Rustシリアライザの中でも最高水準のパフォーマンスを実現します。

Agave 4.0では、パフォーマンスが重要なシリアライズ経路が、さらにbincodeからwincodeへ移行しています。Solanaでディスクに書き込まれる、またはネットワーク経由で送信されるほぼすべてのデータがbincodeに依存しているため、これらの経路の最適化は広範な効果をもたらします。

最低ステーク委任額の引き上げ（Stake Program v5）

Agave 4.0では、Stake Programに重要なアップデートが加わります。SIMD-0490で説明されているこのfeature gate変更は、Solanaが進めるステーク保証金（別名rent）の削減に向けた準備です。

最も注目すべき変更は、最低ステーク委任額が1 lamportから1 SOLへ引き上げられることです。これにより、rent要件の引き下げに伴ってステークアカウントの作成・維持コストが低くなりすぎ、潜在的な攻撃経路が生じることを防ぎます。この基準を下回る小規模なステークアカウントは多数存在しますが、アクティブステーク総量のわずか0.02%にすぎず、アップデートの有効化後も既得権として維持されます。

このアップグレードでは、ステークアカウント処理の複数の部分も整理されます。rentの計算では、各アカウントに保存されたrent_exempt_reserveに依存せず、Rent sysvarを使用するようになります。また、ステークプログラム操作のsysvarアカウント入力が任意になり、長年存在していたエッジケースを修正するためにSplitの実装が書き直されます。 

バリデータ運用者のコミュニティは、新しい最低額1 SOLを問題なく受け入れています。ステークプログラムと連携するツールやdappは、新しい最低額を考慮するようロジックを確認する必要があります。

暗号化サポートの改善 

Agave 4.0のリリースサイクル全体で行われる複数の機能有効化は、Solanaのネイティブな暗号化機能を拡張し、ZK証明やBLS署名などの最新ユースケースをより適切にサポートすることを目的としています。

ZK ElGamal証明プログラムの再有効化

ZK ElGamal証明プログラムは、Token-2022の機密送金で使用されるゼロ知識証明を検証するSolanaネイティブプログラムです。基礎となるデータを開示せずに、暗号化された残高とトランザクションを検証できます。ElGamalベースの暗号証明に対応する汎用検証器として機能し、Solanaのプライバシー保護トークン機能の中核を担います。 

このプログラムは、2025年6月のセキュリティインシデントを受けてmainnetで無効化されました。証明検証ロジックの不備、具体的にはFiat-Shamirトランスクリプトのハッシュ処理に要素が欠けていたため、検証を通過する偽造証明を作成できました。実環境での悪用は確認されませんでしたが、潜在的な影響を考慮して、このプログラムはfeature gateで無効化され、修正と監査が完了するまで機密送金も一時停止されました。問題への対処と実装の強化が完了したため、現在はmainnetでの再有効化が予定されています。

alt_bn128向けG2演算

SIMD-0302：alt_bn128 G2 Syscallの追加は、Solanaの既存のBN254（alt_bn128）暗号化syscallを拡張し、加算、減算、スカラー乗算を含むG2曲線上の点に対するネイティブ演算をサポートします。G1とG2はペアリングベース暗号で使用される2つの楕円曲線群であり、G2はより大きな拡大体上で定義されます。

これにより、主にG1演算を中心とする現在のsyscallセットの重要な不足が補われ、ペアリングベース暗号をオンチェーンで直接、より完全にサポートできるようになります。特に、BLS署名検証や高度なZK証明システムなどのユースケースに有効です。

ネイティブのG2サポートがないため、一部のプロジェクトではsolana-alt-bn128-blsのようなカスタム実装に依存してきました。これは、BlueshiftのDean Little氏が既存のsyscall上に構築したエンドツーエンドのBLS署名ライブラリです。syscallレベルでG2演算を有効にすれば、こうした回避策が不要になり、本番品質の暗号プロトコルをSolana上でネイティブに構築しやすくなります。

alt_bn128のリトルエンディアン対応

SIMD-0284：alt_bn128へのリトルエンディアン互換性の追加は、Solanaの既存のalt_bn128暗号化syscallを拡張し、リトルエンディアン形式の入出力をサポートします。以前、これらのsyscallはビッグエンディアンのエンコーディングしか受け付けませんでした。そのため、ツールやライブラリ、特にEthereumエコシステム由来のものを使用する開発者にとって障害となっていました。Solana上の大半のZKチームが、リトルエンディアンで動作するark-bn254を使用しているためです。この変更には後方互換性があり、alt_bn128上の楕円曲線演算を伴う既存ユースケースへの対応を拡大します。

BLS12-381 Syscall

最後に、SIMD-0388：BLS12-381 Syscallでは、BLS12-381楕円曲線上の暗号演算をネイティブにサポートします。これにより、最新の128ビットセキュリティを備えたペアリング対応曲線をSolanaプログラムで利用できるようになります。これまでSolanaはペアリングベース暗号にBN254（alt_bn128）を使用してきましたが、このセキュリティ基準を満たしておらず、Ethereumなど広く採用されている他のエコシステムとの互換性も制限されていました。

このアップグレードでは、まったく新しいsyscallインターフェースを導入するのではなく、既存の曲線syscallをBLS12-381のG1およびG2演算向けの新しい識別子で拡張します。開発者は使い慣れたインターフェースで群演算、点検証、展開、バッチペアリングチェックを実行でき、暗号化機能が大幅に拡張されます。

この取り組みは、ゼロ知識証明とBLS署名検証を全般的に改善するだけでなく、Alpenglowコンセンサスを実現するための重要な要素でもあります。特に、バリデータがBLS Proofs of Possessionをオンチェーンで検証できるようになり、不正鍵攻撃を防げます。続いて、この点を詳しく見ていきます。

Alpenglow対応

BLS12-381 syscallは、Alpenglowコンセンサスアップグレードの基盤を築くため、Agave 4.0のリリースサイクルで有効化される複数のfeature gateの1つにすぎません。以下では、展開に寄与する追加の有効化項目を紹介します。現在、AlpenglowはAgave 4.1とともに2026年第3四半期にmainnetへ導入される予定です。

連鎖ブロックID検証

SIMD-0340：連鎖ブロックIDの検証は、TowerBFTとAlpenglowの両コンセンサスで一貫した正規チェーンを保証するために、バリデータがブロックの系譜を検証する方法を定義します。スロット番号だけではブロックを一意に識別できないためです。特に、同じスロットに複数のブロックが生成され得る二重提案の場合、クライアントは正しい親子関係を判断するためにスロット順序へ依存できません。

この変更では、各ブロックが親を正しく参照していることを保証する明示的なチェーン検証ルールを導入し、分岐を防いでネットワークが単一の履歴へ収束できるようにします。TowerBFTでは、スロット内とスロット間の両方でFECセットが親のMerkle rootを参照することを必須にして、これを強制します。Alpenglowでは、スロット内のすべてのFECセットに対して二重Merkle root構造を使用します。これらのチェックに失敗すると、そのブロックまたはスロットはdeadとマークされます。こうしたルールを強制することでコンセンサスの安全性が高まり、バリデータは不正または競合するブロックを受信しても復旧できます。

高速リーダー引き継ぎマーカー

SIMD-0337：Alpenglowの高速リーダー引き継ぎ用マーカーは、親スロットが完全に完了し、安全にその上へ構築できるタイミングをバリデータが判断するための明示的なシグナリングルールを定義します。これは、高速なリーダー移行の前提条件です。この変更では、DATA_COMPLETE_SHREDの配置要件を厳格化し、新しい「parent ready」マーカーを導入します。これにより、ブロックの完全性をshredストリーム自体から明確に検出できます。

現在は、スロットが完全に送信されたかどうかが曖昧なため、次のリーダーへの移行が遅れる可能性があります。追加のshredを待つ必要がある場合や、不完全なデータ上に構築するリスクがあるためです。完了を通知する方法を標準化することで、次のリーダーは追加の調整や推測を行わず、確信を持ってより早くブロック生成を開始できます。

これはAlpenglowの高速リーダー引き継ぎ設計を支える重要な構成要素です。リーダー間の空白時間を最小化することで、ネットワークスループットが直接向上します。

Voteトランザクションのコストモデル更新

SIMD-0458：静的なSimpleVoteトランザクションコストの廃止では、Voteトランザクションに固定CUコストを使用する仕組みを廃止し、Vote以外のトランザクションに使用される標準のトランザクションコストモデルに統一します。 

現在、単純なVoteトランザクションには、実行コストが決定論的であるという従来の前提に基づき、一定の3,428 CUが課されています。新しいモデルでは、Voteトランザクションも他のトランザクションと同様に動的に計測されます。これにより、コスト計算の一貫性が高まり、個別のVote CU上限が不要になります。

Voteトランザクションの実際のランタイムCU消費量は変わりませんが、ブロックへのパッキング時の計上方法は変わります。具体的には、Voteにはアカウントデータ読み込みコストなど、推定で約~16,000 CUが追加されます。そのため、リーダーがブロックを構築する際の初期CU予約量が増えます。

この変更は、Voteプログラムの実行プロファイルが静的であるという前提を廃止したSIMD-0387（VoteアカウントでのBLS公開鍵管理）に続くものです。

その他の注目すべきアップグレード

Agave 4.0リリースサイクルのその他の主な変更には、SBPFv3プログラムのサポート、事前入金済みアカウントを作成する機能、スナップショット展開用のdirect I/Oがあります。

SBPFv3プログラムのサポート

Agave 4.0のリリースサイクルには、SBPFv3プログラムのデプロイと実行を有効にするfeature gateが含まれています。Solana Berkeley Packet Filter（SBPF）は、SolanaがRustベースでフォークしたeBPFです。オンチェーンプログラムが実行前にコンパイルされる低レベルのバイトコード形式および仮想マシンです。このアップデートは、SIMD-0178、SIMD-0189、SIMD-0377という3つのSIMDで説明されている取り組みを統合します。 

SIMD-0178では、静的syscallを導入し、syscall参照をランタイムのELF再配置ではなくリンク時に解決できるようにします。現在、こうした再配置はプログラムローダーを複雑にしています。これを削除することで実行が簡素化され、セキュリティリスクが低減します。

続いてSIMD-0189では、プログラムで許可されるELFレイアウトを厳格化し、より厳密なファイル構造を必須にします。これにより、バリデータが解析するエッジケースと処理すべき予期しないデータが減ります。リンカーツールチェーンが準拠バイナリを自動的に出力すると想定されているため、開発者への影響はない見込みです。

最後に、SIMD-0377では、LLVMが生成する最新のeBPF命令セットにより適合するようSBPF仮想マシンを更新し、32ビットジャンプ演算などの追加命令をサポートします。目的は、SolanaのVMとアップストリームツールとの互換性を高め、プログラムをより効率的なバイトコードへコンパイルできるようにすることです。開発者にとっての実質的な効果は、プログラム読み込みの高速化、攻撃対象領域の縮小、そしてアプリケーションロジックを変更せずにコンピュート使用量を削減できる可能性です。

事前入金済みアカウントの作成

SIMD-0312：CreateAccountAllowPrefundは、Agave 4.0のリリースサイクル中にmainnetで有効化される予定です。これにより、新規作成アカウントの開始時lamport残高をゼロにする要件を取り除く新しい命令がシステムプログラムに導入されます。アカウントの作成前に入金できるようになり、一般的な開発ワークフローが簡素化され、不要な命令も減ります。

以前は、送信先アカウントがすでにlamportを保有していると、CreateAccount命令が失敗していました。そのため開発者は、通常はtransferの後にallocateとassignを実行するなど、アカウント初期化を複数のステップに分割する必要がありました。これにより複雑さが増し、追加のコンピュートコストも発生します。このパターンは、アカウントへ事前に資金を投入するプログラムで特によく見られます。

新しい命令では、事前入金済みアカウントを直接初期化できるため、これらのステップを1回の呼び出しに統合できます。実際にはCPIのオーバーヘッドが減り、一般的なフローで数千コンピュートユニットを節約できるため、今後は開発者にとってよりシンプルで高性能な方法となります。既存命令の変更ではなく新しい命令として導入されるため、完全な後方互換性も維持されます。

スナップショット展開用のDirect I/O 

Agave 4.0では、スナップショットの書き込みをOSのページキャッシュ経由で行う代わりに、デフォルトでdirect I/Oを使用してスナップショットを展開します。これにより、起動時間とスナップショット復元のパフォーマンスが向上します。スナップショットデータは通常ディスクへストリーミングされ、メモリ内のアクセス頻度が高いバリデータデータを追い出す必要がないため、特に有効です。ファイルシステムがO_DIRECTをサポートしていない場合、運用者は**--no-accounts-db-snapshots-direct-io**を使用して無効化できます。将来のリリースでは、direct I/Oがスナップショット作成にも拡張される見込みです。 

まとめ

Agave v4.0は、幅広いパフォーマンス改善とランタイム最適化を実現する大規模なクライアントアップグレードです。これらの変更は、ネットワークをより高速で安全にし、開発しやすくするために設計されています。

今後の次のマイルストーンは、Agave 4.1とApenglowコンセンサスアップデートです。

関連リソース

• Agave 4.0リリーススケジュール
• Feature Gate Trackerスケジュール
• Agave 4.0変更履歴
• Agave 4.0プルリクエスト