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

はじめに

Agave 4.4では、Solanaの中核バリデータクライアントがAlpenglowの導入を基盤として、ブロック検証の簡素化、ステーキング報酬計算の効率化、プログラムやアカウントデータの保存に必要なSOLの削減を進めます。これらの変更により、日常的な運用効率が向上するとともに、非同期実行に向けた基盤がさらに整備されます。最近、目標スロット時間が200msに短縮されたことで、エポックも約1日に短縮され、機能ゲートをさらに速いペースで有効化できるようになりました。

Agave 4.4リリースサイクルの主なアップデート

• 無効な手数料支払者の許可： 非同期実行の実現に向けた重要な一歩です
• プログラムの自動リサイズ： プログラムのアップグレード時に余剰レントを返還します
• シュレッドの標準化： プロトコルでデータ32個、コーディング32個のFECセットを必須化します
• 非アクティブなステークの除外： 報酬計算から非アクティブなステークを除外します
• レント削減： 状態保持に必要な保証金を90%削減する計画の最終3段階です

無効な手数料支払者の許可

SIMD-0290：手数料支払者の制約緩和の機能ゲートは、Agave 4.4のリリースサイクル中に有効化される見込みです。これにより、たとえばSOL不足などの理由で手数料支払者の検証に失敗するトランザクションがブロックに含まれている場合の処理が変わります。従来は、そのようなトランザクションが含まれるとブロック全体が無効になっていました。新しいコンセンサスルールでは、トランザクションはブロック内に残り、バリデータは実行をスキップするため、アカウント状態は変更されません。

手数料支払者の残高は、それより前のトランザクションが実行されることで変化する可能性があります。そのため、すべてのトランザクションに有効な手数料支払者を求めると、バリデータはブロックが有効かどうかを判断する前に、先行する一部のトランザクションを実行しなければなりません。手数料支払者の検証に失敗したトランザクションをスキップ扱いにすることで、この依存関係が解消されます。

これは、バリデータが実行完了前にブロックとトランザクションの順序について合意できる、非同期実行に向けた基盤整備です。実行は別途進められ、合意済みのトランザクションがアカウント状態に適用されます。Solanaは、ブロック時間の短縮や複数の同時ブロック提案者といった将来の改善を実現するため、この設計へ移行しています。

Agaveでは、こうしたスキップ対象のトランザクションをno-opとして扱います。命令は実行されず、手数料も支払われません。ただし、要求されたリソース予算またはデフォルトのリソース予算の全量に基づいてブロック容量を消費するため、リーダーが含められる数には制限があります。また、この実装では、バリデータがブロックのリプレイ時にこれらを受け入れられる一方で、リーダーはブロック生成時に引き続き除外できます。

SIMD-0290は、存続期間の指定に最新のブロックハッシュを使用するトランザクションにのみ適用されます。Durable nonceトランザクションには追加対応が必要で、これはSIMD-0297：無効なノンストランザクションに関する制約緩和で別途扱われます。この変更には完全な後方互換性があり、これまで有効だったすべてのトランザクションとブロックは引き続き有効です。

アップグレード時のプログラム自動リサイズ

Agave 4.4には、SIMD-0433：Loader V3：プログラムデータをELFの長さに設定の機能ゲート有効化が含まれます。これにより、プログラムのアップグレード時に、コンパイル済みコードを保存するアカウントのサイズが自動調整されます。

Loader v3（現在、Solanaプログラムのデプロイとアップグレードに使用されるデフォルトのローダー）は、プログラムのコンパイル済みELFバイナリを、アップグレード権限などのメタデータとともにProgramDataアカウントへ保存します。従来、開発者はこのアカウントを拡張することしかできず、縮小はできませんでした。そのため、より小さなバイナリへアップグレードしても未使用領域が残り、その領域をレント免除状態に保つために必要なSOLがアカウント内にロックされたままでした。

この変更により、Upgrade命令は、メタデータヘッダーと新しいELFの長さを合計したサイズにアカウントを調整します。バイナリが小さくなる場合、余剰lamportはアップグレードのスピルアカウント、つまり残余資金の受取先として指定されたアカウントへ送られます。バイナリが大きくなる場合はアカウントが自動的に拡張されるため、通常のアップグレードでは個別の拡張手順が不要になります。ProgramDataアカウントとバッファアカウントには、新しいレント要件を満たす十分なlamportがあらかじめ必要です。不足している場合、アップグレードは失敗します。

そのため、より小さなバイナリを採用する開発者は、次回のアップグレード時にSOLを回収できます。以前に確保されていた予備容量も削除されます。CPIを通じて呼び出されるアップグレードには、引き続き10 KiBのアカウント拡張上限が適用されます。これを超える拡張には、事前の拡張またはトップレベルのアップグレード命令が必要です。返還分が意図した受取先に届くよう、開発者はアップグレード前にスピルアカウントの送付先を確認する必要があります。

この変更は、Pinocchioのような、より新しく高性能なライブラリやフレームワークへのアップグレードを開発者に促します。また、Accounts DB内でプログラムが占有する容量も削減されます。

シュレッドの標準化

Agave 4.4では、SIMD-0317：データシュレッド32個+コーディングシュレッド32個の強制で定められたSolanaのブロック伝播ルールが厳格化されます。これにより、バリデータがブロックデータの配布と復元に使用する構造が標準化されます。

SolanaはTurbineを通じてブロックを配布します。Turbineはブロックデータをシュレッドに分割し、複数層のバリデータを経由して中継します。シュレッドは前方誤り訂正（FEC）セットにまとめられ、データシュレッドと、復元情報を含むコーディングシュレッドが組み合わされます。データ32個、コーディング32個で正しく構成されたセットでは、受信側は64個のシュレッドのうち任意の32個から元のデータを復元できるため、パケット損失への耐性が高まります。

各シュレッドには、そのシュレッドをセットのMerkleルートに結び付けるMerkle証明も含まれ、リーダーの署名によって認証されます。64個のシュレッドからなるセットの場合、この証明にはリーフからルートまでの6階層に対応する6つのエントリがあります。Agaveの証明サイズチェックでは、この固定された32:32構造に対応するサイズが要求されます。

クライアントはすでにセットごとにデータシュレッド32個とコーディングシュレッド32個を生成していますが、受信側のバリデータは従来、より柔軟な構成も受け入れてきました。SIMD-0317では、固定された32:32構造をプロトコル要件にすることで、この差を解消します。これにより検証が簡素化されます。受信側は、コーディングシュレッドからセットの構成が判明するのを待たずに、有効なシュレッドインデックスの境界を判断できます。

固定構造により、リーダーが同じデータの競合するバージョンを配布するequivocationの検出も簡素化されます。同じFECセットに属し、異なるMerkleルートと有効なリーダー署名を持つ2つのシュレッドが、その競合の証拠になります。そのため、フォーマットの標準化は実装の複雑さを軽減するとともに、equivocationを特定しやすくします。

報酬計算から非アクティブなステークを除外

Agave 4.4のリリースサイクルでは、SIMD-0599：ステーク委任から非アクティブなステークを削除の機能ゲートが有効化される予定です。これにより、各エポックの開始時に分割エポック報酬を処理する際の、非アクティブなステークアカウントの扱いが簡素化されます。非アクティブなステークアカウントには、レント免除に必要な最低額を超えるSOLが保持されている場合がありますが、アクティブまたはアクティブ化中のステークはありません。そのSOLは委任されていないか、無効化が完全に完了しています。

これらのアカウントはプロトコル報酬を獲得しませんが、含めることで報酬配布パーティションの数や、アカウント状態の追跡に使用するラティスハッシュに影響する可能性があります。すべてのバリデータクライアントはこの動作を正確に再現する必要があり、コンセンサスに不可欠なコードへ不要な複雑さが加わっています。

この変更では、報酬対象エポック中に非アクティブだったステークを除外し、アクティブ化中、アクティブ、無効化中のステークは残します。したがって、新しいエポックの開始時に非アクティブになったステークアカウントも、無効化中だった直前のエポックで獲得した報酬を引き続き受け取れます。

さらなるレント削減

Agave 4.4では、Solanaが段階的に進めているレント削減の最後の3段階が有効化される見込みです。SIMD-0437で定められた計画に基づき、アカウントストレージ1バイトあたりに必要な最低残高は、5段階を経て当初の6,960 lamportから696 lamportへ引き下げられます（90%の削減）。

各段階には個別の機能ゲートが設けられているため、ネットワークは次の段階へ進む前に、アカウント作成や状態増加への影響を評価できます。

この要件を引き下げることで、トークンアカウント、PDA、その他のオンチェーン状態を作成する際に、開発者やユーザーが確保しなければならない資金が減少します。大規模な決済サービスなど、ユーザーに代わってアカウント作成費用を負担するアプリケーションには特に有用です。

Ghostの推計によると、300万SOL超（~3億ドル）を回収できます。ユーザーがアカウントから余剰SOLを回収できるよう、複数のツールが開発されています。

まとめ

Agave 4.4の主要な変更はAlpenglowを基盤としながら、長く待ち望まれていたステーキング報酬、プログラムのデプロイ、アカウントコストの改善を前進させます。これらにより、Solanaはより高速で利用しやすいネットワークへと進み続けます。次はBreakpoint London、その後はAgave 4.5です。

関連リソース

• Agave 4.4リリーススケジュール
• 機能ゲートトラッカーのスケジュール
• Agave 4.4変更履歴
• Agave 4.4プルリクエスト