Agave 3.1アップデート：知っておくべきすべてのこと
本記事の以前のバージョンをレビューしてくださった0xIchigo氏とBrian Wong氏に深く感謝します。
はじめに
Solana Agaveクライアントの最新進化版、Agave v3.1が登場しました。このアップデートでは、クライアントのパフォーマンス、バリデータ運用、開発者体験を改善する幅広いアップグレードが導入されています。また、プロトコル内でのブロック報酬分配、ステートボンド（いわゆるrent）の大幅な削減、そして何より、今後予定されているAlpenglowコンセンサスアップグレードの基盤となる、複数の重要なフィーチャーゲートの有効化も含まれています。
Agave 3.1の主なアップデート
- リプレイ中のディスクI/Oを削減
- クライアントの再起動を高速化
- トランザクション処理を2倍高速化
- CPIアカウント情報の上限を引き上げ*
- バリデータ投票アカウントV4とコミッション更新の遅延*
- TurbineのChaChaラウンド数を削減*
- 新しい命令データポインタ*
- RPCの改善
* フィーチャーゲート付きアップグレード
バリデータ運用者でも開発者でも、このガイドから最新の改善を最大限に活用するために必要なアップデートと知見を得られます。本記事の各セクションは独立しているため、ご自身に最も関連するトピックに集中してお読みいただけます。
執筆時点では、Agave 3.1.8はメインネットアップグレード候補（MUC）と見なされており、Anzaはこのリリースをステークの25%まで普及させるための協力者を募集しています。バリデータの皆様、今こそアップグレードするときです。
クライアントのパフォーマンス向上
今回のAgaveメジャーリリースには、さまざまなパフォーマンス向上が含まれています。以下では、特に重要な改善点をいくつか紹介します。
リプレイ中のディスクI/Oを削減
Agave 3.1では、リプレイ中のディスクアクティビティが大幅に削減されています。以下の画像は、Agave 3.0で実際のメインネットトランザクションを処理した際の、リプレイにおける10秒間のプロファイリング結果です。ディスク操作（赤いマーカー）は1,100イベントを超えています。ディスクへのアクセスが発生するたびにI/O待機時間が生じ、バンキングとリプレイの両方にジッターが加わるため、これは問題です。
Agave 3.1では、リプレイ中のディスクI/Oが劇的に削減されています。同じ10秒間で確認されたディスク操作は80回未満で、93%の減少です。これにより、ディスクの消耗を抑えながらリプレイの安定性が向上し、ディスク寿命の延長にもつながります。
クライアントの再起動を高速化
クライアントの再起動パフォーマンスは、主にAccountsDBの最適化によって引き続き大幅に改善されています。Agave 1.*のメジャーリリースでは、再起動に30分以上かかることが一般的でした。Agave 2.*のリリースでは、これが10分未満に短縮されました。Agave 3.1では再起動時間がさらに短縮され、現在は通常1分未満です。今後、次のメジャーリリースであるAgave 4.0では再起動時間が30秒未満になると見込まれており、バリデータの稼働時間がさらに向上し、メンテナンスや予期しない障害からの復旧時間も短縮されます。
トランザクション処理を高速化
Agave 3.1には、トランザクション処理の効率を大幅に改善する重要な修正が含まれています。以前は、トランザクション処理パイプラインのバグにより、バンキングワーカーがトランザクションを実行するのではなく、Proof of Historyとの同期に過剰な時間を費やしていました。そのため、リーダーモードでは、クライアントが約61%の時間にわたってトランザクションを能動的にスケジューリングしていませんでした。
Agave 3.1でこれらの問題が解消されたことにより、バンキングワーカースレッドは現在、稼働時間の~91%をトランザクション処理に費やしています。その結果、トランザクション処理速度が2倍になり、スループットが大幅に向上するとともに、リーダー時間をより有効に活用できるようになりました。
そのほかの注目すべきパフォーマンス改善として、デフォルトでアカウントインデックス全体をメモリ内に保持する変更があります。エポック境界での遷移も大幅に改善され、2秒以上かかっていた処理が現在は400ms未満で完了するようになりました。これにより、エポック切り替え時にスキップされるスロットが大幅に減少します。
ネットワークの堅牢化
Anzaは、継続的なストレステスト、レッドチーミング、リアルタイムの状況監視を通じて、Agaveクライアントのレジリエンス向上に多大な投資を行っています。この取り組みの詳細はこれまで非公開でしたが、プログラムが十分に成熟したため、現在ではこの重要な活動を公表できるようになりました。Anzaの専任invalidatorチームは、1時間ごとに新しいテストセットを用いてSolanaの公開テストネットを積極的に攻撃しています。
テストは主に2つのカテゴリーに分類されます。1つ目は、ネットワークレイヤーでのサービス拒否シナリオに焦点を当て、極端な条件下におけるバックプレッシャー処理と負荷制御をストレステストするものです。2つ目は、Solana VMの限界を試すために設計された、異常かつ敵対的なトランザクションを含む特別なブロックを生成するテストです。
Anzaは攻撃シナリオを体系的に構築し、それに対する防御策を開発しています。この取り組みは、十分な情報と相応のステークを持つ悪意あるバリデータに何ができるのか、また十分な資金と高度な技術を持つ外部開発者が何を試み得るのかに基づいた、現実的な脅威モデルを土台としています。
この水準の備えは12月に実証されました。Solanaは数週間にわたる大規模なDDoS攻撃を耐え抜き、ピーク時には約6 Tbpsに達したと報告されています。これは、分散システムに対して記録された攻撃として過去最大級です。規模が極めて大きかったにもかかわらず、ネットワークで測定可能な影響はほとんど見られず、攻撃期間を通じて1秒未満の確認時間と安定したスロットレイテンシを維持しました。
CPIアカウント情報の上限を引き上げ
SIMD-0339：CPIアカウント情報の上限引き上げは、Agave 3.1のリリースサイクル中にメインネットで有効化される予定です。これにより、クロスプログラム呼び出し（CPI）のアカウント情報上限が64から255へと約4倍に引き上げられ、CPIを介して多数のアカウントリストを渡す必要があるプログラムを構築する開発者の長年の課題が解消されます。アカウント情報とは、CPI syscallに渡されるシリアライズ済みのアカウントメタデータであり、呼び出し先プログラムが呼び出し元から提供されたアカウントを読み取れるようにするものです。
以前は、CPIごとに渡せるアカウント情報は1回のsyscallにつき64件に制限されていました。この制約により、プログラムはCPI呼び出しの前にアカウントリストの重複を排除して再構築する必要があり、複雑さとオーバーヘッドが増加していました。実際には、DFlowやJupiterなどのDEXアグリゲーターのラッパーをはじめ、多くの実運用プログラムが日常的にこの上限を超えています。
上限の引き上げに加えて、このフィーチャーゲートでは、CPIに渡されるアカウント情報と命令アカウントの数に応じて増加するコンピュートユニットコストの変更も導入されます。これにより、プログラムがアカウント使用量を最小限に抑えるインセンティブが維持されます。
上限を引き上げるだけの変更であるため、完全な後方互換性があり、既存プログラムの動作には影響しません。
バリデータ投票アカウントV4とコミッション更新の遅延
Agave 3.1のリリースサイクル中に有効化が予定されている2つのフィーチャーゲート付きアップデートは、バリデータ運用者にとって特に重要です。1つ目はSIMD-0185：投票アカウントV4です。これは、Alpenglow、ブロック収益分配、コミッションの改善など、今後のプロトコルアップグレードを可能にする新しいバージョンの投票アカウント状態を導入します。
現在、投票アカウントに保存できるコミッション率は1つだけです。しかし、SIMD-0123：ブロック収益分配で示されている、今後のプロトコル内ブロック収益分配を実現するには、バリデータが収益源ごとに異なるコミッション率を設定できる必要があります。
さらに、基本手数料と優先手数料を含むすべてのブロック手数料収益は、現在バリデータのアイデンティティアカウントに入金されています。アイデンティティアカウントは、TurbineやGossipなどの重要なネットワークプロトコルで頻繁にメッセージへ署名する必要があるため、コールドウォレットにできません。これは運用上およびセキュリティ上の懸念につながる可能性があります。
投票アカウントV4は、投票状態に新しいフィールド（以下のコードブロックを参照）を追加することで、これらの制約に対処します。これにより、バリデータはインフレ報酬とブロック収益について、コミッション率と回収先アカウントの両方を設定できます。このアップデートでは、従来のprior_votersフィールドも削除されます。
pub struct VoteStateV4 {
pub node_pubkey: Pubkey,
pub authorized_withdrawer: Pubkey,
/// REMOVED
/// commission: u8,
/// NEW: the collector accounts for validator income
pub inflation_rewards_collector: Pubkey,
pub block_revenue_collector: Pubkey,
/// NEW: basis points (0-10,000) that represent how much of each income
/// source should be given to this VoteAccount
pub inflation_rewards_commission_bps: u16,
pub block_revenue_commission_bps: u16,
/// NEW: reward amount pending distribution to stake delegators
pub pending_delegator_rewards: u64,
/// NEW: compressed bls pubkey for alpenglow
pub bls_pubkey_compressed: Option<[u8; 48]>
pub votes: VecDeque<LandedVote>,
pub root_slot: Option<Slot>,
/// UPDATED: serialization structure of the AuthorizedVoters map is
/// unchanged but will now contain entries for the previous epoch.
pub authorized_voters: AuthorizedVoters,
/// REMOVED
/// prior_voters: CircBuf<(Pubkey, Epoch, Epoch)>,
pub epoch_credits: Vec<(Epoch, u64, u64)>,
pub last_timestamp: BlockTimestamp,
}このアップデートの一環として、コミッション値はベーシスポイントで保存されます。ただし、Vote Programの既存のUpdateCommission命令は、整数パーセントのコミッション値しかサポートしていません。SIMD-0291：ベーシスポイント単位のコミッション率が採用されるまでは、コミッション率は引き続き整数パーセントに限定されるため、現時点ではコミッションの計算に整数パーセント値を使用してください。
ステークプログラムを含め、投票状態を読み取る既存のツールやプログラムは、新しい投票アカウントのバージョンに対応するよう更新されます。
コミッション更新の遅延
バリデータ運用者にとって重要な2つ目のフィーチャーゲート付きアップデートは、SIMD-0249：コミッション更新の遅延です。この変更により、バリデータはいつでもコミッション更新を送信できますが、その更新は少なくとも1回の完全なエポックが経過するまで有効になりません。
投票プログラムは、エポック前半でのコミッション引き上げを禁止する現在の制限を撤廃するよう変更されます。コミッション変更を送信できるタイミングを制限する代わりに、プロトコル側で有効化までの遅延を適用します。これにより、バリデータはコミッション率を自由に調整できますが、新しい料率が有効になるまで少なくとも1回の完全なエポックを待つ必要があります。
この遅延は、今後のコミッション変更に対応するための通知期間を1エポック分確保できるため、ステーク委任者にもメリットがあります。特に重要なのは、「コミッションラグ」を防止できる点です。これは、悪意あるバリデータが報酬を獲得するため、エポック境界の直前にコミッションを一時的に100%へ引き上げ、その直後に通常の水準へ戻す行為です。
ステートボンド（Rent）の削減
一般に「rent」と呼ばれる高額なステートボンド要件は、Solana開発者にとって長期的なスケーリングを制約する最重要課題の1つです。現在、メインネットのステートボンドは高額で、ストレージコストは1ギガバイトあたり約100万ドルです。たとえば、新しいトークンアカウント（ATA）を1つ作成するには0.002 SOL強が必要で、現在の価格では約0.25ドルに相当します。このため、大規模なトークンの直接エアドロップは非常に高額になり、マイクロペイメントやステーブルコイン決済アプリケーションにも障壁が生じます。こうしたアプリケーションは、トークンアカウントの作成費用を補助するか、そのコストをエンドユーザーに転嫁する必要があります。
この負担を軽減する第一歩が、Agave 3.1のリリースサイクル中に有効化される予定のSIMD-0194：Rent免除しきい値の非推奨化です。これは、ストレージコストを大幅に引き下げて簡素化する、より広範な取り組みの始まりです。これにより、状態に関連する過大な資本要件を課すことなく、アプリケーションを数百万人規模のユーザーへ拡張できるようになります。さらに、ステートボンドのコストに直接対処し、rentを一段と削減する3つのSIMDも現在準備されています。
SIMD-0194は、将来のrent更新を簡素化します。現在、アカウントがrent免除対象かどうかを計算する処理は、オンチェーンプログラムにとって比較的高コストです。現在の`Rent::minimum_balance`計算では浮動小数点（f64）演算を使用し、1回の呼び出しで約256コンピュートユニットを消費します。SIMD-0194では、rent免除ロジックから浮動小数点演算を排除することで、わずか8 CUに削減されます。
これは、exempt_threshold（f64）フィールドを非推奨にし、プログラムがrent免除状態を判定する際に浮動小数点計算を実行する必要をなくすことで実現されます。
この変更の一環として、lamports_per_byte_yearはlamports_per_byteに改名され、デフォルト値は3480から6960へ倍増します。これは、rent免除が従来、2年分のrentを保持することとして定義されてきた点を反映しています。重要なのは、このアップデートではアカウントがrent免除になるために必要な金額は変わらず、値の表現方法と計算方法のみが簡素化および標準化されることです。
このアップデートには完全な後方互換性があり、既にデプロイされているプログラムには影響しません。
今後の展望：SIMD-0437
今年後半に予定されているrent関連の追加SIMDのうち、最も重要なのはSIMD-0437：`lamports_per_byte`を696まで段階的に削減です。この提案では、`lamports_per_byte`を6960から696まで段階的に引き下げ、長期的なステートボンドコストを10分の1に削減するための体系的なスケジュールが示されています。
SIMD-0437は、1回で50%削減することを提案していた以前のSIMD-0436に代わるものです。SIMD-0437では、よりきめ細かな5段階の削減スケジュールが導入されます：6333 → 5080 → 2575 → 1322 → 696。
変更を複数のフェーズに分けることで、ネットワークは時間の経過に伴う状態の増加を観察および評価できます。また、特に議論を呼ぶ削減を個別のステップに分離し、より明確な議論とガバナンスを行えるようになります。
Agave 3.1リリースサイクルのその他の主なアップデート
32データシュレッドと32コーディングシュレッドの厳格な適用
現在、TurbineはFECセットごとに可変数のシュレッドを受け入れます。この挙動は、実質的なメリットがない一方で、不必要な複雑さを生みます。受信側はインデックス境界を判定するためにコーディングシュレッドを必要とするため、シュレッドインデックスの検証が難しくなります。今後予定されているSIMD-0317：32データシュレッド＋32コーディングシュレッドの適用のフィーチャーゲート有効化では、FECセットごとにデータシュレッドとコーディングシュレッドをそれぞれ正確に32個ずつ必須とし、この挙動を標準化します。この変更により二重投票の検出も強化され、将来的にはスラッシングペナルティなどの適用メカニズムに活用されます。
静的命令上限
現在、トップレベル命令が64個を超えるトランザクションは、最初のサニタイズチェックを通過しますが、実行時に失敗します。必ず失敗するトランザクションがパイプラインに入り、スケジューラのリソースを消費するため、不必要な処理が発生しています。
今後予定されているSIMD-0160：静的命令上限のフィーチャーゲート有効化では、トランザクションのサニタイズ時に64命令の上限を適用することで、この問題に対処します。この変更により、トップレベル命令が64個を超えるトランザクション（CPI呼び出しを含む）はサニタイズに失敗し、直ちに拒否されます。
TurbineのChaChaラウンド数を削減
SIMD-0332：TurbineのChaChaラウンドを20から8へ削減は、Turbineのブロックデータ伝播能力に小規模ながら有意義なパフォーマンス向上をもたらします。現在、Turbineはブロック伝播ツリーを構築する際、ステーク加重されたバリデータを決定論的にシャッフルするためにChaCha20を使用しています。このランダムな順序付けは検閲攻撃を防ぐうえで重要ですが、追加の計算オーバーヘッドが発生します。
ChaChaラウンドは決定論的なスクランブラーとして機能し、各ラウンドで変換を適用して出力のランダム性を高めます。ラウンド数を増やすと暗号学的セキュリティは強化されますが、計算コストも増加します。
AgaveがXDPへ移行したことで、再送信はほぼ瞬時に完了するようになり、現在は加重シャッフルのステップが実行時間の大半を占めています。1シュレッドあたり約~1マイクロ秒の処理において、シャッフルをChaCha20からChaCha8へ削減することで、検閲耐性に十分なランダム性を維持しながら、この処理がボトルネックになるのを防げます。
新しい命令データポインタ
現在、sBPFプログラムは命令データを特定するため、シリアライズされた入力領域のアカウントセクションを解析する必要があります。シリアライズレイアウトではアカウントが命令データより前に配置されるため、プログラムは命令データセグメントへ到達する前に、すべてのアカウントエントリを順番に処理しなければなりません。これは、主に、または命令データのみを処理するプログラムに不要な負担を課します。
今後予定されているSIMD-0321：VMレジスタ2の命令データポインタのフィーチャーゲート有効化では、プログラムのエントリポイントでVMレジスタr2に命令データへの64ビットポインタを提供することで、この問題を改善します。このポインタは入力領域内の命令データセクションの先頭を直接参照するため、プログラムは最初にアカウントセクションを解析することなく、命令データへ即座にアクセスできます。解析のオーバーヘッドがなくなるため、コンピュートユニットの消費量を削減できます。
互換性に関する注意： この機能に後方互換性があるのは、現在エントリポイントでr2から読み取っていないプログラムだけです。エントリポイントのr2に以前存在していた未初期化値または不定値へ誤って依存しているプログラムは、この機能が有効化されると動作しなくなります。
RPCの改善
getProgramAccounts RPCエンドポイントは、不正な形式のフィルターが指定された場合に、適切なJSON-RPCエラーを返すようになりました。以前は無効なフィルターが黙って無視され、RPC呼び出しがフィルターなしのクエリへフォールバックしていました。その結果、予想外に高コストなリクエストが実行され、RPCノードに不要な負荷がかかることがありました。この改善により、不正なフィルターに対して明確なエラーが返されるようになり、意図せずリソースを大量消費するクエリを防止し、デバッグも大幅に容易になります。
さらに、simulateTransaction()とsendTransaction()のプリフライト段階で発生した署名検証の失敗は、JSON-RPC APIエラー（-32003）としてスローされるのではなく、シミュレーション結果のerrフィールドにTransactionError::SignatureFailureとして返されるようになります。
そのため、これまで署名検証の失敗時にJSON-RPC例外をキャッチしていたアプリケーションは、今後これらのエラーがシミュレーションレスポンスに直接含まれることを想定する必要があります。シミュレーション結果でTransactionError値を既に具体化して処理しているアプリケーションは、これらの検証時点でTransactionError::SignatureFailureを受け取るようになります。
まとめ
Agave v3.1は、ディスクI/Oの削減、トランザクション処理の高速化、RPCエラー処理の改善など、さまざまなパフォーマンス向上と最適化を実現する大規模なクライアントアップグレードです。Agaveはネットワークの堅牢化でも明確な進展を遂げ、敵対的な条件下でのレジリエンスが強化されています。今回のリリースは、ステートボンドの大幅な削減に向けた第一歩でもあります。
Anzaは、Linuxカーネルへのパッチ提出を含め、スタック全体にわたって改善を提供する業界唯一のコア開発チームとして、引き続き独自性を発揮しています。Agave 3.1がまもなくネットワークを支えるようになることで、Solanaはそのスケーラビリティを引き続き証明していきます。
次のマイルストーンは、現在5月上旬に予定されているAgave 4.0とAlpenglowのテストネットローンチです。
関連リソース
Heliusを購読
Solana開発の最新情報や新しい記事の公開通知を受け取れます