Agave v2.3アップデート：知っておくべきことのすべて

はじめに

Agaveバリデータクライアントのv2.3リリースは、Solanaにとって新たな大きな進歩です。これまでのアップデートと同様に、この新バージョンでもネットワーク性能と開発者体験の両方を向上させるための重要な改善が導入されています。

Agave 2.3の注目すべきアップデート 

• 新しいTPUクライアント tpu-client-next
• ディスクI/O使用量を削減するAccountsDBの最適化
• バリデータの投票アカウントをキーとするリーダースケジュール
• スラッシュ対象イベントの検証
• グリーディスケジューラをデフォルトで有効化
• スナップショットの強化
• gossipのアップグレード
• エポック移行の高速化

この記事の各セクションは独立しているため、読者は自分に最も関係するトピックへ簡単に移動できます。バリデータ運用者、開発者、積極的なユーザーのいずれであっても、このAgave 2.3の包括的なガイドから、最新の改善を最大限に活用するために必要な重要情報を得られます。

AnzaはAgaveのリリースペースを加速させています。2.2のリリースから3か月も経たないうちにバージョン2.3がすでに稼働しており、現在は総ステークの13%が新しいクライアントの各バージョンを実行しています。今後数週間で導入が急速に進むと予想されています。その間、メインネットの機能ゲート有効化はロールアウト中、一時的に停止されていますが、計画された有効化シーケンスの一環として近日中に再開されます。

新しいTPUクライアント

Agave 2.3では、従来のConnectionCacheに代わり、Transaction Processing Unit（TPU）クライアントの新しい実装が導入されました。このTPUクライアントは、QUICプロトコルを使用して、シリアライズされたトランザクションをネットワーク経由でバリデータへ送信します。tpu-client-nextと呼ばれる新設計は、性能の大幅な向上、リソース使用量の削減、アーキテクチャ全体の簡素化を目的とした全面的な刷新です。

TPUクライアントは、主に2つのシナリオで使用されます。1つは、バリデータが次のリーダーへトランザクションを転送するForwardingStageです。もう1つは、RPCがリーダーへトランザクションを中継するために使用するSendTransactionServiceです。

以前の実装であるConnectionCacheは、UDPとQUICの両方のプロトコルをサポートするよう構築されていたため、不必要に複雑でした。ConnectionCacheは、明示的なチャネルではなく内部の非同期キューにトランザクションを保存し、空のパケットを送信するキャッシュウォームアップロジックも備えていました。また、Quinn（QUICのRust実装）のエンドポイント管理に関する問題が継続的に発生していました。

新しいtpu-client-nextは、効率化された非同期設計によってこれらの問題を解決します。内部ではエージェントベースのモデルを採用し、個別のワーカータスクが各QUIC接続を処理します。これらのワーカーは、非同期チャネルを使用して中央のConnectionWorkersSchedulerと通信します。 

スケジューラがトランザクションのバッチを受信すると、設定された戦略に従って適切なワーカー群へブロードキャストします。このアーキテクチャではマルチストリーミングが完全に排除され、トラフィックの断片化が軽減されます。また、接続が事前に確立されるため、送信時に新しいストリームを開く際のレイテンシも解消されます。

tpu-client-nextは明確な性能向上を示しています。 

• テストネットのRPC実験では、負荷時に旧クライアントと新クライアントが同程度の平均TPSを達成しましたが、tpu-client-nextではジッターが明らかに低下しました。 
• バリデータのユースケースでは、ForwardingStageによる転送トランザクション量が10%増加し、トラフィックパターンがより安定したほか、CPU使用量が30%減少しました。
• Anzaのクローズドソースのストレステストツールであるtransaction-bench,は、最新クライアントを使用して構築されています。従来のベンチテストツールであるbench-tpsと比べ、1秒あたり2倍のトランザクションを生成します。

tpu-client-nextは完全な後方互換性を備え、現在はAgaveノードのデフォルト実装となっています。問題が発生した場合、運用者は**--use-connection-cache**フラグを指定してノードを起動することで、以前の実装に戻せます。

まとめると、tpu-client-nextには次の利点があります。

• 非同期処理に適したエージェントベースのアーキテクチャ
• ジッターを抑えた安定したトラフィック
• CPUとメモリの使用量削減
• 設定可能なスケジューリングおよびキューイングポリシー
• 統合の簡素化と、より明快なAPIサーフェス

投票アカウントをキーとするリーダースケジュール

Agave 2.3のリリースサイクルの一環として、SolanaはSIMD-0180：投票アカウントアドレスをリーダースケジュールのキーとして使用を有効化します。この変更により、ブロック生成を担当するバリデータをネットワークが決定する方法が変わります。リーダースケジュールの主キーが、バリデータのIDアドレスから投票アカウントアドレスへ移行します。

この移行は、Solanaプロトコルに長年存在していた曖昧さを解消します。具体的には、ブロックを生成したバリデータと特定のステークを確実に関連付けられないという問題です。現在の設計では、リーダースケジュールはバリデータのIDアドレスをキーとしています。しかし、複数の投票アカウントが同じバリデータIDへ委任できるため、特定のスロットで生成されたブロックを、特定の委任ステーク群まで追跡することが困難です。

代わりに投票アカウントアドレスをリーダースケジュールのキーとすることで、委任ステークとバリデータのリーダー役割の間に明確で直接的なつながりが確立されます。一見小さな変更ですが、これにより複数の重要な機能が実現可能になります。

第一に、3月の正式なガバナンス投票で可決されたSIMD-0123の規定に基づく、ブロック報酬分配に必要な基盤が整います。これにより、バリデータはブロック手数料にコミッション率を設定し、残りの収益を委任者に比例配分できます。このシステムは、インフレ型ステーキング報酬ですでに使用されている報酬共有モデルを踏襲し、バリデータとステーカー間の経済的インセンティブをより一致させます。

第二に、投票アカウントアドレスをリーダースケジュールのキーとして使用することは、プログラムによるスラッシングを可能にするために不可欠です。これは、重複ブロックを送信したり、複数のフォークに投票したりしてネットワークルールに違反したバリデータへペナルティを科す仕組みです。次のアップデートは、まさにこの点に関するものです。

スラッシュ対象イベントの検証

スラッシングは、不正行為をオンチェーンで検証し、委任されたステークの一部をバーンすることで、悪意あるバリデータにペナルティを科す仕組みです。ネットワークのセキュリティや安定性を脅かす行為に対する重要な抑止力となります。

スラッシングには、主に2つのモデルがあります。

ソーシャルスラッシング（Solanaの現行システム）

Solanaは現在、ソーシャルスラッシングと呼ばれる、コミュニティ主導の手動コンセンサス方式を採用しています。このモデルでは、バリデータがネットワークのライブネスや安全性を損なうなどの悪意ある行動を取った場合、誠実な参加者がオフチェーンで連携してハードフォークを開始し、ネットワークを再起動して違反者のステークをスラッシュできます。この方法ではケースごとに柔軟な判断が可能ですが、多大な調整コストがかかり、本質的に事後対応となります。

プログラムによるスラッシング（プロトコル内スラッシング）

対照的に、プログラムによるスラッシングは完全にオンチェーンで実行されます。バリデータがプロトコルルールに違反した場合、その違反を示す暗号学的証明を専用プログラムへ提出でき、その後スラッシングが自動的に発動します。このモデルは人間による調整への依存を減らし、ネットワーク運用を中断せずに軽微な違反も取り締まれるため、拡張性のある分散型の説明責任への道を開きます。

スラッシングには2つの重要なステップがあります。

• 障害の検出と帰属： 不正行為と、その責任を負うバリデータを特定します。
• ペナルティの執行： 違反者のステークをスラッシュし、責任を負わせることで経済的な罰を科します。

Agave 2.3のリリースサイクルの一環として、SolanaはSIMDで説明されているSlashing Programの機能ゲートを有効化する予定です。SIMD-0204：スラッシュ対象イベントの検証。これはSolanaでプログラムによるスラッシングを可能にするための第一歩であり、障害の検出と帰属に重点を置いています。誰でもスラッシュ対象の行為を報告・記録できるオンチェーンプログラムを導入し、将来の自動執行に向けた基盤を整えます。

このプログラムはステークや報酬を変更せず、違反の検証と記録のみを行います。これにより、バリデータの不正行為がオンチェーンに記録されます。初期のプログラムプロトタイプはTestnetにデプロイされています（例：DuplicateBlockProofトランザクションのサンプル）。 

このプログラムは当初、重複ブロック生成の検出と記録に重点を置き、将来的には二重投票など、ほかの違反にも対応する予定です。重要なのは、プログラムによるスラッシングの対象が、明確に証明できる不正行為に限定されることです。そのため、意図的に遅いブロック生成やMEV抽出など、より主観的またはシステム的な問題の執行は格段に難しく、スラッシングプログラムで対処される可能性は低いと考えられます。

提出される証明には、同じスロットに対する2つの競合するshredが含まれ、どちらも同じバリデータによって署名されています。スラッシングプログラムは、shredが有効な重複ブロック証明を構成していること、同じスロットに属すること、違反したバリデータによって正しく署名されていることを確認して証明を検証します。このロジックは、Solanaのgossipプロトコルがフォーク選択プロセスで重複ブロック証明を処理する際のアプローチを踏襲しています。 

証明が正常に検証されると、結果は将来参照できるようProgram-derived Address（PDA）に保存されます。これにより、スラッシングプログラムに対してgetProgramAccountsを実行するだけで、スラッシング関連データを表示するダッシュボードを簡単に構築できます。バリデータはこの機能を使用して、違反が報告されているか確認し、必要に応じて是正措置を講じられます。

将来のSIMDでは、各種違反に対するステークペナルティなどのパラメータを含め、スラッシングの経済的執行に対応します。これらの決定はSolanaバリデータ運用の経済性に影響するため、変更案はすべて正式なガバナンス投票による承認が必要です。

エポック移行の高速化

Agave 2.3では、エポック移行の速度が大幅に向上しています。エポック報酬の計算が500ミリ秒未満で完了するようになりました。その結果、スキップされるスロットが減少し、エポック境界付近でトランザクションがより確実に取り込まれます。

さらに、新しいエポックの最初のリーダースロットがスキップされた場合でも、Agave 2.3では報酬計算が再実行されません。代わりに以前の計算結果が再利用されるため、重複計算がなくなり、新しいエポックをよりスムーズに開始できます。

AccountsDBの最適化

このリリースでは、ストレージ効率が大幅に向上しました。ディスクI/O使用量は約75%減少し、リペアリクエストの量は約85%削減されています。これらの最適化により、特にネットワーク負荷が高い時間帯でも、ノードの性能がより安定し、信頼性が向上します。

グリーディスケジューラをデフォルトで有効化

Agave 2.3では、グリーディスケジューラがデフォルトで有効になりました。以前の中央スケジューラは、トランザクションのソートと依存関係グラフの構築に時間がかかるため、高いネットワーク負荷の下でボトルネックになることがよくありました。新しいグリーディ方式では、ロジックの簡素化とバッチサイズの縮小により、トランザクションのスケジューリングが大幅に高速化されます。

グリーディスケジューラの詳細については、以前のHeliusブログ記事をご覧ください。

Gossip Shredバージョン

Agave 2.3では、gossipネットワークにおけるshredバージョン一致の適用が厳格化されました。ノードは、自身のshredバージョンがクラスターのバージョンと一致する場合にのみ、受信gossip接続を確立できるようになりました。これにより、設定を誤ったノードを早期に排除できます。

以前は、スパイノードがクラスターのshredバージョンと一致していなくてもネットワークに参加できました。この変更により、スパイモードのノードを含むすべてのノードは、クラスターのエントリーポイントから取得するか、コマンドラインで明示的に設定することで、正しいshredバージョンを取得する必要があります。

このアップデートは、gossipのオーバーヘッドを削減する最近の取り組みをさらに進めるものです。ここ数か月で、3種類のgossipメッセージが非推奨となり、ステークのないバリデータによるエポックスロット通知が廃止されたことで、受信gossipトラフィックが約61%減少しました。

RPCシミュレーションにリソース使用量を追加

トランザクションのリソース使用量を把握しやすくするため、デフォルトの`simulateTransaction` RPCメソッドに新しいフィールド、`loadedAccountsDataSize`が追加されました。このフィールドは、シミュレーション中に読み込まれたアカウントデータの総バイト数を報告します。

この追加により、開発者はトランザクションコストを見積もり、優先手数料をより正確に調整できます。アカウントデータの読み込みではコンピュートユニット（CU）が消費されます。消費率は32 KBあたり8 CUで、Solanaのヒープページ割り当てサイズに基づいています。この指標が表示されることで、開発者はトランザクションの構築と送信時に、コスト効率をさらに最適化できます。

スナップショットの強化

スナップショットは定期的な保存ポイントとして機能し、ノードが状態を復元できるようにします。ノードはこれらのスナップショットを継続的に生成し、古いものを時間の経過とともに新しいバージョンへ置き換えます。

このリリースでは、スナップショットの動作に関する使い勝手が複数改善されています。

• デフォルト間隔の更新： フルスナップショットのデフォルト間隔が25,000スロットから50,000スロットに延長され、スナップショットの作成頻度が減少しました。
• スナップショットを無効化する新しいフラグ： スナップショット生成を明示的に無効化する新しい`--no-snapshots`フラグが導入されました。従来の`--snapshot-interval-slots 0`を使用する方法は非推奨となりました。
• Geyserの動作改善：スナップショットから復元する際、Geyserを通じて送信されるアカウント通知の重複排除が行われなくなりました。

スナップショット間隔の延長には、ディスク性能を安定させ、IOPSの急増を抑える（1秒あたりの入出力操作数）という追加の利点もあります。

SBPFツールチェーンの改善

Agave 2.3では、SBPFツールチェーンを使用する開発者向けに、使い勝手を向上させるアップグレードが複数導入されています。

• バージョン指定： 開発者はプログラムのコンパイル時に特定のBPF VMバージョン（v0〜v3）を明示的に指定できるようになり、制御性が向上しました。
• SBPFv3ではRustのみ： SBPFv3以降では、Rustベースのツールチェーンのみがサポートされます。従来のCツールチェーンは今後のバージョンと互換性がありません。
• 新しい最適化フラグ： デプロイ用のプログラムバイナリを小さくするため、新しい`--optimize-size`ビルドフラグが追加されました。ストレージの削減に役立ちますが、コンピュートユニット（CU）の使用量がわずかに増える可能性があります。

その他の変更

このリリースには、次の追加アップデートも含まれています。

• クラスターの自動復旧： チェーンがクラッシュした場合にクラスターの再起動を自動的に開始する、新しいクラスター復旧機能`wen-restart`が導入されました。
• ロギングABIの更新： `TimedTracedEvent`ロギングABIが更新され、新しい診断情報が追加されました。そのためバリデータは、互換性を確保するために、これらのログに依存する外部のトレーシングツールや分析ツールを更新する必要があります。形式の不一致を避けるため、アップグレード後は既存のトレースデータを消去してください。
• CLIの改善： ステークされていないすべてのlamportを簡単に引き出せるよう、withdraw-stake AVAILABLEが追加されました。また、セキュリティ向上のため、solana-test-validatorはデフォルトでRPCサービスをlocalhost（127.0.0.1）へバインドするよう更新されました。
• 起動の高速化： バリデータの起動時間が大幅に短縮されました。ノードの起動と台帳の読み込みには約3分、チェーン先端への追いつきには約5分かかるようになりました。ただし、fastbootでは新しい--wait-for-exitフラグを使用して正常にシャットダウンする必要があります。運用者は即座に再起動コマンドを実行するのではなく、再起動前にバリデータプロセスが自動的に完全終了するまで待つ必要があります。

まとめ

Agave 2.3は、Solanaプロトコルにとって新たな重要なマイルストーンです。主なポイントには、新しいTPUクライアント（`tpu-client-next`）の導入、AccountsDBの最適化によるディスクI/Oの大幅な削減、スナップショット性能の強化、gossipネットワークの改善、エポック移行と起動時間の高速化が含まれます。これらのアップデートにより、ネットワークがさらに堅牢になり、開発者とバリデータ運用者の双方にとって体験が向上します。

Solanaは堅牢なマルチクライアントネットワークに向けて着実に進歩を続けており、総ステークの8%以上がFiredancerを実行し、その割合は増加しています。約1年半にわたる中断のない稼働は、ネットワークのコアソフトウェアが成熟し、安定性が向上していることを示しています。一方で、メジャーリリースとマイナーリリースの両方が加速しています。

次はAgave 3.0です！

関連リソース

• Agave 2.3リリーススケジュール
• Agave 2.3変更履歴
• Agave 2.3プルリクエスト
• Agave 2.3パッチノート - Anzaブログ 
• tpu-client-nextプレゼンテーション - Solana Core Community Call、2025年6月20日