Agave 3.0アップデート：知っておくべきこと

はじめに

Agave v3.0のメジャーリリースは、Solanaにとって新たな節目です。ネットワークパフォーマンス、バリデータ運用、開発者体験の向上を目的とした多くのアップグレードが導入されます。

Agave 3.0の主なアップデート

• キャッシュの全面刷新：トランザクション処理を30〜40%高速化
• 単一アカウントのコンピュート上限引き上げ：単一アカウントの上限をブロックCUの40%に引き上げ
• 新しいスケジューラ用TransactionView構造体：スケジューリング効率を向上
• Turbine向けeXpress Data Path（XDP）： 1億CUブロックの前提条件
• CPIネスト深度の引き上げ：CPIのネスト上限を4から8に引き上げ
• エントリ制約の緩和：スケジューリングロジックを簡素化し、非同期実行を可能にするために必要
• 起動時間の短縮： ノードがより迅速にオンラインへ復帰
• ロード済みトランザクションデータサイズの仕様化： ロード済みトランザクションデータの計算方法を標準化
• RPCの改善： PubSub WebSocketsを使用するdAppに、より高速で信頼性の高いリアルタイム更新を提供

この記事の各セクションは独立しているため、読者は自分に最も関係のあるトピックに集中できます。バリデータ運用者、開発者、活発なコミュニティメンバーのいずれであっても、このAgave v3.0ガイドから最新の改善を最大限に活用するために必要な主要アップデートと知見を得られます。

クライアント関連のトレンド

Agave v3.0の新機能を詳しく見ていく前に、最近のデータからSolanaネットワークとAgaveクライアントの進展を確認します。リリースサイクルの高速化、クライアント採用の拡大、高負荷時の堅牢なパフォーマンスが示されています。

Agaveのリリース頻度

Anzaは今年、リリース頻度を大幅に高め、Agaveのマイナーバージョン間の期間を3か月未満に短縮しました。Agave 2.2.*シリーズが超多数派バージョンであった期間はわずか11週間で、Agave 2.3も同様のペースで推移しています。

マルチクライアントネットワーク

ここ数か月で、メインネットにおけるFiredancerの採用は大きく進みました。現在、ステークの21.6%がJito-Frankendancerクライアントを実行しており、この割合は年間を通じて緩やかかつ着実に増加しています（下のグラフを参照）。Firedancerの完全版クライアントがメインネットへの本番デプロイに対応するまでは、採用率は20%前後にとどまると予想されます。

これは、ネットワークの安全性、ライブネス、レジリエンスの向上を目指すSolanaの長年の目標である、マルチクライアント戦略にとって重要な節目です。クライアントの多様性が高まることで、バリデータ運用者の選択肢が増え、クライアントチーム間の健全な競争が促進され、より多くの人がクライアントのコードベースを精査するようになります。また、単一の重大なバグによってネットワーク全体が停止するリスクも軽減されます。

Jitoなどのサードパーティ製MEV変更を含まない、標準のAgaveクライアントを実行するステークが、年初の約6%から現在は約2%まで減少した点も注目に値します。一方、Paladin-Agaveの採用はここ数か月で増加し、現在では総ステークの約6%を占めています。

ネットワークストレステスト

10月10日、暗号資産市場では史上最大規模の清算イベントが発生し、主要なブロックチェーン全体で極端なボラティリティが引き起こされました。ネットワークアクティビティが記録的に急増したにもかかわらず、SolanaネットワークとAgaveバリデータクライアントは、高負荷下で卓越したレジリエンスと安定性を示しました。

ピーク時には、Solanaは通常の6倍のトラフィックを維持し、リーダーは毎秒約100,000件のトランザクションパケットを取り込み、同時に6,000万CUの上限までフルブロックを生成しました。

このような状況でも、Solanaは1桁高いスループットを処理しながら、主要ネットワークの中で最も安定した手数料動向を示しました。実質TPS（投票以外のトランザクション）は、アクティビティのピーク時に3,200を超えました。

約2時間のピーク期間中、Solanaのトランザクション手数料中央値（P50）はわずか0.007ドル、つまり1セント未満までしか上昇しませんでした。平均手数料は一時0.10ドルに達し、上位1%のトランザクション（P99）でもピークは1.00ドルをわずかに上回る程度でした。このパターンはローカル手数料市場の有効性を示しています。高額な手数料は競合の激しいホットアカウントを操作するトランザクションに限定され、単純な送金（例：ステーブルコイン決済）を行う一般ユーザーには影響がありませんでした。

比較すると、同じ期間にEthereumメインネットとArbitrumでは、トランザクションあたりの手数料中央値が一時100ドルを超えました。Coinbaseが運営するL2のBaseでも手数料が急騰し、中央値はピーク時に3ドルを超えました。これらのネットワークにはローカル手数料市場がなく、ネットワークの高負荷時にはグローバルな手数料調整が適用され、すべてのユーザーのコストが一律に上昇します。

ステートの増加

Solanaは最近、オンチェーンステートの増加における大きな節目を迎え、アカウント総数が10億を超えました。これらのアカウントの約67%はToken Programが所有しており、そのうち89.45%が関連付けられたトークンアカウント、10.55%がトークンミントアカウントです。

このようにステートが継続的に増加することは、Solanaクライアントやインフラプロバイダーに長期的な影響を及ぼします。アカウント数の増加に伴い、ストレージ、スナップショットサイズ、アカウントのインデックス作成に対する需要も高まり、パフォーマンスやハードウェア要件に影響する可能性があります。ZK Compressionのようなソリューションは、ステートの肥大化を抑える有望な長期的アプローチです。

Agave 3.0リリースサイクルのアップデート

キャッシュの全面刷新

Agave 3.0では、ランタイムの重複処理が大幅に削減されます。プログラムキャッシュの全面刷新により、トランザクションバッチごとに数百回発生していた不要なアカウント参照が解消され、社内ベンチマークではトランザクション処理が約30〜40%高速化しました。

アカウント上限をブロックCUの40%に引き上げ

Agave 3.0のリリースサイクルの一環として、SolanaはSIMD-0306：アカウントCU上限の引き上げを有効化します。これにより、アカウントごとのCU上限が固定値の1,200万から、ブロックCU上限の40%に引き上げられます。現在、各アカウントが1ブロックあたりに消費できるのは最大1,200万CUです。以下のAnzaのグラフが示すように、競合が最も激しいアカウントはこの上限に頻繁に達しています。

この変更により、アカウントごとの上限はまず1,200万CUから2,400万CUへ引き上げられ、SIMD-0286（1億CUブロック）が有効化されると、最終的に4,000万CUになります。P-token programの導入などのアップデートと組み合わせることで、このアップグレードは各ブロック内で頻繁にアクセスされるホットアカウントのスループットを大幅に向上させます。

以下を含むその他の制約は変更されません。

• 最大投票ユニット： 1ブロックあたりの投票トランザクションCU総数の上限で、3,600万CU
• ブロックあたりのアカウントデータサイズ差分の上限： 1ブロックあたりのアカウントデータ変更量の上限で、100メガバイト。

アカウントごとのCU上限を引き上げることでホットステートのスループットは向上しますが、最悪時の直列実行時間が増え、高負荷時にはブロック検証時間やスロット時間が長くなる可能性もあります。

最後に、最近提案されたSIMD-0370：コンピュートユニットのブロック上限撤廃にも注目する価値があります。これはCUベースのブロック上限を完全に撤廃する可能性を検討するもので、Alpenglowアップグレード後に再検討される可能性が高い方向性です。

Turbine向けeXpress Data Path（XDP）

eXpress Data Path（XDP）は、高性能ネットワーク向けに設計されたLinuxカーネル技術です。アプリケーションがカーネルの標準的なパケット処理経路の大部分を迂回できるため、中間データのコピーとユーザー空間・カーネル空間間のコンテキストスイッチの両方を削減できます。ユーザー空間でネットワークインターフェースカード（NIC）と直接パケットを処理することで、XDPはパケットごとのオーバーヘッドを大幅に削減します。

TurbineでのXDPサポートはAgave v2.3.8で初めて導入され、Agave 3.1からデフォルトで有効になります。ブロック上限が1億CUに増加するにつれ、Turbineがスケーラビリティ上の主なボトルネックになります。リーダーはshredを200のピアに中継するため、大きなネットワーク負荷が発生します。リーダースロットが多い大規模バリデータでは、現在の条件下で送信パケット数が毎秒150,000件近くに達する場合があります。XDPはこのボトルネックに直接対処し、パケット送信を最大100倍高速化します。これにより、バリデータはより大きなブロックをはるかに効率よく伝播できます。

AgaveにおけるXDP実装をさらに詳しく知りたい方は、バリデータのセットアップガイドと、XDPのAgaveクライアントへの統合を主導したAnzaのエンジニアAlessandro Decina氏への以前のインタビューをご覧ください。

ロード済みトランザクションデータサイズの仕様化

Solanaの実行モデルを簡素化し標準化する継続的な取り組みの一環として、SIMD-0186：ロード済みトランザクションデータサイズの仕様が、Agave 3.0のリリースサイクル中にメインネットで有効化される予定です。

これにより、各トランザクションがロードするアカウントデータの合計を計算する、コンセンサス上安全な方法が導入されます。目的は、すべてのバリデータクライアントが同一のトランザクションデータサイズを計算するようにし、コンセンサスの分岐を引き起こし得る微妙な不整合を排除することです。

現在、Solanaのトランザクションデータサイズ算出ロジックは過度に複雑です。既存の実装ではLoaderV3とBPF Upgradeable Loaderプログラムの処理方法が特異で、いずれもロード済みプログラムデータの実際のサイズを過小計上することがよくあります。こうした不一致により、独立したクライアントチームが互換性のあるロジックを実装することは困難でした。

SIMD-0186では、サイズ算出ルールが明確になり、簡単に理解できるようになります。

• ロードされた各アカウントは正確に1回だけカウントされます
• BPF Upgradeable Loaderを使用するプログラムには、関連するプログラムデータが含まれます
• ロードされた各アカウントのサイズは、トランザクション実行前のデータのバイト長に、メタデータ用の64バイトを加えたものとして定義されます
• Address Lookup Table（ALT）ごとに一律8,248バイトが加算されます

この仕様により、すべてのクライアントでトランザクションのサイズ算出が標準化され、開発者にとってトランザクションの挙動がより予測しやすくなります。

ロード済みデータサイズ上限は、トランザクションごとのCU上限と同様の役割を果たし、バリデータノードに予測可能なリソース計算を提供します。デフォルトでは、各トランザクションは最大64MBのアカウントデータをロードできます。実際にロードされるデータがそれより少ない場合でも、ロード済み32KBあたり8コンピュートユニット（CU）を消費し、基本コストは16,000CUに相当します。開発者はsetLoadedAccountsDataSizeLimit命令を使用してこの上限を下げることで、コンピュートコストを削減し、スケジューリング効率を向上できます。

新しいサイズ算出方法ではトランザクション構造に応じて異なる値が生じる可能性があるため、開発者はコンピュートバジェット命令で指定するロード済みアカウントデータサイズ上限を調整する必要がある場合があります。

スケジューラ用TransactionView構造体

Agave 3.0では、スケジューラにTransactionViewと呼ばれる新しい軽量データ構造が導入され、トランザクションの解析と処理が効率化されます。デシリアライズと複数回のメモリ割り当てが必要だった従来のSDKトランザクション型とは異なり、TransactionViewはシリアライズ済みトランザクションを直接参照できます。実際にデシリアライズすることなく、トランザクションレイアウトに関するメタデータを解析してキャッシュします。

起動時間の短縮

Agave v3.0のリリースでは、クライアントの起動パフォーマンスが引き続き改善され、バリデータとRPCの運用者にとって利便性が大きく向上します。クラッシュ、アップグレード、定期メンテナンスのいずれによる再起動でも、ノードは大幅に短い時間でオンラインに復帰できるようになりました。

スナップショットアーカイブから起動する場合、起動時間は3分30秒未満に短縮され、Agave v2.2で必要だった時間の半分以下になりました（下のグラフを参照）。起動の高速化はノードがコンセンサスに再参加するまでの時間を短縮し、ネットワークのレジリエンスとバリデータの稼働時間を直接向上させるため、重要なパフォーマンス改善です。

今後、Agave v3.1ではバックグラウンドでのアカウント検証を廃止することでこのプロセスがさらに効率化され、バリデータはリプレイ開始直後に投票を始められるようになります。

CPIネスト上限の引き上げ

SIMD-0268：CPIネスト上限の引き上げでは、Cross-Program Invocation（CPI）呼び出しの最大深度が4から8に引き上げられます。これにより、1つのトランザクション内でSolanaプログラムが他のプログラムを呼び出せる回数が実質的に2倍になります。

CPIは、あるSolanaプログラムが別のプログラムを呼び出すための仕組みです。プログラム同士が互いのロジックを基盤として構築できるようにする、Solanaランタイムの基本機能です。

無期限スワップ、スマートウォレット、クロスマージンシステムなどの複雑なオンチェーンプロトコルは、ポジション、清算、リスクを管理するために、複数階層のプログラム間連携に依存することがよくあります。従来の4階層というCPI上限はこうした設計を制約し、場合によっては開発者がロジックを複数のトランザクションに分割する必要がありました。

既存のアプリケーションは、以前と同様に引き続き動作します（トランザクションを失敗させるためのロジックが旧上限に依存している場合を除きます）。全体として、この要望の多かった変更により開発者の設計の可能性が広がり、Solanaのコンポーザビリティが強化されます。

エントリ制約の緩和

Agave 3.0で有効化される予定のSIMD-0083：エントリ制約の緩和では、ブロックエントリ内のトランザクションが互いに競合してはならないというルールが廃止されます。従来は、競合するトランザクション、つまり同じアカウントに両方が書き込む場合や、一方が読み取り中に他方が書き込む場合を含むエントリがあると、ブロック全体が無効になっていました。

今回のアップデートにより、このような競合が許可されます。競合が発生した場合、トランザクションは出現順に直列実行されます。この変更によりブロックのパッキングルールが簡素化され、リーダーはトランザクションの順序付けとブロック構築をより柔軟に行えるようになります。また、Solanaが非同期実行を実装するためにも必要な変更です。

RPCの改善

Agave v3.0では、サブスクリプションサーバーの応答性が向上します。送信通知よりも、サブスクリプションリクエストやPINGなどの受信メッセージが優先されるようになりました。この変更により、PubSub WebSocketsを使用するdAppへ、より高速で信頼性の高いリアルタイム更新を提供できます。

さらに、エポック報酬のエラーデータにスロットプロパティが追加され、開発者向けのデバッグ性とオブザーバビリティが向上しました。

その他の変更

• Agave v3.0.0以降、Anzaはビルド済みのagave-validatorバイナリの公開を終了しました。バリデータ運用者は、提供されているビルド手順に従い、ソースからバイナリをコンパイルする必要があります。
• Agave v3.0では、デフォルトのスナップショット間隔が100,000スロットごとに延長されました。v2.3では50,000、v2.2では25,000でした。間隔を広げることでディスクパフォーマンスが大幅に改善し、スナップショット作成時のIOPS（1秒あたりの入出力処理数）の急増が抑えられます。
• 非推奨となっていた多数の古いCLI引数とフラグが削除されました（完全な一覧はこちら）。
• 現在、トランザクション内のadvance nonce命令では、そのトランザクション内の任意のアカウントを更新対象として指定できます。SIMD-0242：静的Nonceアカウントのみのフィーチャーゲートが有効化されると、advance nonce命令は静的に含まれているアカウントのみを更新できるように制限されます。

まとめ

Agave v3.0は大規模なクライアントアップグレードです。トランザクション処理の高速化、コンピュート上限の引き上げ、スケジューラ効率の改善に加え、バリデータとRPCに関するさまざまな最適化が導入されます。これらのアップデートにより、ネットワークパフォーマンスと開発者体験の両方が強化されます。

最近のデータも、この進展を裏付けています。リリース頻度の向上、クライアントの多様化、ピーク需要下での卓越したネットワーク安定性は、いずれもSolanaの成熟を示しています。Agave 3.0がネットワークを支えるようになった今、Solanaはスケールできる能力を引き続き実証しています。

関連リソース

• Agave 3.0リリーススケジュール
• フィーチャーゲートトラッカーのスケジュール
• Agave 3.0変更履歴
• Agave 3.0プルリクエスト