Agave v2.2アップデート：知っておくべきすべて

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

• 広範なパフォーマンス最適化
• ブロック上限を50M CUから60M CUへ20%引き上げ
• Accounts Lattice Hash（ALH）の導入
• Secp256r1署名検証（Agave 2.1リリースサイクルから延期）
• SBPFv1、v2、v3プログラムのデプロイと実行
• CPI呼び出し元の制限を撤廃
• Loader-v4

本記事の各セクションは独立しているため、関心のあるトピックを簡単に確認できます。バリデータ運用者、開発者、または熱心なユーザーのいずれであっても、このAgave 2.2総合ガイドから、最新の改善を最大限に活用するために必要な重要情報を得られます。

機能のロールアウト

執筆時点では、総ステークの19.8%がAgave v2.2で稼働しています。*これはネットワーク全体での導入に対する強い支持を示しています。メインネットのフィーチャーゲート有効化はアップグレード期間中、一時的に停止されており、予定された有効化手順に従って近日中に再開される見込みです。

Agave 2.2で導入された主要機能の多くは現在フィーチャーゲートで制御されており、メインネットではまだ有効になっていません。これらはSolanaのフィーチャーゲートシステムを通じ、2.2リリースサイクル全体で段階的に有効化されます。有効化のタイミングは、機能の優先度とtestnetおよびdevnetクラスターでのロールアウト順序によって決まります。最新情報はAgaveフィーチャーゲートトラッカーをご覧ください。

ブロック上限を60M CUへ引き上げ

Anzaは2025年に向け、Solanaで利用可能なブロックスペースを2倍にするという意欲的な目標を掲げています。この取り組みの一環として、SIMD-0256：ブロック上限を60Mへ引き上げが次期Solana 2.2リリースに含まれる予定です。これは現在のブロック上限から20%の引き上げとなります。

これに先立つ以前のアップグレードでは、ブロック上限が4,800万から5,000万コンピュートユニット（CU）に引き上げられ、その後もブロック時間は一貫して目標の400ms未満に維持されました。最近のデータでは、ブロックが日常的に50M CUの上限に達しており、さらなるスケーリングの準備が整っていることを示しています。

注：Firedancerダッシュボードのレポートロジックにハードコードされた定数があるため、一部のブロックは充填率104%と表示されます。

このアップデートでも、その他のプロトコル上限は変更されません。

• ブロックごとのアカウント単位のコンピュートバジェットは1,200万CUのままです。
• トランザクションごとの最大コンピュート量は引き続き140万CUが上限です。
• ブロックごとの投票トランザクションの合計コンピュート上限は3,600万CUのままです。
• ブロックごとの新規アカウントデータ割り当て上限は引き続き100 MBです。

ブロック上限の引き上げはユーザー体験に直接影響します。ネットワークスループットが向上すると、トランザクション手数料の中央値が下がり、混雑時にトランザクションが正常に取り込まれる可能性も高まります。

ブロック上限引き上げの課題

スループットを高める際は、2つの重要な課題に対処する必要があるため、ブロック上限を慎重かつ段階的に引き上げることが望まれます。

1. インフラストラクチャの準備状況

エコシステム全体のインフラストラクチャも、コアクライアントの最適化に追随する必要があります。特に、ユーザー体験を損なうことなく書き込みレイヤーが読み取りレイヤー（RPCノード、インデクサー、アーカイブサービスなど）を上回ることはできません。

2. 適時のブロック伝播

もう1つのボトルネックは、リーダーノードからクラスターの残りの部分へブロックを配信する処理です。ブロックが大幅に大きくなると、特に高負荷時には、ブロック配信時間が目標の400msを超える可能性があります。

差し迫った課題は、Transaction Validation Unit（TVU）の再送信ステージです。シュレッドはここを通じてクラスター全体に配信されます。Turbineのアグレッシブなファンアウト係数200により、大規模バリデータの送信パケット数は毎秒150,000パケット（PPS）に迫ります。つまり、各ノードは200個の他ノードへのシュレッド中継を担います。これを非効率に処理すると、シュレッドの滞留、不安定なリーダー交代、ネットワーク全体で一貫性のない状態ビューを引き起こす可能性があります。

この問題に対処するため、Anzaのエンジニアは現在、ブロック配信パイプラインを全面的に見直しています。チームは現在、XDP（eXpress Data Path）への移行に取り組んでいます。これはパケット処理をユーザー空間に直接公開し、カーネルをバイパスできるようにする仕組みです。このアプローチではコストの高い中間コピーがなくなり、バリデータソフトウェアがネットワークインターフェースカード（NIC）と直接通信できるようになります。

Accounts Lattice Hash（ALH）

Solanaで数十億のアカウントをサポートするには、グローバルなアカウント状態をハッシュ化するための、よりスケーラブルな手法が必要です。新たに導入された**Accounts Lattice Hash（ALH）**は、従来のMerkleベースのアカウントハッシュを、準同型ハッシュに基づく、より効率的でスケーラブルな代替手法に置き換えます。準同型ハッシュでは、最初から再計算することなく、既存のハッシュから新しいハッシュを作成できます。

Solanaは現在、2つのアカウント状態ハッシュを保持しています。

• Epoch Accounts Hash（EAH）： アカウント状態全体のMerkleルートで、エポックごとに1回計算されます。
• Accounts Delta Hash（ADH）： 1つのブロック内で変更されたアカウントのMerkleルートで、ブロックごとに再計算されます。

どちらも公開鍵でアカウントを並べ替えてMerkleツリーを構築するため、特にアカウント数の増加に伴い、パフォーマンスとスケーラビリティの課題が生じます。二重ハッシュモデルは妥協案として生まれました。EAHは正確であり、すべてのアカウント状態を含みますが、計算頻度が低い一方、ADHは頻繁に計算されますが、変更されたアカウントのみを含む部分的なものです。理想的には、Merkleツリーの再計算によるオーバーヘッドなしで、すべてのブロックにアカウント状態全体の完全かつ最新のハッシュが含まれるべきです。

Accounts Lattice Hashの仕組み

ALHは、増分更新を可能にする準同型ハッシュ関数を使用して、この目標を実現します。毎回Merkleツリーを再構築する代わりに、アカウントへの書き込み時に個々のアカウントハッシュ（LtHashes）を単純に加算または減算します。最終的に、すべてのアカウント状態を要約する単一の2,048バイトのハッシュが生成されます。重要なのは、最初から再計算することなく、ブロック単位で更新できる点です。

このアプローチの計算量はO(n)であり、MerkleツリーのO(n log n)から大幅に改善されています。コストの高い再計算を行わずに、すべてのブロックへアカウント状態全体のハッシュを含められます。

統合と廃止されるハッシュ

ロールアウトは3つの個別SIMDにまたがり、Agave 2.2リリースサイクルを通じて、それぞれに対応する独立したフィーチャーゲートが有効化されます。

• SIMD-0215：Accounts Lattice Hash
• SIMD-0220：スナップショットでAccounts Lattice Hashを使用
• SIMD-0223：Accounts Delta Hashを削除

これらの変更により、Accounts Lattice HashがADHとEAHの両方を置き換えます。ALHは各ブロックのバンクハッシュに統合され、エポック単位ではなくブロック単位で完全な状態をハッシュ化できるようになります。

パフォーマンスとトレードオフ

ALHへの移行では、ブロックごとのMerkleベースのハッシュ処理が不要になるため、バリデータのパフォーマンスが大幅に向上します。これにより、コンセンサスとスナップショット生成が効率化されます。たとえば、バリデータはブロックの確定時やスナップショット生成時にアカウントを並べ替えたり、ツリーを再構築したりする必要がなくなります。ALHの更新は単純な加算処理です。

ただし、MerkleツリーやVerkleツリーとは異なり、このアプローチは包含証明や非包含証明をサポートしません。これはライトクライアントやSimple Payment Verification（SPV）など、特定の暗号学的検証のユースケースに影響しますが、大幅な効率向上を考慮すれば、価値のあるトレードオフと見なされています。包含証明の代替手法に関する議論はこちらで確認できます。

スナップショット統合

最初のAccounts Lattice Hashの計算には大きなコストがかかるため、ALHの値はバリデータのスナップショットに永続化され、利用可能な場合は起動時に復元されるようになりました。スナップショットにはMerkleベースのSnapshot Hashesではなく、更新されたALH形式が反映されます。これにより、Solanaのストレージおよびハッシュモデルが、この新しい設計を中心にさらに統一されます。

ネイティブSecp256r1署名検証

Solanaはsecp256r1楕円曲線署名検証のネイティブサポートを追加します。これは、Passkeys、WebAuthn標準、二要素認証（2FA）を含む高度なアカウント抽象化モデルとのオンチェーン互換性を実現する重要なアップグレードです。このアップデートにより、Web2ですでに広く普及しているパスワードレス認証がWeb3領域に導入され、オンチェーンアプリケーションのセキュリティと使いやすさが向上します。

当初Agave 2.1リリースに予定されていたこの機能は、2.2へ延期されました。詳細については、Agave 2.1アップデートにおけるSecp256r1署名検証の包括的な解説をご覧ください。

プリコンパイルのアラインメントバグ

Agave 2.2の最初のロールアウト直後、Secp256r1およびEd25519プリコンパイルプログラムの実装に重大なバグが見つかりました。このバグは、アラインメントを保証せずに生のトランザクションレイアウトを公開する、新しい`--transaction-structure`ビューフラグで発生しました。プリコンパイルが命令データを誤って2バイト境界に整列されていると想定したため、ブロックプロデューサーとバリデータの間で実行結果が一致しませんでした。その結果、バンクハッシュが不一致となってリーダーが処理を中断し、可用性が低下しました。この問題は4月9日に初めて報告され、4月11日までに速やかに修正されました。このバグによるユーザー資金への影響はありませんでした。詳細については、その直後に公開された根本原因分析をご覧ください。

SBPFv1、v2、v3プログラムのデプロイと実行

Solana Berkeley Packet Filter（SBPF）は、Solanaプログラムを効率的かつ安全に実行するために設計されたカスタム仮想マシンです。これは元々Linux向けに構築されたextended Berkeley Packet Filter（eBPF）をRustベースでフォークしたものです。 

Solana Berkeley Packet Filter（SBPF）のアップグレードは、パフォーマンスの向上、セキュリティの強化、アプリケーション開発者向けの新機能の実現に不可欠です。Agave 2.2では、SIMD-0161で最初に示されたSBPF仮想マシンの正式なバージョニングシステムを導入し、長期的な保守性とパフォーマンス向上の基盤を整えます。この変更により、SBPFv1（SIMD-0166）、SBPFv2（SIMD-0173、SIMD-0174）、SBPFv3（SIMD-0178、SIMD-0179、SIMD-0189）プログラムのデプロイと実行が可能になります。ネットワーク全体で再デプロイすることなく、プログラム実行環境を段階的に進化させるための持続可能なフレームワークが確立されます。

これまでは、すべてのSBPFアップグレードをグローバルなフィーチャーゲート経由で導入する必要があり、ランタイムの進化は煩雑で、デプロイの調整はほぼ不可能でした。バージョニングでは、プログラムの動作をグローバルランタイムから切り離し、代わりにプログラムごとのバージョンタグへ関連付けることで、この問題を解決します。バージョンタグはExecutable and Linkable Format（ELF）ファイルヘッダーのe_flagsフィールドにエンコードされます。このアプローチにより、以下が可能になります。

明示的なランタイム動作

各プログラムは、想定する命令セットアーキテクチャ（すなわちSBPFバージョン）を示します。このバージョンに基づいて、プログラムのランタイムが動作を変更します。

制御されたロールアウト

フィーチャーゲートにより、新しいSBPFバージョンのデプロイと実行が個別に有効化され、古いバージョンは時間をかけて段階的に廃止されます。一連の変更は個別のSBPFバージョンにまとめられるため、アップグレードがより明確になり、管理も容易になります。

段階的な非推奨化

古いSBPFバージョンが非推奨になった後は、最終的にそのサポートを終了できるため、仮想マシンのロジックが簡素化されます。この非推奨化プロセスは時間をかけて進められ、開発者にはプログラムの移行や再デプロイ、新しいバージョンへの適応に十分な時間が与えられます。

バージョン識別子

現在のプロトコルでは、0x0020以外のすべてのe_flags値がSBPF v0として扱われ、既存システムでは有効です。ただし、このアプローチは複数のSBPFバージョンのサポートには拡張できないため、更新する必要があります。

新しいSBPFバージョンを有効にする最初のフィーチャーゲートが有効化されると、プロトコルによるe_flagsの解釈方法が変更され、その値が対応するSBPFバージョン番号に直接マッピングされます。このシステムでは、0x0000がSBPF v0、0x0001がSBPF v1を表し、以降も同様に続きます。

CPI呼び出し元の制限を撤廃

Agave 2.2リリースサイクルには、Cross-Program Invocation（CPI）に関する従来の制約を取り除く、長らく待望されていた改善が含まれています。現在、CPI経由で呼び出されるプログラムは、呼び出し元によって命令アカウントとして明示的に渡す必要があります。これにより、特にCPIが深くネストされている場合、トランザクションの構築が複雑になり、コンピュートのオーバーヘッドも大幅に増加します。しかし、この制限は歴史的な経緯によるものにすぎず、現在のプロトコルには必要ありません。

SIMD-0163では、すべての呼び出し階層でアカウントを再帰的に渡す代わりに、CPI命令がトランザクションの最上位アカウントリストからプログラムアカウントを直接参照できるようにして、この制限を撤廃します。この変更には次のメリットがあります。

• プログラムアカウントの冗長なシリアライズとデシリアライズを回避し、CU使用量を大幅に削減します（実行可能ファイルを別のアカウントに保存するloader-v3プログラムを除く）。これらはサイズが大きい（~10 MBのバイナリ）ため、特にコストが高くなります。
• 呼び出し先プログラムのアカウントを命令スタック全体で引き回す必要がなくなり、トランザクションの構築が簡素化されます。
• コンポーザビリティが向上し、モジュール式で深くネストされたプログラムアーキテクチャを構築しやすくなります。

後方互換性

既存のプログラムは、この変更を利用しない限り影響を受けません。利用する場合は、次のいずれかに対応できます。

呼び出し先を静的にハードコードしており、ランタイムによる制約を満たすために任意の命令アカウントとしてのみ必要とするプログラムには、他の命令アカウントのインデックスをずらさないよう、NativeLoader1111111111111111111111111111111のようなプレースホルダーを渡せます。

特定の命令アカウントで渡された対象を動的に呼び出す、それ以外の既存プログラムは、制限撤廃のメリットを得るために更新して再デプロイする必要があります。

この最適化によって安全性が損なわれることはありません。「delay visibility」機能により、同じトランザクション内で追加、変更、削除された他のプログラムを呼び出すことはできません。

Loader-v4

Agave 2.2では、Loader-v3に代わる、合理化され、より柔軟なプログラムデプロイメカニズムであるLoader-v4のサポートが導入されます。SIMD-0167によって有効化されるLoader-v4は、プログラムアカウント管理を簡素化し、アップグレードワークフローを改善します。また、特にDeFiのような大きな価値を扱う環境で稼働中のプログラムに不可欠な安全機能を導入します。

Loader-v4の主な機能：

単一アカウントモデル： Loader-v4では、プロキシアカウントと個別のプログラムデータバッファが不要になります。各プログラムを1つのアカウントで表すようになります。

メンテナンスモード

プログラムを完全に閉じたり再デプロイしたりすることなく、実行不可の「メンテナンスモード」に設定できるようになります。元のプログラムアドレスが維持されるため、開発者はアドレスを手放すことなく実行を一時停止できます（エクスプロイト発生時など）。

任意のサイズ変更

Loader-v4では、デプロイ後にプログラムバイナリを拡大、縮小できるため、リソースをより柔軟に割り当て、ロックされた資金を回収できます。

任意のバッファ使用

再デプロイ時に外部バッファアカウントが常に必要だったLoader-v3とは異なり、Loader-v4ではバッファが任意になります。プログラムをメインのプログラムアカウントへ直接再デプロイできるようになり、アップロード中にロックする必要がある資金を半分に削減できます。

部分的な再デプロイ

Loader-v3では、アップグレードのたびにプログラムバイナリ全体を再アップロードする必要がありました。対照的に、Loader-v4は部分アップロードをサポートし、開発者はプログラムの特定部分だけを修正できます。これは小規模なアップデートで特に役立ちます。

Loader-v3からのシームレスな移行

Loader-v3でデプロイされたプログラムは、プログラムアドレスを変更せずにLoader-v4へ移行できます。これはLoader-v3の新しいMigrate命令によって実現されます。この操作では可視化が遅延するため、現在のスロットの残りの期間、プログラムは利用できなくなります。

Loader-v4の有効化後、別のフィーチャーゲートが作動し、Loader-v3への新規デプロイが無効化されます。既存のLoader-v3プログラムは引き続き機能しますが、今後のデプロイではすべてLoader-v4を使用することが想定されています。

loader-v4プログラムを確定する際、次のバージョンのアドレスを示して、リンクリストを形成できる可能性があります。これにより、プログラムの再デプロイに代わる方法が提供され、ユーザーインターフェースでは確定済みのプログラムバージョン一覧をユーザーに提示して選択できるようになります。

権限管理とアカウント閉鎖の仕組みは、Loader-v4でも変更されません。これらはすべて、新しいprogram-v4 CLIサブコマンドから利用できます。

まとめ

Agave 2.2はSolanaプロトコルにとって重要なマイルストーンであり、ネットワークの技術的な可能性を広げる重要なランタイム強化と新機能を提供します。このリリースでは、ブロック容量の20%増加、スケーラブルな状態ハッシュを実現するAccounts Lattice Hash（ALH）の統合、複数のプログラム開発機能のアップグレード、一般的な暗号技術との統合を実現するうえで不可欠なSecp256r1署名検証のサポートなど、いくつかの重要な変更が導入されます。これらの改善により、スループットと開発者体験が向上し、ネットワークがより幅広いアプリケーションをサポートできるようになります。

プログラムを構築する場合も、バリデータを運用する場合も、ネットワークを利用する場合も、Agave 2.2によってSolanaのパフォーマンス、柔軟性、レジリエンスがさらに高まります。

関連リソース

• Agaveクライアントリポジトリ
• Agave v2.2リリーススケジュール
• Agave v2.2変更履歴
• Agave v2.2タグ付きプルリクエスト