Agave v2.0アップデート すべての必要な情報
アガベ 2.0 サマリー
Agaveバリデータクライアントv2.0のリリースは、Solanaのより堅牢でマルチクライアントのエコシステムへの道のりで重要なマイルストーンです。このアップデートでは、ネットワークのパフォーマンス、信頼性、効率を向上させるためのいくつかの重要な改善が導入されています。このアップデートの主な変更点は次のとおりです:
- 広範囲のコードベースのリファクタリングと最適化
- 分割されたエポックの報酬
- バリデータに完全な優先手数料を報酬する
- 新しい中央スケジューラはデフォルトでオンになりました
- ZK ElGamal証明プログラム
- Get-Sysvar Syscall
- GetEpochStake Syscall
- MoveStakeとMoveLamports
- 廃止されたRPCメソッドの削除
- クレートの名前の変更
バリデータを実行するか、プラットフォーム上で構築するか、または積極的にSolanaを使用するかどうかにかかわらず、このAgave 2.0の包括的な概要により、最新のイノベーションを理解し、活用するために必要な洞察を身につけることができます。
2.0はメジャーバージョンアップデートとなる要素
単一の「Solanaバリデータ」はもう存在しません。Agave 2.0はSolanaの新しいマルチクライアントの世界を受け入れ、古いものとの完全な切り離しを示しています。Solana LabsのGitHubリポジトリ.Solana Labs リポジトリはアーカイブされ、新しいプルリクエストやイシューは受け付けられなくなります。以前は、このリポジトリは Agave リポジトリからのアクティビティをミラーリングしていました。開発者は、すべてのアクティビティをAnza Agave GitHubリポジトリif they haven’t already done so. TheSolana Labsからアガベへの移行プロセス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の変更の詳細は、この記事の最後に含まれています。
機能の展開
この記事を書いている時点では、~20.7%のバリデーターがバージョン2.0.14を実行しています。メインネットでの機能ゲートのアクティベーションは、v2.0の採用がテストネットおよびdevnetでのアクティベーションとより緊密に連携できるように、一時的に一時停止されています。メインネットクラスターがv2.0を広く採用すると、機能ゲートのアクティベーションが再開される予定です。予定されたアクティベーション注文.
次のセクションで説明する新しい全機能は、現在公開されておらず、機能ゲート システムを使用して 2.0 ライフサイクル全体で徐々にロールアウトされます。機能は、相対的な優先度と、テストネットおよび開発ネット クラスターでアクティブ化された順序に基づいて、特定のエポックでアクティブ化されます。
バリデータに対する完全な優先手数料の報酬
この高い期待と激論を巻き起こしている経済アップデート提案に続いて、実装が進行中です。SIMD-0096, which went through a validator governance vote in May. The vote concluded at the end of epoch 620, with 51.17% of the stake participating and 77.77% voting in favor. The feature-gated update will fundamentally change the network’s handling of優先手数料. 現行のモデルでは、手数料の50%が燃やされ、50%がバリデータに報酬として与えられる代わりに、新しいモデルでは、優先手数料の100%が直接バリデータに割り当てられます。
上記：Solana週間優先手数料のUSD価値（ソース)
優先手数料は技術的には任意ですが、Solana上の経済活動が増加するにつれて標準的な実践となっています。 これらの料金は、式を使用してコンピューティングユニットあたりのマイクロラムポート（ラムポートの百万分の一）で計算されます。
優先料金 = コンピュートユニット価格（マイクロラムポート）×コンピュートユニット制限
今後、すべての優先手数料はブロックプロデューサーに支給されます。これによりインセンティブの強化が図られ、バリデータがプロトコル外の取引手続きに関与する可能性が低減されます。これは過去に問題となっていたことです。
手数料の焼却を除いても、SOLの純インフレ率はわずかに上昇しますが、ステーキング報酬による新しいトークンの発行は、はるかに大きな影響を与えます。読者は私たちの以前のHeliusブログ記事を参照してください。Solanaの発行とインフレスケジュールこれらのダイナミクスの詳細な分解については、以下をご覧ください。
パーティションされたエポック報酬
分割されたエポックの報酬分配を目指すステーキング報酬複数のブロックにまたがり、新しい各エポックの最初のブロック内に報酬の分配を集中させることに関連するパフォーマンスの問題を軽減します。このプロセスの主なボトルネックは、ネットワーク上で増え続けるアクティブなステークアカウント(現在、合計約140万)に更新を書き戻す必要があることです。\
この新しいアプローチでは、エポック境界でのステーク報酬の計算と配布は、2つの異なるフェーズに分割されます。
- 報酬計算フェーズ:このフェーズでは、すべてのアクティブなステークアカウントのエポック報酬が計算され、配布がスケジュールされたチャンクに分割されます。
- 報酬配布フェーズ：アクティブなステークアカウントの事前計算済みエポック報酬は適切に配布されます。
プロセスを容易にするために、Sysvarアカウントを作成し、監視します。EpochRewards,報酬の配布を追跡し、配布フェーズ全体で報酬の配布を確認します。EpochRewards Sysvarは、報酬の配布フェーズが進行中であるかどうか、およびスナップショットから再開するために必要な情報を記録します。
報酬の計算
リワードの計算はエポックの最初のブロックで行われます。計算が行われると、リワードは銀行に格納された分配チャンクに分割され、リワード分配フェーズ中に配布されます。
報酬配布フェーズ中のブロック処理時間への影響を最小限に抑え、各ブロックが報酬のサブセットを確定的な方法で配布するために、ブロックあたり4,096のステーク報酬の配布目標が設定されます。ステークアカウントの数の急激な増加に対する保護策として、エポック内の総スロット数の10％を上限としてブロック数が制限されます。このブロック上限に到達した場合にのみ、パーティションごとのアカウントが4,096の目標を超えることが許可されます。
報酬配布
報酬配布は、報酬計算フェーズの直後、エポックの2番目のブロックから開始されます。報酬の配布は通常のトランザクション処理の前にブロックの先頭で行われます。
その結果、ユーザーは以前よりも数ブロック遅れて報酬がステークアカウントに入金される場合があります。ただし、エポック境界の最初のブロック時間が長くなったため、ユーザーのステークアカウントへのアクセスが遅れるという全体的な体験は同様です。このアプローチの追加の利点は、非ステーキングトランザクションがスムーズに処理され続けることです。以前は報酬の分配中にブロックされていました。
投票アカウントの数が比較的少ない（約1,500）ため、エポック境界の最初のブロックでの投票報酬の配布メカニズムは変更されません。ステーク報酬のみが複数のブロックに分散して配布されます。
セントラルスケジューラはデフォルトでオンになりました
v1.18アップデートで機能リリースとして最初に紹介された中央スケジューラー（以前は「スケジューラー」として知られていた）は、デフォルトで有効になっておらず、バリデータを起動する際にオペレータが —block-production-method central-scheduler フラグを使用して有効にする必要がありました。現在はデフォルトでオンになっています。以前のスケジューラー実装には、パフォーマンスに悪影響を与える可能性があるいくつかの問題がありました。トランザクション処理のボトルネックは、トランザクションの順序付けと優先順位付けに不一致や不安定さを引き起こすことがよくありました。
新しい実装は、それぞれが独自のトランザクション優先順位と処理を管理する4つの独立したバンキングスレッドの以前のモデルを置き換えます。この改訂された構造では、中央スケジューラーがTPUのSigVerifyステージからトランザクションを唯一の受信者として受け取ります。優先度キューを構築し、競合するトランザクションの処理と優先順位付けをより良く管理するために、依存グラフ（prio-graphとも呼ばれる）を展開します。この新しいスケジューラーの設計により、以前のロックの競合が増加する心配なしに、スレッド数を増やすことができるため、スケーラビリティと柔軟性が向上します。中央スケジューラーの最初の導入は、多くのオペレーターの収益に改善をもたらし、より良い報酬を生み出すことが示されています。Solana v1.18のアップデートに関する以前のHeliusの投稿でも詳しく説明されています。中央スケジューラがどのように機能するか.
ZK ElGamal証明プログラム
1.17リリースに含まれる予定だったZK Token Proofプログラムは非推奨となり、より多目的でアプリケーションに依存しないものに置き換えられます。ZK ElGamal証明プログラム.新しいZK ElGamalプルーフプログラムは、公開鍵の有効性やElGamal暗号文内で暗号化された値の範囲の検証など、アプリケーション全体に広く適用されるZKトークンプルーフプログラムの部分を保持しています。ただし、SPLトークンの転送手順に必要なゼロ知識証明の検証など、アプリケーション固有の要素は省略されています。新しいZK ElGamal Proofプログラムは、アドレスの組み込みプログラムのリストに組み込まれますZkE1Gama1Proof11111111111111111111111111111.
ZKトークンプルーフプログラムの詳細については、Heliusブログの元の記事.
Get-Sysvar Syscall
Syscallsまたはシステムコールは、オペレーティングシステムカーネルからサービスを要求します。Solanaの文脈では、SyscallはSolana仮想マシン（SVM）内で実行されているプログラムが外部リソースやサービスとやり取りすることを可能にします。
Sysvarsは、最近のブロックハッシュやエポック報酬などのクラスタの状態情報を公開します。これらのアカウントは既知のアドレスに配置されます。プログラムはSysvarアカウントを介してSysvarsにアクセスするか、Syscallを介してクエリすることができます。オンチェーンプログラムは、さまざまなユースケースに対して多くのSysvarsを使用し、特定のSysvarsはネットワークの運用に不可欠です。
最初に提案されたGet-Sysvar SyscallSIMD-127 by Anza エンジニア Joe Caulfieldでは、Sysvar データにアクセスするための統一された Syscall インターフェイスが導入されています。このアップグレードにより、SlotHashes や StakeHistory など、以前はアクセスできなかった Sysvar データを取得できるようになります。この新しいインターフェイスを使用すると、開発者は Sysvar データの特定のフラグメントにアクセスできます。SlotHashes::get_slot(スロット)そしてStakeHistory::get_entry(epoch)—データ構造全体を複製する必要はありません。
この更新では、Sysvarデータレイアウトを変更したり新しいSysvarsを追加する際のオーバーヘッドも最小限に抑えられます。以前は、新しいSysvarごとに対応するSyscallの追加が必要であり、時間の経過とともにSyscallインターフェースが膨れ上がり、メンテナンスが複雑化していました。今では、単一のsol_get_Sysvar SyscallがすべてのSysvarインターフェースを提供し、どのSysvarからも一貫して効率的にデータを取得できるようになりました。
新しいSyscallの導入により、Sysvarsの変更と新規追加のプロセスが簡素化されます。これにより、Syscallインターフェースの複雑さとメンテナンス要件が大幅に削減されます。さらに、このアップデートにより、BPFプログラムがSysvarデータにアクセスできるようになり、トランザクションサイズに影響を与えずにオンチェーンプログラムがより多くのSysvar情報を読み取ることが可能になります。
GetEpochStake Syscall
新しいGetEpochStake システムコール現在のエポックのための投票アカウントの委任ステークを取得するための要求の非常に高い機能を導入します。これにより、この情報をオンチェーンでより効率的かつ直接的に取得する方法が提供されます。
現在、プログラムは、現在のエポックの特定の投票アカウントに委任されたステークのリアルタイムデータにアクセスできないため、バリデーターガバナンスや二次コンセンサスメカニズムなどのユースケースの障壁となっています。このデータのオンチェーンクエリを有効にすることで、これらのアプリケーションのロックが解除され、将来のユースケースへの道が開かれます。
GetEpochStakeを使用すると、開発者は32バイトの投票アカウントアドレスを提供し、システムコールはその投票アカウントに現在委任されている総アクティブステークを表すu64整数を返します。提供されたアドレスが有効な投票アカウントに対応していないか存在しない場合、システムコールは単に0を返します。
MoveStakeとMoveLamports
2つの新しいステークプログラム命令MoveStake と MoveLamportsは、ステークアカウント間の価値移転を容易にするために導入されています。これらの指示は、最初にSIMD-0148 (英語)、引き出し権限の制御なしに、一致する権限を持つアカウント間で資金の移動を許可することにより、開発者を支援します。
以前、ユーザーのステークを管理するプロトコルは、複数のバリデータにステークを分割し、定期的に再委任する際に課題に直面していました。プロトコルがユーザーのステークを非アクティブ化するためにステークを分割する場合、新しいアカウントのためにレントの免除ラムポートを資金提供する必要があります。プロトコルは、これらの分割されたアカウントをマージする際にレントの免除ラムポートを回収することはできません。
MoveStake:この命令により、アクティブなステークをアカウント間で移動し、あるアクティブなアカウントから別のアカウントに、またはアクティブなアカウントから非アクティブなアカウントに転送して、アカウントを再アクティブ化できます。ソースアカウントの委任全体が移動すると、ソースアカウントは非アクティブになります。家賃免除残高はすべてのシナリオで変更されず、アクティブなアカウントに対して最小委任ルールが維持されます。
MoveLamports：「MoveLamports」は、アクティブまたは非アクティブなアカウントから別のアクティブまたは非アクティブなアカウントに余剰のlamportsを移動します。「余剰のlamports」とは、委任されたステークでもなく、家賃免除に必要なものでもないlamportsのことを指します。MoveLamportsは、マージされたアカウントからlamportsを回収したり、未使用の資金を統合したりするなどのメンテナンス作業を可能にします。
実装を効率化するため、これらの変更はアカウントの有効化や無効化をサポートせず、一部のアクティブなステークアカウントにも影響を与えません。これらの新しいプログラムの指示は既存の機能に影響を与えません。
おまけ:Solana-SVMクレート
Agave 2.0のリリースとともに、ブランド-ニューなsolana-svmクレート開発者に対して、フルバリデータフレームワークに依存しないスムーズなAPIを通じて、コアSVMコンポーネントへの直接アクセスを提供しています。これにより、バリデータ以外のアプリケーション（オフチェーンサービス、軽量クライアント、ステートチャネル、ロールアップなど）にSolanaの高性能トランザクション処理が開放されます。
APIをランタイムの他の部分から分離することにより、このクレートはBankインスタンスなどのコンポーネントが不要になり、運用オーバーヘッドが削減されます。開発者は、メインネットベータをサポートする堅牢なコンポーネントを使用して、軽量クライアント、状態チャネル、ロールアップ、オフチェーンサービスなどのカスタムSVMプロジェクトを構築できます。このAPIのコアはTransactionBatchProcessor構造体であり、アプリケーションは、BPFローダー、eBPF、および仮想マシンを含む下流のAgaveコンポーネントの全機能を備えた、サニタイズされたSolanaトランザクションのバッチを処理できます。
上:トランザクションバッチプロセッサ(画像出典:Anza)
ディープダイブを読むアンザの新しいSVM APIこのエキサイティングな開発の詳細については、gateをご覧ください。
RPCエンドポイントが削除されました
廃止および非推奨の v1 Agave RPC エンドポイントが複数削除されました。Helius Devrel チームは、これらのエンドポイントを使用しているすべてのお客様に連絡を取りました。内部分析を通じて、削除が予定されている次のエンドポイントを積極的に使用している少数の顧客グループを以前に特定しました。
getRecentBlockhash、getConfirmedSignatureForAddresses2、getConfirmedTransaction、getConfirmedBlock、getStakeActivation、getFees
再度、すべての開発者に対して、これらの呼び出しに対する参照を確認し、提案された置換で適切に更新することを強くお勧めします。
上記：削除予定の完全な旧式および非推奨のv1 Agave RPCエンドポイントの一覧
N.B. 画像に示されているgetAccountInfoの代替アプローチは次のとおりです見つかりました.
SDKの変更には、gateが含まれています。
- Borsh v0.9 のサポートが削除されたため、v1 または v0.10 (#1440)
- コピー特性はもはや派生されませんRentとEpochScheduleでの切り替え。clone()の使用に切り替える
- solana-sdk: 非推奨の記号) removed
- solana-program: 廃止されたシンボルが削除されました
バリデーターオペレーターの場合、Agave v2.0のリリースに伴い、いくつかの廃止されたバリデーター引数が削除されます。これらの完全なリストはこちらで見つけることができますここ.
結論
Agave 2.0のアップデートは、Solanaにとって重要な進歩を示しており、多数の機能実装やランタイムの最適化が組み込まれています。このリリースは、強力な新しいSyscalls、拡張機能、包括的なメンテナンスを継続して推進し、クレートの名前変更、非推奨のRPCメソッドの削除、スムーズなバリデーター引数などを含んでいます。Agave 2.0はSolanaの機能を拡張し、パフォーマンスと使いやすさを洗練させています。開発者、バリデーター、またはアクティブユーザーであるかにかかわらず、Agave 2.0のアップデートにより、Solanaエコシステムのすべての人にとって新しい可能性が開かれます。
追加リソース/さらに読む
免責事項：
関連記事
PayFiとは何ですか、そしてなぜPayFiにはソラナが使用されていますか？
CKBの進化を探る
ケルトナーチャネルの理解
Agave v2.0アップデート すべての必要な情報
アガベ 2.0 サマリー
バリデーターに全額優先手数料を報酬
分割されたエポック報酬
中央スケジューラーはデフォルトでオンになっています
ZK ElGamal証明プログラム
Get-Sysvar Syscall
GetEpochStake Syscall
MoveStakeとMoveLamports
ボーナス：Solana-SVM Crate
RPCエンドポイントが削除されました
結論
追加リソース / さらなる読書
アガベ 2.0 サマリー
Agaveバリデータクライアントv2.0のリリースは、Solanaのより堅牢でマルチクライアントのエコシステムへの道のりで重要なマイルストーンです。このアップデートでは、ネットワークのパフォーマンス、信頼性、効率を向上させるためのいくつかの重要な改善が導入されています。このアップデートの主な変更点は次のとおりです:
- 広範囲のコードベースのリファクタリングと最適化
- 分割されたエポックの報酬
- バリデータに完全な優先手数料を報酬する
- 新しい中央スケジューラはデフォルトでオンになりました
- ZK ElGamal証明プログラム
- Get-Sysvar Syscall
- GetEpochStake Syscall
- MoveStakeとMoveLamports
- 廃止されたRPCメソッドの削除
- クレートの名前の変更
バリデータを実行するか、プラットフォーム上で構築するか、または積極的にSolanaを使用するかどうかにかかわらず、このAgave 2.0の包括的な概要により、最新のイノベーションを理解し、活用するために必要な洞察を身につけることができます。
2.0はメジャーバージョンアップデートとなる要素
単一の「Solanaバリデータ」はもう存在しません。Agave 2.0はSolanaの新しいマルチクライアントの世界を受け入れ、古いものとの完全な切り離しを示しています。Solana LabsのGitHubリポジトリ.Solana Labs リポジトリはアーカイブされ、新しいプルリクエストやイシューは受け付けられなくなります。以前は、このリポジトリは Agave リポジトリからのアクティビティをミラーリングしていました。開発者は、すべてのアクティビティをAnza Agave GitHubリポジトリif they haven’t already done so. TheSolana Labsからアガベへの移行プロセス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の変更の詳細は、この記事の最後に含まれています。
機能の展開
この記事を書いている時点では、~20.7%のバリデーターがバージョン2.0.14を実行しています。メインネットでの機能ゲートのアクティベーションは、v2.0の採用がテストネットおよびdevnetでのアクティベーションとより緊密に連携できるように、一時的に一時停止されています。メインネットクラスターがv2.0を広く採用すると、機能ゲートのアクティベーションが再開される予定です。予定されたアクティベーション注文.
次のセクションで説明する新しい全機能は、現在公開されておらず、機能ゲート システムを使用して 2.0 ライフサイクル全体で徐々にロールアウトされます。機能は、相対的な優先度と、テストネットおよび開発ネット クラスターでアクティブ化された順序に基づいて、特定のエポックでアクティブ化されます。
バリデータに対する完全な優先手数料の報酬
この高い期待と激論を巻き起こしている経済アップデート提案に続いて、実装が進行中です。SIMD-0096, which went through a validator governance vote in May. The vote concluded at the end of epoch 620, with 51.17% of the stake participating and 77.77% voting in favor. The feature-gated update will fundamentally change the network’s handling of優先手数料. 現行のモデルでは、手数料の50%が燃やされ、50%がバリデータに報酬として与えられる代わりに、新しいモデルでは、優先手数料の100%が直接バリデータに割り当てられます。
上記：Solana週間優先手数料のUSD価値（ソース)
優先手数料は技術的には任意ですが、Solana上の経済活動が増加するにつれて標準的な実践となっています。 これらの料金は、式を使用してコンピューティングユニットあたりのマイクロラムポート（ラムポートの百万分の一）で計算されます。
優先料金 = コンピュートユニット価格（マイクロラムポート）×コンピュートユニット制限
今後、すべての優先手数料はブロックプロデューサーに支給されます。これによりインセンティブの強化が図られ、バリデータがプロトコル外の取引手続きに関与する可能性が低減されます。これは過去に問題となっていたことです。
手数料の焼却を除いても、SOLの純インフレ率はわずかに上昇しますが、ステーキング報酬による新しいトークンの発行は、はるかに大きな影響を与えます。読者は私たちの以前のHeliusブログ記事を参照してください。Solanaの発行とインフレスケジュールこれらのダイナミクスの詳細な分解については、以下をご覧ください。
パーティションされたエポック報酬
分割されたエポックの報酬分配を目指すステーキング報酬複数のブロックにまたがり、新しい各エポックの最初のブロック内に報酬の分配を集中させることに関連するパフォーマンスの問題を軽減します。このプロセスの主なボトルネックは、ネットワーク上で増え続けるアクティブなステークアカウント(現在、合計約140万)に更新を書き戻す必要があることです。\
この新しいアプローチでは、エポック境界でのステーク報酬の計算と配布は、2つの異なるフェーズに分割されます。
- 報酬計算フェーズ:このフェーズでは、すべてのアクティブなステークアカウントのエポック報酬が計算され、配布がスケジュールされたチャンクに分割されます。
- 報酬配布フェーズ：アクティブなステークアカウントの事前計算済みエポック報酬は適切に配布されます。
プロセスを容易にするために、Sysvarアカウントを作成し、監視します。EpochRewards,報酬の配布を追跡し、配布フェーズ全体で報酬の配布を確認します。EpochRewards Sysvarは、報酬の配布フェーズが進行中であるかどうか、およびスナップショットから再開するために必要な情報を記録します。
報酬の計算
リワードの計算はエポックの最初のブロックで行われます。計算が行われると、リワードは銀行に格納された分配チャンクに分割され、リワード分配フェーズ中に配布されます。
報酬配布フェーズ中のブロック処理時間への影響を最小限に抑え、各ブロックが報酬のサブセットを確定的な方法で配布するために、ブロックあたり4,096のステーク報酬の配布目標が設定されます。ステークアカウントの数の急激な増加に対する保護策として、エポック内の総スロット数の10％を上限としてブロック数が制限されます。このブロック上限に到達した場合にのみ、パーティションごとのアカウントが4,096の目標を超えることが許可されます。
報酬配布
報酬配布は、報酬計算フェーズの直後、エポックの2番目のブロックから開始されます。報酬の配布は通常のトランザクション処理の前にブロックの先頭で行われます。
その結果、ユーザーは以前よりも数ブロック遅れて報酬がステークアカウントに入金される場合があります。ただし、エポック境界の最初のブロック時間が長くなったため、ユーザーのステークアカウントへのアクセスが遅れるという全体的な体験は同様です。このアプローチの追加の利点は、非ステーキングトランザクションがスムーズに処理され続けることです。以前は報酬の分配中にブロックされていました。
投票アカウントの数が比較的少ない（約1,500）ため、エポック境界の最初のブロックでの投票報酬の配布メカニズムは変更されません。ステーク報酬のみが複数のブロックに分散して配布されます。
セントラルスケジューラはデフォルトでオンになりました
v1.18アップデートで機能リリースとして最初に紹介された中央スケジューラー（以前は「スケジューラー」として知られていた）は、デフォルトで有効になっておらず、バリデータを起動する際にオペレータが —block-production-method central-scheduler フラグを使用して有効にする必要がありました。現在はデフォルトでオンになっています。以前のスケジューラー実装には、パフォーマンスに悪影響を与える可能性があるいくつかの問題がありました。トランザクション処理のボトルネックは、トランザクションの順序付けと優先順位付けに不一致や不安定さを引き起こすことがよくありました。
新しい実装は、それぞれが独自のトランザクション優先順位と処理を管理する4つの独立したバンキングスレッドの以前のモデルを置き換えます。この改訂された構造では、中央スケジューラーがTPUのSigVerifyステージからトランザクションを唯一の受信者として受け取ります。優先度キューを構築し、競合するトランザクションの処理と優先順位付けをより良く管理するために、依存グラフ（prio-graphとも呼ばれる）を展開します。この新しいスケジューラーの設計により、以前のロックの競合が増加する心配なしに、スレッド数を増やすことができるため、スケーラビリティと柔軟性が向上します。中央スケジューラーの最初の導入は、多くのオペレーターの収益に改善をもたらし、より良い報酬を生み出すことが示されています。Solana v1.18のアップデートに関する以前のHeliusの投稿でも詳しく説明されています。中央スケジューラがどのように機能するか.
ZK ElGamal証明プログラム
1.17リリースに含まれる予定だったZK Token Proofプログラムは非推奨となり、より多目的でアプリケーションに依存しないものに置き換えられます。ZK ElGamal証明プログラム.新しいZK ElGamalプルーフプログラムは、公開鍵の有効性やElGamal暗号文内で暗号化された値の範囲の検証など、アプリケーション全体に広く適用されるZKトークンプルーフプログラムの部分を保持しています。ただし、SPLトークンの転送手順に必要なゼロ知識証明の検証など、アプリケーション固有の要素は省略されています。新しいZK ElGamal Proofプログラムは、アドレスの組み込みプログラムのリストに組み込まれますZkE1Gama1Proof11111111111111111111111111111.
ZKトークンプルーフプログラムの詳細については、Heliusブログの元の記事.
Get-Sysvar Syscall
Syscallsまたはシステムコールは、オペレーティングシステムカーネルからサービスを要求します。Solanaの文脈では、SyscallはSolana仮想マシン（SVM）内で実行されているプログラムが外部リソースやサービスとやり取りすることを可能にします。
Sysvarsは、最近のブロックハッシュやエポック報酬などのクラスタの状態情報を公開します。これらのアカウントは既知のアドレスに配置されます。プログラムはSysvarアカウントを介してSysvarsにアクセスするか、Syscallを介してクエリすることができます。オンチェーンプログラムは、さまざまなユースケースに対して多くのSysvarsを使用し、特定のSysvarsはネットワークの運用に不可欠です。
最初に提案されたGet-Sysvar SyscallSIMD-127 by Anza エンジニア Joe Caulfieldでは、Sysvar データにアクセスするための統一された Syscall インターフェイスが導入されています。このアップグレードにより、SlotHashes や StakeHistory など、以前はアクセスできなかった Sysvar データを取得できるようになります。この新しいインターフェイスを使用すると、開発者は Sysvar データの特定のフラグメントにアクセスできます。SlotHashes::get_slot(スロット)そしてStakeHistory::get_entry(epoch)—データ構造全体を複製する必要はありません。
この更新では、Sysvarデータレイアウトを変更したり新しいSysvarsを追加する際のオーバーヘッドも最小限に抑えられます。以前は、新しいSysvarごとに対応するSyscallの追加が必要であり、時間の経過とともにSyscallインターフェースが膨れ上がり、メンテナンスが複雑化していました。今では、単一のsol_get_Sysvar SyscallがすべてのSysvarインターフェースを提供し、どのSysvarからも一貫して効率的にデータを取得できるようになりました。
新しいSyscallの導入により、Sysvarsの変更と新規追加のプロセスが簡素化されます。これにより、Syscallインターフェースの複雑さとメンテナンス要件が大幅に削減されます。さらに、このアップデートにより、BPFプログラムがSysvarデータにアクセスできるようになり、トランザクションサイズに影響を与えずにオンチェーンプログラムがより多くのSysvar情報を読み取ることが可能になります。
GetEpochStake Syscall
新しいGetEpochStake システムコール現在のエポックのための投票アカウントの委任ステークを取得するための要求の非常に高い機能を導入します。これにより、この情報をオンチェーンでより効率的かつ直接的に取得する方法が提供されます。
現在、プログラムは、現在のエポックの特定の投票アカウントに委任されたステークのリアルタイムデータにアクセスできないため、バリデーターガバナンスや二次コンセンサスメカニズムなどのユースケースの障壁となっています。このデータのオンチェーンクエリを有効にすることで、これらのアプリケーションのロックが解除され、将来のユースケースへの道が開かれます。
GetEpochStakeを使用すると、開発者は32バイトの投票アカウントアドレスを提供し、システムコールはその投票アカウントに現在委任されている総アクティブステークを表すu64整数を返します。提供されたアドレスが有効な投票アカウントに対応していないか存在しない場合、システムコールは単に0を返します。
MoveStakeとMoveLamports
2つの新しいステークプログラム命令MoveStake と MoveLamportsは、ステークアカウント間の価値移転を容易にするために導入されています。これらの指示は、最初にSIMD-0148 (英語)、引き出し権限の制御なしに、一致する権限を持つアカウント間で資金の移動を許可することにより、開発者を支援します。
以前、ユーザーのステークを管理するプロトコルは、複数のバリデータにステークを分割し、定期的に再委任する際に課題に直面していました。プロトコルがユーザーのステークを非アクティブ化するためにステークを分割する場合、新しいアカウントのためにレントの免除ラムポートを資金提供する必要があります。プロトコルは、これらの分割されたアカウントをマージする際にレントの免除ラムポートを回収することはできません。
MoveStake:この命令により、アクティブなステークをアカウント間で移動し、あるアクティブなアカウントから別のアカウントに、またはアクティブなアカウントから非アクティブなアカウントに転送して、アカウントを再アクティブ化できます。ソースアカウントの委任全体が移動すると、ソースアカウントは非アクティブになります。家賃免除残高はすべてのシナリオで変更されず、アクティブなアカウントに対して最小委任ルールが維持されます。
MoveLamports：「MoveLamports」は、アクティブまたは非アクティブなアカウントから別のアクティブまたは非アクティブなアカウントに余剰のlamportsを移動します。「余剰のlamports」とは、委任されたステークでもなく、家賃免除に必要なものでもないlamportsのことを指します。MoveLamportsは、マージされたアカウントからlamportsを回収したり、未使用の資金を統合したりするなどのメンテナンス作業を可能にします。
実装を効率化するため、これらの変更はアカウントの有効化や無効化をサポートせず、一部のアクティブなステークアカウントにも影響を与えません。これらの新しいプログラムの指示は既存の機能に影響を与えません。
おまけ:Solana-SVMクレート
Agave 2.0のリリースとともに、ブランド-ニューなsolana-svmクレート開発者に対して、フルバリデータフレームワークに依存しないスムーズなAPIを通じて、コアSVMコンポーネントへの直接アクセスを提供しています。これにより、バリデータ以外のアプリケーション（オフチェーンサービス、軽量クライアント、ステートチャネル、ロールアップなど）にSolanaの高性能トランザクション処理が開放されます。
APIをランタイムの他の部分から分離することにより、このクレートはBankインスタンスなどのコンポーネントが不要になり、運用オーバーヘッドが削減されます。開発者は、メインネットベータをサポートする堅牢なコンポーネントを使用して、軽量クライアント、状態チャネル、ロールアップ、オフチェーンサービスなどのカスタムSVMプロジェクトを構築できます。このAPIのコアはTransactionBatchProcessor構造体であり、アプリケーションは、BPFローダー、eBPF、および仮想マシンを含む下流のAgaveコンポーネントの全機能を備えた、サニタイズされたSolanaトランザクションのバッチを処理できます。
上:トランザクションバッチプロセッサ(画像出典:Anza)
ディープダイブを読むアンザの新しいSVM APIこのエキサイティングな開発の詳細については、gateをご覧ください。
RPCエンドポイントが削除されました
廃止および非推奨の v1 Agave RPC エンドポイントが複数削除されました。Helius Devrel チームは、これらのエンドポイントを使用しているすべてのお客様に連絡を取りました。内部分析を通じて、削除が予定されている次のエンドポイントを積極的に使用している少数の顧客グループを以前に特定しました。
getRecentBlockhash、getConfirmedSignatureForAddresses2、getConfirmedTransaction、getConfirmedBlock、getStakeActivation、getFees
再度、すべての開発者に対して、これらの呼び出しに対する参照を確認し、提案された置換で適切に更新することを強くお勧めします。
上記：削除予定の完全な旧式および非推奨のv1 Agave RPCエンドポイントの一覧
N.B. 画像に示されているgetAccountInfoの代替アプローチは次のとおりです見つかりました.
SDKの変更には、gateが含まれています。
- Borsh v0.9 のサポートが削除されたため、v1 または v0.10 (#1440)
- コピー特性はもはや派生されませんRentとEpochScheduleでの切り替え。clone()の使用に切り替える
- solana-sdk: 非推奨の記号) removed
- solana-program: 廃止されたシンボルが削除されました
バリデーターオペレーターの場合、Agave v2.0のリリースに伴い、いくつかの廃止されたバリデーター引数が削除されます。これらの完全なリストはこちらで見つけることができますここ.
結論
Agave 2.0のアップデートは、Solanaにとって重要な進歩を示しており、多数の機能実装やランタイムの最適化が組み込まれています。このリリースは、強力な新しいSyscalls、拡張機能、包括的なメンテナンスを継続して推進し、クレートの名前変更、非推奨のRPCメソッドの削除、スムーズなバリデーター引数などを含んでいます。Agave 2.0はSolanaの機能を拡張し、パフォーマンスと使いやすさを洗練させています。開発者、バリデーター、またはアクティブユーザーであるかにかかわらず、Agave 2.0のアップデートにより、Solanaエコシステムのすべての人にとって新しい可能性が開かれます。
追加リソース/さらに読む
免責事項：
関連記事
PayFiとは何ですか、そしてなぜPayFiにはソラナが使用されていますか？
CKBの進化を探る