Agave 4.1アップデート：知っておくべきこと
目次
はじめに
Agave 4.1では、Solanaの中核バリデータクライアントが着実な進化を続けています。現在のパフォーマンスを改善すると同時に、ブロックの大型化、200msのスロット時間、そして将来的なAlpenglowの導入に向けた基盤を整えます。
4.1リリースサイクルの主なアップデート
- リリースサイクルを短縮し、メジャーリリースを6週間ごとに実施
- BLS公開鍵管理*、Validator Admission Tickets*、コミュニティテストクラスターなど、Alpenglow対応に向けた作業を継続
- XDPの導入率がネットワークの重要なしきい値を突破
- p-memoやp-ATAを含む、Pinocchioによる追加の書き換え
- バリデータのRAM使用量を削減
- 200msのスロット時間に向けた準備**
* フィーチャーゲート付きアップグレード
** Agave 4.2で導入予定
中核クライアントの開発と並行して、Anzaとエコシステム全体では複数の大規模な取り組みも進められています。
- Constellation： Constellationは、大規模な本番ブロックチェーンにおけるMultiple Concurrent Proposers（MCP）の、プロトコルレベルで初となる正式な実装を提案しています。単一のリーダーにトランザクションの取り込みに関する広範な裁量を与える代わりに、Constellationでは提案者と証明者を導入し、有効なブロックからリーダーが除外できる内容を制限します。
- 耐量子強化： Anzaの研究チームは、ポスト量子署名、アカウント移行、コンセンサス署名、ブロック伝播、オンチェーン署名検証などの研究を通じて、将来の量子攻撃者からSolanaを保護する方法の検討を始めています。
- 経済面のアップグレード： 新たなトークノミクス提案も複数準備されています。SIMD-550はSolanaのディスインフレ率を-15%から-30%へ倍増させることを提案しています。一方、SIMD-553：リソースおよび取り込み手数料 では、現在の署名手数料を、リーダーに支払われる基本取り込み手数料と、要求されたコストユニットに基づいてバーンされるリソース手数料に分割することを提案しています。
- 新しいガバナンスツール： 次の経済提案群は、改善されたガバナンスインフラによっても形作られています。新しいツールにより、バリデータだけでなくステーカーもSolanaのガバナンスへ直接参加できるようになり、中核プロトコルの変更に意見を表明できる参加者が広がります。
現在、非常に多くの動きがあります。
バリデータ運用者にも開発者にも、本ガイドでは最新の改善を最大限に活用するために必要なアップデートと知見を提供します。各セクションは独立しているため、自分に最も関係するトピックに絞って読むことができます。
執筆時点では、Agave v4.1.0-rc.1がmainnetでの一般利用に推奨されています。バリデータは今こそアップグレードしましょう。
Alpenglow対応への準備
Alpenglowコンセンサスアップグレードの基盤の多くが、Agave 4.1のリリースサイクル中に導入されます。これらの変更は、投票プログラムでのBLS鍵管理、Validator Admission Tickets、Fast Leader Handoverマーカーなど、Tower BFTからAlpenglowへのネットワーク移行に備えるものです。
コミュニティテストクラスター
Alpenglowをmainnetで有効化するまでの残りの道のりは、広範な実環境テストに大きく依存しています。5月以降、地理的に分散した約100台のバリデータで構成されるコミュニティテストクラスターが、稼働中のネットワーク環境でアップグレードを実行しています。mainnetでの有効化に先立ち、Solanaの現在のTower BFTベースのコンセンサスとAlpenglowの間の移行をテストしています。
目標は、ローンチプロセスを可能な限り平穏に進めることです。クラスター上のバリデータはTower BFTとAlpenglowを切り替え、管理された内部テストだけに頼るのではなく、実際の運用条件で移行手順を検証しています。議論はSolana Tech Discordの`ag-community-cluster`チャンネルで行われています。また、クラスターの稼働状況は、Valid Blocks、Staking Facilities、Nodersが提供するコミュニティダッシュボードで確認できます。
BLS公開鍵管理
SIMD-0387：投票アカウントでのBLS公開鍵管理 は、Agave 4.1のリリースサイクル中に有効化されます。これにより、Alpenglowに先立ってバリデータが投票アカウントへBLS公開鍵を登録するために必要な投票プログラムの基盤が追加されます。AlpenglowはBLS集約署名を使用し、投票の集約と検証にかかるコストを削減します。ただし、BLS公開鍵は現在使用されているEd25519投票権限鍵とは異なります。
バリデータは、既存のEd25519投票権限鍵での運用を継続しながら、投票アカウントにBLS公開鍵を追加できます。Alpenglowが有効になると、BLS公開鍵が登録されていない投票アカウントは、新しい投票プロセスに参加できません。
Alpenglow Validator Admission Tickets（VAT）
Agave 4.1のリリースサイクルでは、Validator Admission Tickets（VAT）を実装するSIMD-0357もmainnetで有効化されます。VATは、SolanaがTower BFTの現在の投票トランザクションモデルから移行する際に、同程度のバリデータコスト構造を維持するよう設計されています。
現在、バリデータは投票のたびに継続して投票トランザクション手数料を支払っており、安定して投票するバリデータでは1エポックあたり合計~2.1 SOLになります。Alpenglowでは、これらの投票トランザクションが新しいコンセンサス設計に置き換えられるため、SIMD-0357は代わりにエポックごとに1回の参加コストを導入します。Alpenglowの投票に参加する資格を持つ各バリデータは、エポックごとに1.6 SOLのVATを支払います。これにより、同程度の経済的参入障壁を維持しつつ、Alpenglowのローンチ後にバリデータセットが即座かつ無制御に拡大するリスクを軽減します。
実装上の処理はエポック境界で行われます。新しいエポックへ移行する際、ランタイムは次のエポックのバリデータセットを計算し、BLS公開鍵が登録済みで、かつVATとrentを賄う十分なlamportsを持つ投票アカウントを抽出します。その後、承認されたバリデータの投票アカウントからVATを差し引きます。これらのlamportsはincineratorアカウントへ直接送られます。条件を満たすバリデータが2,000台を超える場合、投票セットはステーク加重によって制限され、条件を満たす上位のバリデータが選択されます。
運用面では、バリデータ運用者が資金を保持すべき場所が変わります。現在、投票トランザクション手数料はバリデータIDアカウントから支払われます。このアカウントは通常のバリデータ運用のためにホットキーペアである必要があります。VATでは、代わりに参加コストが投票アカウントから差し引かれます。
Fast Leader Handoverマーカー
最後に、SIMD-0337：Alpenglow Fast Leader Handover用マーカーが有効化されると、新しいブロックマーカーが追加されます。これにより、Alpenglowのリーダーはブロックの先頭で親ブロックを宣言し、必要に応じてブロックのストリーミング中にその親を更新できます。これらのマーカーは、リーダー間の同期遅延を短縮するために設計されたFast Leader Handoverを支えます。
XDP導入の拡大と1億CUへの道
XDP（eXpress Data Path）は、AgaveがTurbineを高速化するために使用する高性能ネットワークパスです。Agaveはネットワークインターフェースカードの近くでeBPFプログラムを読み込めるため、shredトラフィックは標準的なLinuxパケット処理パスの大部分を迂回できます。ネットワークが長年の目標である1億CUのブロックを実現するには、XDPの導入が不可欠です。
導入率は重要なしきい値を超えました。今月初め、XDPを実行するリーダーが実行していないリーダーを上回る「フリッペニング」がネットワークで発生しました。現在、ネットワークの3分の2以上がXDPを有効化しています。Agave 4.1では、この成熟度を反映してXDPサポートから実験的機能のラベルを外し、従来の`--experimental-retransmit-xdp-*`フラグを`--xdp-interface`、`--xdp-cpu-cores`、`--xdp-zero-copy`に置き換えます。Agave 4.2では、XDPがデフォルトで有効になる予定です。
まだ移行していないバリデータ運用者には、Solana FoundationのアップグレードページとAnzaのセットアップガイドが、カーネルサポート、ネットワークハードウェア、バリデータ機能、起動フラグ、検証手順を網羅した実用的な互換性チェックリストを提供しています。以下は、ドライバーとNICに関する便利な互換性ガイドです。
Pinocchioによるプログラム書き換えの拡大
p-tokenのローンチ成功により、Solanaで最も利用されているプログラムを対象とした書き換えが、ネットワーク全体で大幅なコンピュート削減につながることが最近実証されました。SPL Tokenプログラムのドロップイン代替として、p-tokenはコンピュートユニット（CU）の消費量を約95%削減し、標準的なトークントランザクションの効率を約~19倍に高めます。従来、Tokenプログラムの命令はブロック全体のCU使用量の約10%を占めていました。これらの命令のコストを従来の約5%まで削減したことで、p-tokenはブロック容量全体の約9.5%を解放しました。
p-tokenの「p」は、Anzaが開発した、Solanaプログラムを記述するための最適化された高性能かつ依存関係のないライブラリ、Pinocchioを意味します。Pinocchioは標準的なsolana-program crateの代替となります。solana-program crateでは、命令データとアカウントデータの処理にゼロコピー型が広く使用されています。
Anzaは現在、ほかの中核プログラムもPinocchioで書き換えています。目的は、新しい標準を導入したりアプリケーションレベルの移行を強制したりすることではありません。既存の広く利用されているプログラムの実行コストを大幅に削減することです。
P-memoプログラム
最初の例は、すでにmainnetで稼働している、SPL MemoプログラムをPinocchioで再実装したp-memoです。Memoプログラムは小規模ですが、それでも効率向上は顕著です。署名者がいない場合、現在のMemoプログラムが2,022 CUを消費するのに対し、p-memoは287 CUで、既存コストの約14%です。署名者がいる場合、その差はさらに広がります。署名者が1人の場合、現在の13,525 CUに対してp-memoは513 CU、2人の場合は25,111 CUに対して628 CU、3人の場合は36,406 CUに対して743 CUです。つまり、署名者が多いケースでは、p-memoはコンピュート消費量を現在のプログラムコストのわずか2～4%まで削減します。
P-ATAプログラム
Associated Token AccountプログラムをPinocchioで再実装するp-ATAの開発も進んでいます。ATAプログラムは、ウォレット、トークンmint、そのmintを保持するために使用されるトークンアカウントの標準的な対応関係を定義します。ユーザーのassociated token accountを決定論的に導出できるほか、まだ存在しない場合は誰でも受取人のためにそのアカウントを作成できます。
ATAプログラムは、ネットワーク上で呼び出し回数が5番目に多いプログラムです。Anzaチームの推定によると、全トランザクションの~11.9%で使用され、CU消費量全体の~13.3%を占めています。書き換えにより、加重平均CU使用量を80.9%削減できる可能性があります。p-ATAとともに追加される新しい命令によって、さらなる削減も見込まれます。現在のネットワーク使用量では、mainnet全体で約10%のCU削減に相当します。Anzaのサンプリングでは、p-ATAによって1ブロックあたり278万CU以上が解放されました。
P-token、p-memo、p-ATAで、この取り組みが終わる可能性は低いでしょう。Token-2022プログラムも、書き換えの要望が特に多いプログラムです。より広い視点では、中核プログラムを`no_std`にするAnzaの取り組みが、Solanaの基盤プログラムをより少ない依存関係と低いコンピュートコストで書き換えるための土台となります。
プログラムのエントリーポイントオーバーヘッドを削減
Agave 4.1のリリースサイクル中に有効化が予定されている関連変更として、プログラムのエントリーポイントを最適化するSIMD-0449：プログラム入力での直接アカウントポインターがあります。現在、ABIv1 sBPFプログラムは、プログラム入力内のシリアライズされたアカウントセクションを解析し、アカウント境界を見つけてプログラムへ渡すアカウントスライスを構築する必要があります。SIMD-0449では、VMが呼び出し準備時にすでに把握している境界情報を利用し、直接アカウントポインターのスライスをプログラム入力へ追加することで、この処理を変更します。
これは、アカウント解析がエントリーポイントコストの大部分を占めるPinocchio形式のプログラムで特に重要です。直接アカウントポインターを使用すると、エントリーポイントはアカウントセクション全体を反復処理せずにアカウントへアクセスできます。そのため、アカウント数にかかわらず、エントリーポイントのコンピュートコストは実質的に一定になります。
更新後のベンチマークでは、64アカウントのPinocchioエントリーポイントが504 CUから推定7 CUまで低下します。より小規模なアカウントセットも同じ低水準の7 CUに収束します。
200msへのスロット時間短縮
最も期待されているパフォーマンス改善の1つは、Solanaの目標スロット時間を400msから200msへ短縮することです。Agave 4.1のリリースサイクル中に導入される可能性は低く、Agave 4.2でmainnetに導入される可能性が高いでしょう。しかし、この重要なアップグレードを可能な限り早くmainnetへ導入する機運が高まっています。
SIMD-0525：スロット時間の短縮は、400msのスロットから350ms、300ms、250msへ段階的に移行し、最終的に200msへ到達する導入計画を提案しています。各段階はフィーチャーゲートで制御されるため、クライアントチームと運用者は次の段階へ進む前に、短いスロット時間でのネットワークを観察できます。Anzaは数か月にわたり200msのスロットを社内でテストしており、ネットワークは積極的なスロット時間短縮に対応できると考えています。リプレイステージの改善により、この変更はより現実的になりました。完全な400msスロットのリプレイは、現在約40msで完了します。
目的は明確です。スロットを短縮すると、ユーザーの確認とファイナライズのレイテンシが短くなります。また、各リーダーの担当時間も短縮されます。現在、Solanaのリーダー期間は連続する4スロットで、400msのスロットではリーダーに1.6秒の時間が与えられます。200msのスロットでは800msに短縮されます。これにより、悪意あるリーダーが次のリーダーによるブロック生成までにトランザクションを遅延、並べ替え、または選択的に取り込める最悪時の時間が短縮され、市場構造が改善されます。
スロットの短縮により、アプリケーションはオンチェーンの時間をより細かい粒度で把握できます。これは、オラクル利用者や独自AMM形式のマーケットメーカーなど、スロットの鮮度を考慮するシステムにとって重要です。
この提案は、Solanaの経済性を変えないよう慎重に設計されています。`slots_per_year`は逆比率で増加し、SOLのインフレスケジュールを維持します。Alpenglowでは、Validator Admission Ticket（VAT）のコストもスロット時間の段階に応じて調整され、参加コストを意図された1日あたり~0.8 SOL付近に維持します。さらに、スロットごとの処理上限は短縮後の目標スロット時間に比例して引き下げられるため、ネットワークが1秒あたりに処理できる作業量はほぼ変わりません。
中核となる前提のいくつかは変わりません。リーダー期間は引き続き4スロット、エポックは432,000スロットで固定され、スロットあたりのtick数も64のままです。エポックはスロット数で固定されているため、200msのスロットではエポックの長さが約2日から1日に短縮されます。
議論の焦点の1つは、Alpenglowより前にスロット時間の短縮を有効化した場合、バリデータの投票コストへ与える影響です。スロットが高速化すると1日あたりの投票数が増え、バリデータの1日あたりの投票コストも増加します。投票トランザクションコストは、バリデータ運用者にとって最大の単一コストです。投票トランザクションの価格は一律0.000005 SOLで、1日あたりのトランザクションコストは~1.086 SOLになります。200msのスロットでは、これらのコストが約2倍になります。
その他の注目すべきアップデート
Agave 4.1のリリースサイクル中には、バリデータ手数料率の精度向上、新しい暗号プリミティブ、アップグレード可能なローダーにおけるサービス拒否攻撃経路の排除など、比較的小規模ながら注目すべき複数の改善が有効化される予定です。
バリデータ手数料率の精度向上
Agave 4.1のリリースサイクルの一環として、フィーチャーゲート付きのSIMD-0291：ベーシスポイント単位の手数料率アップグレードがmainnetで有効化されます。現在、バリデータ手数料率は整数のパーセント単位でしか設定できません。つまり、5%や6%には設定できますが、5.5%、5.25%、5.01%には設定できません。
このアップデートにより、バリデータは手数料率をベーシスポイント単位で設定し、より細かく制御できるようになります。100ベーシスポイントが1%に相当します。投票プログラムには新しい`UpdateCommissionBps`命令が追加され、投票アカウントの承認済み引き出し権限者が、バリデータのインフレ報酬手数料をより高い精度で更新できるようになります。バリデータにとって、手数料設定がより柔軟で競争力のあるものになります。
この変更は、新しいVote Account V4に関連する複数のアップデートの1つです。また、ブロック報酬をプロトコル内で分配できるようにするSIMD-0123：ブロック収益の分配の有効化に向けたネットワークの準備にも役立ちます。
SHA-512 syscall
SIMD-0512：Sha512 Syscallは、オンチェーンプログラムがランタイムを通じてSHA-512ハッシュを直接利用できる新しいsyscallを導入します。インターフェースは、`sol_sha256`、`sol_keccak256`、`sol_blake3`など、既存のハッシュsyscallに準じています。
SHA-512はEd25519署名検証で使用される中核プリミティブであり、AgaveとFiredancerの両バリデータクライアントに内部依存関係としてすでに存在します。しかし、これまではオンチェーンプログラムに公開されていませんでした。オンチェーンで短いメッセージを直接ハッシュする処理は高コストで、数千CUを消費します。一方、syscall経由では100 CU未満です。
`sol_sha512`を使用すると、プログラムはsyscallのコストでSHA-512ハッシュを計算し、標準的な64バイトのダイジェストを直接受け取れます。この変更は追加的でフィーチャーゲート付きのため、新しいsyscallを使用しないプログラムには影響せず、既存のハッシュsyscallも変更されません。
アップグレード可能なローダーの強化
Agave 4.1のリリースサイクルでは、Loader V3の`ExtendProgram`命令に最小拡張サイズを追加する、フィーチャーゲート付きのSIMD-0431：Loader V3：プログラムの最小拡張サイズもリリースされます。有効化後、プログラムデータアカウントが最大アカウントサイズである10 MiBまで残り10 KiB以内の場合を除き、プログラムは少なくとも10,240バイト（10 KiB）拡張する必要があります。
この変更は、現在のアップグレード可能なローダーに存在する巧妙なサービス拒否攻撃経路に対処します。`ExtendProgram`はパーミッションレスです。つまり、誰でもアップグレード可能なプログラムのデータアカウントを、わずか1バイトでも拡張できます。拡張のたびに現在のスロットにおけるプログラムのキャッシュエントリが無効化されるため、低コストの1バイト拡張によってプログラムへのアクセスを一時的に妨害できます。
この変更では、`ExtendProgram`に権限を設定するのではなく、命令のパーミッションレス設計を維持しながら、悪用が経済的に割に合わないようにします。新しい最小値である10 KiBでは、拡張ごとにrent免除用のlamportsとして約0.072 SOLが必要です。
正当なプログラムアップグレードへの影響は限定的です。追加スペースが10 KiB未満でよいプログラムでも最小値いっぱいまで拡張する必要がありますが、余分な容量は将来のアップグレードに利用できます。また、このSIMDでは、命令のアカウント、署名者要件、CPI制限、既存のマルチシグワークフローは変更されません。
まとめ
Agave 4.1は、多岐にわたるパフォーマンス改善と最適化を統合した大規模なクライアントアップグレードです。今後のAgave 4.2は、4,096バイトへのトランザクションサイズ拡大、200msへのスロット時間短縮、そして待望のAlpenglowコンセンサスアップグレードが導入される可能性もあり、さらに重要なリリースになりつつあります。
関連リソース
Heliusを購読
Solana開発の最新情報や新しい記事の公開通知を受け取れます