Agave 3.0アップデート: 知っておくべきすべて

この作業の以前のバージョンをレビューしてくれた0xIchigoとBrian Wongに多大な感謝を。
紹介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のマルチクライアント戦略にとって重要なマイルストーンです。長年の目標であり、ネットワークの安全性、ライブネス（稼働性）、およびレジリエンスを改善することを狙っています。クライアントの多様化は、バリデータ運用者により多くの選択肢を提供し、クライアントチーム間で健全な競争を促し、クライアントのコードベースに目がより多く向けられるようになります。さらに、単一の致命的なバグがネットワーク全体の障害につながるリスクを軽減します。
また、バニラのAgaveクライアント（JitoのようなサードパーティのMEV改変を含まないAgave）を実行しているステークが、年初の約6%から今日ではおよそ2%へと減少している点も注目に値します。一方で、Paladin-Agaveの採用はここ数か月で増えており、現在は全ステークの約6%を占めています。
ネットワーク負荷テスト10月10日、暗号資産市場は史上最大の清算イベントを経験し、主要なすべてのブロックチェーンで極端なボラティリティが引き起こされました。ネットワーク活動が記録更新となる急増を見せたにもかかわらず、SolanaネットワークとAgaveバリデータクライアントは、プレッシャー下でも驚くほどの耐性と安定性を示しました。
ピーク時、Solanaは通常の6倍のトラフィックを維持し、リーダーが毎秒約100,000トランザクション・パケットを取り込みながら、60百万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億（1,000,000,000）を超えました。これらの口座の約67%はトークンプログラムに所有されており、そのうち89.45%はトークンアカウント、10.55%はトークンミントアカウントです。
このような状態（ステート）の着実な拡大は、Solanaのクライアントやインフラ提供者にとって、より長期的な影響を及ぼします。口座数が増えるほど、ストレージ需要、スナップショットサイズ、そしてアカウントのインデックス作成への負荷も増大し、パフォーマンスやハードウェア要件に影響を与え得ます。ZK Compressionのような解決策は、ステートの肥大（ステート・バルジ）を抑えるための有望な長期的な道筋を提供します。
Agave 3.0リリースサイクルの更新キャッシュの刷新Agave 3.0は、冗長なランタイム処理を大幅に削減します。プログラムキャッシュの完全な刷新により、トランザクションバッチごとに行われていた数百に及ぶ不要なアカウント参照がなくなり、内部ベンチマークでは約30〜40%高速なトランザクション処理が実現しています。
口座上限をブロックCUの40%に引き上げAgave 3.0リリースサイクルの一環として、SolanaはSIMD-0306：Raise Account CU Limitsを有効化します。これにより、口座ごとのCU上限が、静的な固定定数12Mから、ブロックCU上限の40%へ引き上げられます。現状では、各アカウントは1ブロックあたり最大1200万CUsまで消費できます。Anzaが示すとおり、最も激しく競合する口座はしばしばこの上限に到達します。
この変更により、口座（アカウント）ごとの上限は当初12百万CUsから24百万CUsへ引き上げられ、さらにSIMD-0286（100M CUブロック）が有効化されると最終的に40百万CUsになります。P-tokenプログラムの導入などのアップデートと組み合わせることで、各ブロック内で頻繁にアクセスされる“ホット口座”のスループットが大幅に向上します。
他の制約は次のとおり変更されません：
最大投票ユニット：ブロックあたりの総投票トランザクションCUsの上限である36百万CUs
最大ブロック口座データサイズ差分：ブロックあたりの口座データ変更の総量の上限である100メガバイト。
口座ごとのCU上限を引き上げてホット状態のスループットを改善しても、最悪ケースの直列化された実行時間が増える可能性があり、高負荷シナリオではブロック検証やスロットの所要時間が長くなるかもしれません。
最後に、最近の提案SIMD-0370：Compute Unit Block Limitを削除は、CUベースのブロック上限を完全に排除することを検討するもので、Alpenglowアップグレード後に再検討される可能性が高い方向性です。
Turbine向けeXpress Data Path（XDP）eXpress Data Path（XDP）は、高性能ネットワーキング向けに設計されたLinuxカーネル技術です。これにより、アプリケーションはカーネル標準のパケット処理経路の大部分をバイパスでき、ユーザー空間とカーネル空間の間の中間データコピーやコンテキストスイッチの両方を削減します。ユーザー空間でネットワークインターフェースカード（NIC）を直接扱うことで、XDPはパケットあたりのオーバーヘッドを劇的に削減します。
TurbineでのXDP対応は、Agave v2.3.8で初めて導入され、Agave 3.1からデフォルトで有効化されます。Turbineは、ブロック上限が100M CUsへ増加するにつれてボトルネックになる主要コンポーネントです。リーダーはshredを200のピアへ中継し、大きなネットワーク負荷を生みます。現状の条件では、リーダー枠が多い大規模バリデータは、毎秒最大150,000件の送信パケットに迫ることができます。XDPはこのボトルネックに直接対処し、パケット配送を最大100倍高速化して、バリデータがより大きなブロックをはるかに効率よく伝播できるようにします。
AgaveにおけるXDP実装をより深く知りたい読者は、バリデータセットアップガイドと、AnzaのエンジニアであるAlessandro Decinaによる、以前のインタビューを参照できます。DecinaはAgaveクライアントへのXDP統合を主導しました。
ロード済みトランザクションデータサイズ仕様Solanaの実行モデルを簡素化し標準化するための継続的な取り組みの一環として、SIMD-0186：Loaded Transaction Data Size Specificationは、Agave 3.0リリースサイクル中にメインネットで有効化されるよう設定されています。
これにより、各トランザクションがロードする合計アカウントデータを計算するための、コンセンサスに安全な手法が導入されます。狙いは、すべてのバリデータクライアントが同一のトランザクションデータサイズを計算し、そうでなければコンセンサスが分岐してしまう可能性のある些細な不整合を排除することです。
現在のSolanaのトランザクションデータのサイズ決定ロジックは過度に複雑です。既存の実装はLoaderV3およびBPFアップグレーダブル・ローダープログラムの扱いが独特で、これらはいずれもロードされたプログラムデータの実際のサイズをしばしば過小に見積もります。このような不一致があったため、独立したクライアントチームが互換性のあるロジックを実装するのが難しくなっていました。
SIMD-0186のもとで、サイズ決定ルールは明確で、理解しやすくなっています：
ロードされた各口座はちょうど1回だけカウントされる
BPFアップグレーダブル・ローダーを使用するプログラムには、関連するプログラムデータが含まれる
各ロード済み口座のサイズは、トランザクション実行前のデータのバイト長で定義され、さらにメタデータとして64バイトが追加される
アドレス・ルックアップ・テーブル（ALT）はそれぞれ固定で8,248バイトを追加
この仕様は、すべてのクライアントにわたるトランザクションのサイズ決定を標準化し、開発者にとってトランザクションの挙動をより予測可能にします。
ロード済みデータサイズの上限は、トランザクションごとのCU上限に似た役割を果たし、バリデータノードに対して予測可能なリソース会計を提供します。デフォルトでは、各トランザクションは最大64MBの口座データをロードでき、32KBロードごとに8つの計算ユニット（CUs）を消費します。これは実際にロードされるデータが少なくても、基礎コスト16,000 CUsに相当します。開発者は、setLoadedAccountsDataSizeLimit命令によってこの上限を下げ、計算コストを削減し、スケジューリング効率を向上させることができます。
新しいサイズ決定方式はトランザクション構造に基づいて異なる値を生成し得るため、開発者は計算予算（compute budget）命令内で指定しているロード済みアカウントデータサイズ上限を調整する必要があるかもしれません。
スケジューラ TransactionView 構造体Agave 3.0では、スケジューラがTransactionViewという新しい軽量データ構造を導入します。これは、トランザクションの解析と処理の方法を合理化するために設計されています。従来のSDKのトランザクション型は逆直列化と複数のメモリ確保を必要としましたが、TransactionViewは直列化されたトランザクションへの直接的なビューを提供します。実際には逆直列化を行わずに、トランザクションのレイアウトに関するメタデータを解析してキャッシュします。
起動時間の短縮クライアントの起動パフォーマンスはAgave v3.0リリースによって引き続き改善されています。これは、バリデータおよびRPCオペレーターにとって注目すべきQOL（生活の質）向上です。クラッシュ後、アップグレード後、あるいは計画メンテナンス後であっても、ノードは以前より大幅に高速にオンラインに復帰できます。
スナップショットアーカイブから開始する場合、起動時間は3分半未満まで短縮されました。これはAgave v2.2で必要だった時間の半分以下です（下の図を参照）。起動が速くなることは、ノードが合意に再参加するまでの時間を短縮し、ネットワークのレジリエンスとバリデータの稼働率を直接高めるため、重要なパフォーマンス向上です。
今後は、Agave v3.1でさらにこのプロセスが合理化され、バックグラウンドでのアカウント検証がなくなることで、リプレイ開始後にバリデータがすぐ投票を開始できるようになります。
CPIネスト上限の引き上げSIMD-0268：CPIネスト上限の引き上げは、Cross-Program Invocation（CPI）呼び出しの最大深度を4から8へ増やします。これは実質的に、単一トランザクション内でSolanaプログラムが他のプログラムを呼び出せる回数を2倍にします。
CPIは、あるSolanaプログラムが別のSolanaプログラムを呼び出す仕組みです。これはSolanaの実行環境（ランタイム）における基盤となる機能で、プログラムが互いのロジックの上に積み重ねて構築できるようにします。
無限スワップ、スマートウォレット、クロスマージンのような複雑なオンチェーン・プロトコルでは、ポジション、清算（リキディエーション）、リスクを管理するために、複数層のプログラム相互作用に依存することがよくあります。従来の4レベルのCPI制限は、こうした設計を制約し、場合によってはロジックを複数のトランザクションに分割せざるを得ない状況を生んでいました。
既存のアプリケーションは以前と同様に動作し続けます（ただし、ロジック内で古い上限に依存してトランザクションを失敗させる場合を除きます）。総じて、この頻繁に求められていた変更により、開発者にとっての設計空間が広がり、Solanaの合成可能性（composability）が強化されます。
エントリー制約を緩和SIMD-0083：エントリー制約の緩和は、Agave 3.0で有効化される予定で、ブロック内のエントリーに含まれるトランザクション同士が互いに競合してはならない、というルールを削除します。以前は、競合するトランザクションを含む（つまり、同じアカウントへ書き込むトランザクション同士、または一方が読み、別の一方が書くような組み合わせの）エントリーは、ブロック全体を無効化していました。
この更新により、そのような競合が許可されます。競合が発生した場合、トランザクションは単に、表示されている順に直列に実行されます。この変更により、ブロックのパッキング規則が簡素化され、リーダーはトランザクションの順序付けやブロック構築においてより大きな自由度を得ます。これはまた、Solanaが非同期実行を実装するために必要な変更でもあります。
RPCの改善Agave v3.0では、サブスクリプションサーバーの応答性向上が導入されます。サブスクリプション要求やPINGのような、受信メッセージを送信通知より優先するようになります。この変更により、PubSub WebSocketsを利用するdApps向けのリアルタイム更新がより高速で、より信頼性の高いものになります。
さらに、スロット特性がエポック報酬のエラーデータに追加され、開発者のデバッグ性と観測性が向上します。
その他の変更Agave v3.0.0から、Anzaは事前ビルド済みのagave-validatorバイナリの公開を中止しました。バリデータ運用者は、提供されているbuild instructionsに従って、ソースからバイナリをコンパイルする必要があります。
Agave v3.0では、デフォルトのスナップショット間隔が、v2.3の50,000およびv2.2の25,000から、100,000スロットごとへ延長されています。間隔を大きくすることで、ディスク性能が大幅に改善し、スナップショット作成中のIOPS（1秒あたりの入出力操作）のスパイクが減少します。
多数の非推奨となった古いCLI引数やフラグが削除されました（完全なリストはこちら）。
現状、トランザクション内のadvance nonce命令は、advance先としてトランザクションの任意のアカウントを指定できます。SIMD-0242：Static Nonce Account Onlyの機能ゲートが有効化された後は、このadvance nonce命令は静的に含まれたアカウントに対してのみアドバンスできるようになります。
結論Agave v3.0は大規模なクライアントアップグレードであり、より高速なトランザクション処理、高い計算（コンピュート）上限、スケジューラ効率の向上、そして多数のバリデータおよびRPCの最適化が導入されます。これらのアップデートにより、ネットワークパフォーマンスと開発者体験の両方が強化されます。
最近のデータは、この進展をさらに裏付けています。より速いリリースサイクル、クライアントの多様化の進行、そしてピーク需要下でも例外的なネットワーク安定性が、Solanaの成熟を強く示しています。Agave 3.0が今やネットワークを稼働させていることで、Solanaはスケールできる能力を継続して証明しています。