Agave 4.2アップデート：知っておくべきこと
はじめに
Agave 4.2により、Solanaの中核となるバリデータクライアントはさらなる進化を遂げます。このメジャーリリースの中心となるのは、待望されていた3つのフィーチャーゲート付きアップグレードです。200msのスロット時間、ステートボンドの90%削減、新しいtransaction v1形式による4,096バイトのトランザクションが導入されます。また、次のリリースで予定されている有効化に先立ち、Alpenglowの全機能を実装しています。さらに、XDP送信がデフォルトで有効になりました。
Agave v4.2は、Solana史上最も驚異的なクライアントアップグレードになります。
主なアップデート
- 新しいTransaction v1標準によりトランザクションサイズが3.3倍に拡大 *
- ステートボンド（Rent）を90%削減 *
- スロット時間を200msに短縮 *
- Alpenglowの全機能を実装
- 新しいガバナンスツール（SIMD関連）
* フィーチャーゲート付きアップグレード
Agave 4.2では、いくつかの破壊的変更が導入されます。移行ガイドを確認し、フィーチャーゲートが有効になる前に、エージェントスキルを使用してリポジトリを監査してください。
より大きなトランザクション（Transaction v1）
Agave 4.2のリリースサイクルでは、長年の上限である1,232バイトから最大4,096バイトへとトランザクションサイズを拡大するフィーチャーゲートが有効化されます。SIMD-0296：より大きなトランザクションサイズで正式に定義されているこの上限は、約3.3倍の増加に相当し、SIMD-0385：Transaction V1形式で導入された新しいtransaction v1形式にのみ適用されます。Legacyおよびv0トランザクションは変更なしで引き続き動作し、既存の1,232バイトの上限が適用されます。
開発者にとって、これは命令データ用の領域が増えるだけの変更ではありません。これまで1つのトランザクションに収まらなかった暗号学的証明、マルチシグ承認、大規模なアカウントリストなどのペイロードを、プロトコルネイティブな単一のアトミック操作として実行できるようになります。この変更によって、Solanaのコンピュート、アカウント、署名、命令数の上限が引き上げられるわけではありません。
元の1,232バイトという上限は、Solanaの初期のネットワークアーキテクチャに由来します。トランザクションは個別のUDPデータグラムとして送信され、IPv6の最小最大伝送単位（MTU）である1,280バイト以内に収める必要がありました。40バイトのIPv6ヘッダーと8バイトのUDPヘッダーを差し引くと、トランザクション本体に残るのは1,232バイトでした。各トランザクションを単一パケットに収めることで、フラグメンテーションを減らし、より予測可能な送信を実現していました。
SolanaはすでにUDPからトランザクション取り込み用のQUICへ移行しています。QUICストリームは単一のネットワークデータグラムのペイロードに制限されないため、従来の1,232バイトという上限は不要になりました。クライアントには、アドミッション制御、メモリ割り当て、コンセンサス検証のために明示的な上限が引き続き必要です。しかし今では、IPv6 MTUではなく、ランタイムやアプリケーションの要件に応じて上限を設定できます。
アカウントリストは、既存のサイズ割り当てのかなりの部分を占めることがあります。Ed25519公開鍵またはプログラム派生アドレスはそれぞれ32バイトを使用し、トランザクションでは命令が読み取りまたは変更するすべてのアカウントを指定する必要があります。そのため、完全なアカウントキーを約32個までしか格納できないという実質的な上限がありました。これを回避するため、V0トランザクションではAddress Lookup Tables（ALT）が導入されました。各32バイトのキーを1バイトのテーブルインデックスに置き換えることで、ランタイム上限である64アカウントまでトランザクションに含められます。
ALTは効果的な圧縮手段ですが、残念ながら複雑さも伴います。アプリケーションは、オンチェーンでルックアップテーブルを作成し、管理する必要があります。未加工のv0メッセージをデコードするRPCサービスやインデクサーは、トランザクションメタデータまたは該当するテーブルの状態を使用して、完全なアカウントリストを再構築しなければなりません。参照先のALTがすでに閉じられ、オンチェーンで利用できなくなっているトランザクションを解析する際には、これが課題になります。
v1トランザクションでは、現在ALTを通じてサポートされている完全なアカウントセット（2,048バイトを占める64個の完全な公開鍵）を格納できるため、この開発上の課題が解消されます。そのため、v0から移行するアプリケーションは、ルックアップテーブルのエントリを解決し、得られたアドレスをv1トランザクションに直接含められます。
さらに、1,232バイトというトランザクションサイズは、ネイティブプリコンパイルがないゼロ知識証明やBLS実装などの暗号機能にとって、特に厳しい制約です。こうしたワークロードでは、数百から数千バイトの証明または署名データを扱うことがあります。4,096バイトの上限であれば、一般的な暗号ユースケースの多くに対応できます。
Transaction V1の仕様
シリアライズされたv1トランザクションは、バージョンバイト0x81から始まります。その後に、3バイトのLegacy形式メッセージヘッダー、32ビットのトランザクション設定マスク、32バイトの有効期間指定子、命令数とアドレス数、32バイトアドレスの完全な配列、設定値、固定サイズの命令ヘッダー、連続した命令ペイロード、最後に署名が続きます。
VersionByte (u8)
LegacyHeader (u8, u8, u8)
TransactionConfigMask (u32) -- Bitmask of which config requests are present.
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- Length matches NumAddresses
ConfigValues [[u8; 4]] -- Length equal to the popcount (number of set bits)
of TransactionConfigMask. See section TransactionConfigMask for details.
InstructionHeaders [(u8, u8, u16)] -- Length of NumInstructions. Values are
(ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- Length = NumInstructions.
Each InstructionPayload is the concatenation of the following byte arrays:
InstructionAccountIndexes [u8] -- Length = NumInstructionAccounts from the
corresponding InstructionHeader
InstructionData [u8] -- Length = NumInstructionDataBytes from the
corresponding InstructionHeader
Signatures [[u8; 64]]命令ヘッダーには、プログラムアカウントのインデックス、命令アカウント数、命令データ長が明示的に記録されます。そのため、各命令のペイロードを解釈しなくても、メッセージの境界を特定できます。
V1トランザクションの上限は、署名12個、アカウントアドレス64個、命令64個、命令ごとのアカウントインデックス255個です。大規模なトランザクションも、要求されたコンピュートユニット上限、ロード済みアカウントデータ上限、アカウントロック規則、ブロックで利用可能な実行容量の範囲内に収める必要があります。
既存のパーサーは、v1を単に最大長が拡大されたv0として扱うことはできません。シリアライズされたトランザクションを検査するインデクサー、RPC、SDK、署名インフラストラクチャは、0x81プレフィックスを認識し、新しいフィールド順序を実装する必要があります。特に、v1の署名は、Legacyおよびv0トランザクションのようにメッセージの前ではなく、トランザクションの末尾に配置されます。
Transaction v1では、Compute Budgetプログラムの設定命令がトランザクションヘッダー内のフィールドに置き換えられます。先頭の`TransactionConfigMask`では、トランザクションの以下の項目を宣言できます。
- lamports単位の優先手数料の合計
- コンピュートユニット上限
- ロード済みアカウントデータサイズの上限
- 要求するヒープサイズ
設定された各ビットは、対応する4バイトの設定値を示します。64ビットの優先手数料は、マスク上の2つの位置を使用します。このマスクは、将来のトランザクションバージョンで拡張できるよう設計されています。
ステートボンド（Rent）の削減
一般に「rent」と呼ばれる高額なステートボンド要件は、アカウントを多用するアプリケーションにとって、今なおSolanaの大きな障壁の1つです。rentは継続的なストレージ料金ではなく、アカウントの状態がオンチェーンに存在する限り保持しなければならない返還可能なボンドであるため、この名称はやや誤解を招きます。通常、アカウントを閉じるとlamportsを回収できますが、それまでは開発者またはユーザーが事前に用意し、固定しておかなければならない資本となります。
Agave 4.2では、SIMD-0437：lamports_per_byteを696まで段階的に削減のフィーチャーゲート付き実装が導入されます。これにより、`lamports_per_byte`定数が6,960から696に削減されます。これはrent（より正確にはrent免除最低残高）の90%削減です。削減は、6,960 → 6,333 → 5,080 → 2,575 → 1,322 → 696という5つの独立したフィーチャーゲートを通じて実施されます。
いずれかのゲートが有効になると、AgaveはBankのrent設定を更新し、Rent sysvarを通じて新しい値を公開します。段階的な展開により、各価格水準でアプリケーションがどのように反応するかをネットワークで観察できます。また、ステートの増加やバリデータのリソース使用量に懸念が生じた場合は、次の削減前に停止できます。
アカウントのrent免除最低残高は、割り当てられたデータサイズに固定の128バイトのストレージオーバーヘッドを加えて計算されます。
minimum_balance = (128 + account_data_size) × lamports_per_byte
この変更でも、rentの仕組み自体は変わりません。アカウントには引き続き最低残高が必要で、アカウントを閉じるとその残高を回収できます。変更されるのは、ボンドとして必要なSOLの量だけです。
標準的なSPL Tokenアカウントは165バイトです。128バイトのオーバーヘッドを含めると、実効サイズは293バイトになります。rentを90%削減すると、このようなアカウントに必要なSOLは約~0.16ドルから2セント未満になります。
これは、ステーブルコイン決済、トークン配布、ロイヤルティシステム、直接エアドロップにとって特に重要な意味を持ちます。ウォレットはSPLトークンを直接保持するのではなく、通常はmintごとにAssociated Token Account（ATA）が必要です。受取人が必要なATAをまだ持っていない場合、送信者は送金と同時に作成できますが、受取人のrent免除残高も用意しなければなりません。これは通常、以後の支払いごとに発生する費用ではなく、ウォレットとmintの組み合わせごとに一度だけ発生するオンボーディングコストです。それでも、大規模になると、企業がオンボーディング費用を負担するか、ユーザーに転嫁するかを左右するほどの金額になる可能性があります。
Solanaのステート増加
ステートボンドを引き下げると、攻撃者が不要なステートを作成し、保持するために固定しなければならない金額も減るため、段階的な削減が重要です。Solanaのステートは複製、インデックス化、スナップショットへの組み込みが行われ、すべてのバリデータによって維持されます。そのため、永続的なステートの増加は、最終的にディスク要件、AccountsDBの処理、運用コストに影響します。
Solana Foundationによる最近の分析によると、推奨割り当てが1 TBであるのに対し、AccountsDBのストレージファイルは約495 GBを占めています。計画されているrent削減後にこの余剰容量を使い切るには、攻撃者は約1,720万ドル相当のSOLを投入する必要があります。推奨されるバリデータのストレージ割り当てを2 TBに倍増すると、攻撃者に必要な資本は5,100万ドルに増加します。
新しいアカウントの作成と古いアカウントの閉鎖を考慮した結果、ステートは1日あたり約0.3 GB増加していることが分かりました。
エポック997で取得されたステートのスナップショットから、ステート消費が特定の領域に大きく集中していることが分かります。SPL Tokenアカウントが最大のカテゴリで、OpenBookとSerumのアカウントは稼働中のステートの約30%を占めていました。これは、オンチェーンオーダーブックの複雑なアーキテクチャを反映しています。また、この分析では、SPL Tokenの領域の約30%がPump.funのトークンローンチパッド型アセットに関連すると推定されています。
安全対策
ステートボンドを安全に削減するには、逆方向へ戻せる実行可能な手段が必要です。ランタイムに追加の変更を加えず、後からrent免除最低残高を引き上げると、既存のアカウントは即座に新しい基準を下回ります。追加のステートを割り当てていない場合でも、これらのアカウントを書き込みロックするトランザクションが失敗し、広範な混乱につながる可能性があります。
そこで、SIMD-0392：Rent引き上げに対応するためのランタイム変更では、実行後の最低残高ルールを変更し、rentが引き上げられた場合でも既存アカウントに従来の条件を適用できるようにします。アカウントがすでに存在し、サイズが増加せず、所有者も同じである場合、許容される最低残高は次のいずれか低い方になります。
- 現在のrentレートに基づく最低額
- アカウントの実行前残高
新しいアカウントは、引き続き現在のrent免除最低残高を満たす必要があります。割り当てサイズを増やすアカウントや、所有者を変更するアカウントも同様です。残高ゼロは、引き続きアカウントの閉鎖を表します。これにより、既存のステートは以前のボンド額で動作を継続でき、新たに割り当てられるステートには最新のレートが適用されます。
SIMD-0438：rent免除最低残高引き上げのためのセーフガードでは、`lamports_per_byte`を従来の値である6,960に戻す、独立した保護用フィーチャーゲートが追加されます。このゲートは、rentの削減によってステートが過剰に増加した場合や、その他の重大な運用上の問題が発生した場合にのみ有効化することを想定しています。削減開始前からゲートが存在するため、ステート増加の問題が発生している最中に、コア開発者が新たなコンセンサス変更を設計、レビュー、デプロイする必要はありません。
5つの削減ゲート、SIMD-0392の既存条件適用ルール、SIMD-0438のフォールバックにより、プロトコルレベルで展開を元に戻せます。ネットワークはボンドを段階的に引き下げ、稼働中のステートとバリデータストレージの挙動を観察し、中間値で停止できます。また、すべての既存アカウントに即座の残高補充を求めることなく、元の要件に戻すこともできます。
200msへのスロット時間短縮
Solanaで最も期待されているパフォーマンス向上の1つが、目標スロット時間を400msから200msへ短縮することです。主な利点はレイテンシの低減です。200msのスロットでは、Solanaの4スロットのリーダーウィンドウが1.6秒から800msへ短縮されます。これにより、確認時間が短くなり、悪意のあるリーダーがトランザクションを遅延、並べ替え、選択的に取り込める時間も制限されます。また、スロットの短縮により、オラクル利用者やマーケットメーカーなどのアプリケーションは、オンチェーン上のタイミングをより細かく扱えるようになります。
この提案は、Solanaの既存の経済性とスループットを維持するよう設計されています。インフレパラメータ、AlpenglowにおけるValidator Admission Ticketのコスト、スロットごとの処理上限は比例して調整されます。ただし、Alpenglowより前に200msスロットが導入された場合、バリデータは2倍の頻度で投票する必要があるため、投票コストが約2倍になる可能性があります。
200msスロットの詳細については、Agave 4.1の解説記事をご覧ください。
その他の注目すべきアップデート
Agave 4.2のリリースサイクルでは、規模は小さいものの注目すべき改善がいくつか有効化される予定です。
Alpenglowへの対応
Agave 4.2にはAlpenglowの全機能が実装されていますが、新しいコンセンサスプロトコルはmainnetでは有効化されません。コアエンジニアリングチームは、Agave 4.3で予定されているコンセンサス移行に向け、このリリースサイクルを追加のテスト、監査、堅牢化に使用しています。そのため、4.2を実行するバリデータには、Votor投票エンジンとそのBLS証明書検証コンポーネントを含む、Alpenglowの完全な実装がすでに組み込まれています。
コードのセキュリティレビューを拡大するため、Anzaは賞金総額最大50,000 SOL、応募期間8月5日から19日までのAlpenglowバグバウンティコンテストも実施します。Alpenglowは、開発、モノレポへの移行、内部監査の期間中、常設のAgaveバウンティの対象外でした。このコンテストによって初めてバウンティの対象となり、以前のレビューで見逃された可能性のある問題の発見を目指します。
Stake Programの浮動小数点から固定小数点への移行
Agave 4.2のリリースサイクルには、SIMD-0391：Stake Programの浮動小数点から固定小数点への移行のフィーチャーゲート付き実装も含まれます。Stake Programのウォームアップとクールダウンの計算で使用するIEEE-754浮動小数点演算を、決定論的な固定小数点整数演算に置き換えます。主な目的は、浮動小数点演算をサポートしていない標準のeBPFツールチェーンとの互換性を確保することです。SolanaのSBFツールチェーンでは、決定論的なソフトウェア浮動小数点ルーチンを使用してエミュレートできますが、これは非効率であり、Stake Programの`no_std`実装への移行を妨げています。
ほとんどのアプリケーションでは変更は不要です。ただし、有効なステーク、アクティベート中のステーク、またはディアクティベート中のステークを独自に再現するインデクサーやステーキングツールは、機能が有効になった時点で新しい整数演算ルールを実装する必要があります。
新しいガバナンスツール
Agave 4.2のリリースサイクルでは、昨年から開発が進められてきた新しいガバナンスツールも公開されます。このツールは、主要な経済上およびプロトコルレベルの決定について、バリデータとネイティブステーカーの両方が自身の立場を表明できるオンチェーンプロセスを提供します。
中核となるsvmgovは、提案の作成、支持、ステーク加重投票、確定を管理するAnchorベースのプログラムです。投票ウェイトには、Node Consensus Network（NCN）が生成するエポック固有のステークスナップショットを使用します。独立したオペレーターがスナップショットを生成し、正規のMerkleルートについてコンセンサスを形成したうえで、オンチェーンに公開します。その後、バリデータはMerkle証明を使用して、自身の有効なステークを証明します。
有効なステークが100,000 SOL以上あるバリデータは提案を作成できます。一方、提案が投票プロセスへ進むには、クラスターステークの15%から支持を得る必要があります。ガバナンスリポジトリには、投票と支持状況の追跡に使用できるRust CLIとWebフロントエンドも含まれています。
完全な提案文書は、別のSolana Governance Proposalsリポジトリに保存され、特定のGitコミットに固定されます。オンチェーンの提案アカウントには、リンク、ライフサイクル状態、投票集計が保存されます。バリデータは当初、自身に委任されたすべてのステークで投票しますが、個々の委任者はSOLに対する主権を維持します。ステーカーは特定のステークアカウントについてオーバーライドを送信し、そのステークをバリデータの集計から除外して、自身の投票に従って再配分できます。
Solana Governance Proposals（SGP）は、SIMDを置き換えるのではなく補完することを目的としています。SGPはネットワークが変更を進めるべきかという方向性の問いに答え、関連するSIMDはその変更をどのように実装するかを規定します。
3つのSGPがすでに支持フェーズを通過し、新しいシステムで初となるガバナンス投票が行われます。
- SGP-0001：Solana憲法は、開発者、バリデータ、ステーカーの役割を定義し、SGPプロセスを正式に確立する、正規のガバナンス社会契約の批准を提案しています。
- SGP-0002：ディスインフレ率の倍増は、SOLの年間ディスインフレ率を15%から30%へ倍増させる一方、最終インフレ率を1.5%に据え置くことをネットワークに求めます。これにより、最終インフレ率に達するまでの推定期間は約5.7年から2.8年へ短縮されます。
- SGP-0003：リソース手数料と取り込み手数料は、既存の一律の基本手数料構造を、リーダーに支払う2,500 lamportsの取り込み手数料と、要求されたトランザクションコストユニットに基づいて全額バーンされる別個のリソース手数料に置き換えることを提案しています。優先手数料の分配は変更されません。
まとめ
Agave 4.2は、近年のSolanaで最も重要なリリースの1つです。200msの高速なスロットにより、ネットワークはリアルタイムの応答性に近づきます。ステートボンドを90%削減する計画によってアカウント作成コストは大幅に下がり、4,096バイトのtransaction v1により、複雑な命令、暗号学的証明、アカウントを多用するアプリケーションに使える領域が大幅に広がります。これらの変更により、Solanaは開発者とユーザーの双方にとって、より高速で低コスト、かつ表現力の高いプラットフォームになります。
関連資料
Heliusを購読
Solana開発の最新情報や新しい記事の公開通知を受け取れます