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

Agave 2.0の概要

Agave validator client v2.0のリリースは、より堅牢なマルチクライアントエコシステムを目指すSolanaにとって重要な節目です。このアップデートでは、ネットワークのパフォーマンス、信頼性、効率を高める重要な改善が複数導入されます。主な変更点は次のとおりです。

• コードベースの大規模なリファクタリングと最適化
• エポック報酬の分割
• 優先手数料の全額をvalidatorに付与
• 新しい中央スケジューラーをデフォルトで有効化
• ZK ElGamal Proofプログラム
• Get-Sysvar Syscall
• GetEpochStake Syscall
• MoveStakeとMoveLamports
• 非推奨RPCメソッドの削除
• クレート名の変更

validatorを運用している方、プラットフォーム上で開発している方、Solanaを積極的に利用している方のいずれにとっても、このAgave 2.0アップデートの包括的な概要は、最新のイノベーションを理解し、活用するために必要な知見を提供します。

Agave 2.0がメジャーバージョンアップデートである理由

単一の「Solana validator」は、もはや存在しません。 Agave 2.0はSolanaの新しいマルチクライアント環境を採用し、従来のSolana Labs GitHubリポジトリから完全に移行します。Solana Labsリポジトリはアーカイブされ、新しいプルリクエストやissueは受け付けられなくなります。以前、このリポジトリにはAgaveリポジトリのアクティビティがミラーリングされていました。まだ移行していない開発者は、すべての作業をAnza Agave GitHubリポジトリへ移行してください。Solana LabsからAgaveへの移行プロセスは3月1日に開始され、その進捗はGitHubで公開されています。

エコシステムの進化に伴い、オペレーターは1つ以上のクライアントを運用できるよう対応する必要があります。この移行に合わせ、複数のクレート名が変更され、独立した開発チームが管理するFiredancerをはじめとする複数のクライアントをサポートできるよう名前空間が整理されます。Anzaが保守するクレートには今後「agave」というプレフィックスが付き、マルチクライアント環境内でAnza固有の依存関係として容易に識別できるようになります。

‍影響を受けるクレートは次のとおりです。 

• solana-validator
• solana-ledger-tool
• solana-watchtower
• solana-install
• solana-geyser-plugin-interface
• solana-cargo-registry

以前の移行ガイドで詳しく説明したように、2.0アップデートでは複数の破壊的変更が導入されます。特に、古くなった非推奨エンドポイントが複数削除されます。これは、すべてのSolana開発者が把握しておくべき重要な変更です。RPCの変更点の詳細は、この記事の最後に記載しています。

機能のロールアウト

執筆時点では、validatorの~20.7%がバージョン2.0.14を実行しています。testnetおよびdevnetでの有効化とv2.0の導入時期をより緊密に合わせるため、mainnetでのfeature gateの有効化は一時停止されています。mainnetクラスターでv2.0が広く導入されると、予定されている有効化順序に従ってfeature gateの有効化が再開される見込みです。 

以下のセクションで説明する新機能は、現時点では稼働していません。feature gateシステムを使用し、2.0のライフサイクルを通じて段階的にロールアウトされます。各機能は、相対的な優先順位とtestnetおよびdevnetクラスターで有効化された順序に基づき、特定のエポックで有効化されます。

優先手数料の全額をvalidatorに付与

大きな期待を集め、盛んに議論されてきた経済モデルのアップデートが、5月にvalidatorのガバナンス投票を経た提案SIMD-0096に基づいて実装されます。投票はエポック620の終了時に締め切られ、ステークの51.17%が参加し、そのうち77.77%が賛成票を投じました。このfeature gateによるアップデートは、ネットワークにおける優先手数料の処理方法を根本的に変えます。手数料の50%をバーンし、残りの50%をvalidatorに付与する現在のモデルに代わり、新しいモデルでは優先手数料の100%がvalidatorへ直接割り当てられます。

優先手数料は技術的には任意ですが、Solana上の経済活動が拡大するにつれて標準的な慣行となっています。この手数料は、コンピュートユニットあたりのマイクロランポート（1ランポートの100万分の1）を使用し、次の式で計算されます。

‍優先手数料 = コンピュートユニット価格（マイクロランポート）x コンピュートユニット上限

今後、すべての優先手数料はブロックプロデューサーに付与されます。これによりインセンティブの整合性が強まり、過去に問題となっていた、トランザクションをブロックに含めるためにvalidatorがプロトコル外の取り決めを行う可能性が低下します。

手数料のバーンを廃止するとSOLの純インフレ率はわずかに上昇しますが、ステーキング報酬による新規トークン発行の影響の方がはるかに大きいです。この動向の詳細については、以前のHeliusブログ記事「Solanaの発行量とインフレスケジュール」をご覧ください。

エポック報酬の分割

エポック報酬の分割は、ステーク報酬を複数のブロックに分散し、新しい各エポックの最初のブロックに報酬配布が集中することで生じるパフォーマンス上の問題を軽減することを目的としています。このプロセスにおける主なボトルネックは、ネットワーク上で増加を続けるアクティブなステークアカウントに更新を書き戻す必要があることです。その数は現在、約140万に達しています。

この新しいアプローチでは、エポック境界でのステーク報酬の計算と配布が、次の2つの明確なフェーズに分けられます。

• 報酬計算フェーズ： このフェーズでは、すべてのアクティブなステークアカウントのエポック報酬を計算し、配布分をスケジュールされたチャンクに分割します。
• 報酬配布フェーズ： 事前に計算されたアクティブなステークアカウントのエポック報酬を配布します。

このプロセスの実行と監視を支援するため、SysvarアカウントのEpochRewardsが、配布フェーズ全体を通して報酬配布を追跡し、検証します。EpochRewards Sysvarは、報酬配布フェーズが進行中かどうかと、スナップショットから開始する際に配布を再開するために必要な情報を記録します。 

報酬の計算

報酬はエポックの最初のブロックで計算されます。計算後、報酬はbankに保存される配布チャンクへ分割され、報酬配布フェーズで配布されます。

報酬配布フェーズにおけるブロック処理時間への影響を最小限に抑え、各ブロックが報酬の一部を決定論的に配布できるよう、ブロックごとに4,096件のステーク報酬を配布することを目標とします。ステークアカウント数の急激な増加に備え、ブロック数は1エポック内の総スロット数の10%を上限とします。このブロック上限に達した場合に限り、パーティションあたりのアカウント数が4,096件という目標を超えることが認められます。

報酬の配布

報酬の配布は報酬計算フェーズの直後、エポックの2番目のブロックから開始されます。報酬は、通常のトランザクション処理より前のブロック先頭で配布されます。

その結果、ユーザーのステークアカウントに報酬が反映されるタイミングは、以前より数ブロック遅くなる場合があります。ただし、以前もエポック境界で最初のブロックの処理時間が長引き、ユーザーがステークアカウントへアクセスできる時点が遅れていたため、全体的な体験はほぼ変わりません。このアプローチには、ステーキング以外のトランザクションを引き続き円滑に処理できるという利点もあります。以前は、報酬の配布中にこれらのトランザクションがブロックされていました。‍

vote accountの数は約1,500と比較的少ないため、エポック境界の最初のブロックで投票報酬を配布する既存の仕組みは変更されません。複数のブロックに分けて配布されるのはステーク報酬のみです。

中央スケジューラーがデフォルトで有効化

中央スケジューラーはv1.18アップデートで機能として初めて導入されました。当初は単に「スケジューラー」と呼ばれており、デフォルトでは有効になっていなかったため、オペレーターはvalidatorの起動時に--block-production-method central-schedulerフラグを使用して有効にする必要がありました。今回からデフォルトで有効になります。以前のスケジューラー実装には、パフォーマンスへ悪影響を及ぼす可能性のある問題が複数ありました。トランザクション処理のボトルネックにより、トランザクションの順序付けや優先順位付けに揺らぎや不整合が生じることがよくありました。

新しい実装では、それぞれが独自にトランザクションの優先順位付けと処理を管理していた4つの独立したbanking threadによる従来のモデルを置き換えます。新しい構造では、中央スケジューラーのみがTPUのSigVerifyステージからトランザクションを受け取ります。中央スケジューラーはpriority queueを構築し、prio-graphと呼ばれるdependency graphを使用して、競合するトランザクションの処理と優先順位付けをより適切に管理します。この新しいスケジューラー設計により、スケーラビリティと柔軟性が向上し、従来懸念されていたロック競合の増加を招くことなくthread数を増やせます。中央スケジューラーの初期ロールアウトでは、より多くの報酬を生み出し、多くのオペレーターの収益が向上することが示されています。Solana v1.18アップデートに関する以前のHeliusの記事では、中央スケジューラーの仕組みを詳しく解説しています。

ZK ElGamal Proofプログラム

当初1.17リリースへの搭載が予定されていたZK Token Proofプログラムは非推奨となり、より汎用性が高く、アプリケーションに依存しないZK ElGamal Proofプログラムに置き換えられます。新しいZK ElGamal Proofプログラムには、公開鍵の有効性やElGamal暗号文内で暗号化された値の範囲の検証など、アプリケーション全般に広く適用できるZK Token Proofプログラムの部分が引き継がれます。一方、SPL Tokenの転送命令に必要なゼロ知識証明の検証など、アプリケーション固有の要素は含まれません。新しいZK ElGamal Proofプログラムは、アドレスZkE1Gama1Proof11111111111111111111111111111で組み込みプログラムの一覧に追加されます。

ZK Token Proof Programの詳細については、Heliusブログの解説記事をご覧ください。

Get-Sysvar Syscall

Syscalls（system call）は、オペレーティングシステムのカーネルにサービスを要求します。Solanaでは、SyscallによってSolana Virtual Machine（SVM）内で実行されるプログラムが外部のリソースやサービスと連携できます。 

Sysvarsは、最近のblock hashやエポック報酬など、クラスターの状態情報を公開します。これらのアカウントは既知のアドレスに配置されます。プログラムはSysvarアカウントを介してSysvarへアクセスするか、Syscallを介してクエリできます。オンチェーンプログラムは幅広いユースケースで多くのSysvarを使用しており、一部のSysvarはネットワークの動作に不可欠です。

AnzaのエンジニアであるJoe CaulfieldがSIMD-127で最初に提案したGet-Sysvar Syscallは、Sysvarデータへアクセスするための統一されたSyscallインターフェースを導入します。このアップグレードにより、これまでアクセスできなかったSlotHashesやStakeHistoryなどのSysvarデータを取得できるようになります。新しいインターフェースを使用すると、開発者はSlotHashes::get_slot(slot)やStakeHistory::get_entry(epoch)を呼び出す場合など、データ構造全体を複製することなくSysvarデータの特定部分へアクセスできます。

このアップデートにより、Sysvarのデータレイアウトを変更したり、新しいSysvarを追加したりする際のオーバーヘッドも最小限に抑えられます。以前は、新しいSysvarごとに対応するSyscallを追加する必要がありました。この密結合によってSyscallインターフェースが時間とともに肥大化し、保守が複雑になっていました。今後は単一のsol_get_Sysvar SyscallがすべてのSysvarインターフェースに対応し、どのSysvarからも一貫性のある効率的なデータ取得が可能になります。

新しいSyscallの導入により、Sysvarの変更や追加のプロセスが簡素化されます。Syscallインターフェースの複雑さと保守要件も大幅に軽減されます。さらに、このアップデートはBPFプログラムからアクセスできるSysvarデータの拡大にもつながり、オンチェーンプログラムがトランザクションサイズに影響を与えることなく、より多くのSysvar情報を読み取れるようになります。

GetEpochStake Syscall

新しいGetEpochStake Syscallでは、現在のエポックにおいてvote accountへ委任されたステークを取得するという、要望の多かった機能が導入されます。これにより、この情報をオンチェーンでより効率的かつ直接取得できるようになります。

現在、プログラムは特定のvote accountに対して現在のエポックで委任されているステークのリアルタイムデータへアクセスできません。これはvalidatorガバナンスや二次的なコンセンサスメカニズムなどのユースケースにとって障壁となっています。このデータをオンチェーンでクエリできるようにすることで、こうしたアプリケーションが実現し、将来のユースケースへの道が開かれます。

GetEpochStakeでは、開発者が32バイトのvote accountアドレスを指定すると、そのvote accountに現在委任されているアクティブステークの合計を表すu64整数がsyscallから返されます。指定されたアドレスが有効なvote accountに対応していない場合や存在しない場合、Syscallは単に0を返します。

MoveStakeとMoveLamports

ステークアカウント間の価値移転を容易にするため、2つの新しいstake program命令、MoveStakeとMoveLamportsが導入されます。SIMD-0148で最初に提案されたこれらの命令により、withdrawer authorityによる制御なしで、同じauthorityを持つアカウント間で資金を移動できるようになり、開発者を支援します。

これまで、ユーザーのステークを管理するプロトコルは、複数のvalidatorにステークを分割し、その間で定期的に再委任する際に課題を抱えていました。プロトコルがユーザーのステークを非アクティブ化のために分割する場合、新しいアカウントのrent exemptionに必要なランポートを用意する必要があります。分割したアカウントを統合しても、プロトコルはrent exemption用のランポートを回収できません。

MoveStake

MoveStake：この命令では、アクティブなステークをアカウント間で移動できます。アクティブなアカウントから別のアクティブなアカウント、またはアクティブなアカウントから非アクティブなアカウントへ移転し、移転先のアカウントを再アクティブ化できます。移転元アカウントの委任全体を移動した場合、移転元アカウントは非アクティブになります。どのシナリオでもrent-exempt balanceは変更されず、アクティブなアカウントには最小委任ルールが維持されます。

MoveLamports

MoveLamports：アクティブまたは非アクティブなアカウントから、別のアクティブまたは非アクティブなアカウントへ余剰ランポートを移動します。「余剰ランポート」とは、委任されたステークでもrent-exemptionに必要なランポートでもないものを指します。MoveLamportsにより、統合済みアカウントからのランポート回収や未使用資金の集約といった整理作業が可能になります。

実装を簡素化するため、これらの変更ではアカウントのアクティブ化や非アクティブ化はサポートされず、部分的にアクティブなステークアカウントにも影響しません。これらの新しいプログラム命令によって既存の機能が変更されることはありません。

補足：Solana-SVMクレート

Agave 2.0のリリースに伴い、まったく新しいsolana-svmクレートが登場します。これは、validatorフレームワーク全体から独立した合理的なAPIを通じて、開発者がSVMのコアコンポーネントへ直接アクセスできるようにするものです。これにより、オフチェーンサービス、軽量クライアント、ステートチャネル、ロールアップなど、validator以外のアプリケーションでもSolanaの高性能なトランザクション処理を利用できるようになります。

APIをランタイムの他の部分から分離することで、このクレートはBankインスタンスなどのコンポーネントを不要にし、運用オーバーヘッドを削減します。開発者は、Solanaのmainnet-betaを支えるものと同じ堅牢なコンポーネントを活用し、ライトクライアント、ステートチャネル、ロールアップ、オフチェーンサービスなどのカスタムSVMプロジェクトを構築できます。このAPIの中核となるのはTransactionBatchProcessor構造体です。これによりアプリケーションは、BPF Loader、eBPF、仮想マシンを含む一連の下流Agaveコンポーネントをすべて使用して、サニタイズ済みSolanaトランザクションのバッチを処理できます。

この注目すべき開発の詳細については、Anzaの新しいSVM APIの詳細解説をご覧ください。

削除されたRPCエンドポイント 

古くなった非推奨のv1 Agave RPCエンドポイントが複数削除されました。Helius Devrelチームは、これらのエンドポイントを使用しているすべてのお客様に連絡済みです。社内分析を通じて、削除対象となる以下のエンドポイントを現在も使用している少数のお客様を以前から特定していました。

• getRecentBlockhash
• getConfirmedSignatureForAddresses2
• getConfirmedTransaction
• getConfirmedBlock
• getStakeActivation
• getFees

注：画像に示されているgetAccountInfoの代替手法は、こちらで確認できます。

SDKの破壊的変更は次のとおりです。

• Borsh v0.9のサポートを削除。v1またはv0.10を使用してください（#1440）
• RentとEpochScheduleでCopy traitがderiveされなくなりました。clone()を使用してください
• solana-sdk：非推奨シンボル)を削除 
• solana-program：非推奨シンボルを削除

validatorオペレーター向けには、Agave v2.0のリリース時に複数の非推奨validator引数が削除されます。完全な一覧はこちらで確認できます。‍

まとめ

Agave 2.0アップデートは、多数の機能実装とランタイム最適化を取り入れた、Solanaにとって大きな前進です。このリリースでは、強力な新しいSyscallと拡張機能に加え、クレート名の変更、非推奨RPCメソッドの削除、validator引数の簡素化など、包括的な整理によってさらなる進化を遂げます。Agave 2.0はSolanaの機能を拡張し、パフォーマンスと使いやすさを高めます。開発者、validator、アクティブユーザーのいずれにとっても、Agave 2.0アップデートはSolanaエコシステムに刺激的な新しい可能性をもたらします。

その他のリソース

• Agave v2.0リリーススケジュール
• Agave v2.0変更履歴
• Agaveのリリースバージョン