Agave 4.3アップデート：知っておくべきこと
はじめに
Agave 4.3により、Solanaは史上最大ともいえるプロトコルアップグレードに向けて準備を進めています。4.3のリリースサイクルでは、待望のSolanaの新しいコンセンサスメカニズムであるAlpenglowが導入され、最終的にTowerBFTからメインネットを協調的に移行する「Alpenswitch」が実施されます。
ローンチ以来、SolanaのコンセンサスアーキテクチャはProof of HistoryとTowerBFTを中心に構築されてきました。バリデータはトランザクションを送信して投票し、そのトランザクションは通常のユーザートランザクションとともに処理され、ブロックに格納されます。その後、32スロットにわたって投票が積み上がることでファイナリティが確立され、Solanaのファイナリティ時間は約12.8秒となります（スロット時間を400ミリ秒と仮定）。
Proof of History（PoH）は、イベントの順序付けと時間の同期に独自のアプローチを採用した、Solanaのローンチ時を象徴するアーキテクチャ上の革新の1つでした。そのため、これが最終的に廃止されることは1つの時代の終わりを意味し、当初Solanaを際立たせていた技術からプロトコルがどれほど進化したかを示しています。
Alpenglowは「PoH + TowerBFT」を、バリデータが中核のトランザクションパイプラインの外部で投票を交換するプロトコルであるVotorに置き換えます。Votorはこれらの投票を暗号学的証明書に集約します。この設計では、約150ミリ秒でのファイナリティを目指しています。
トランザクションを送信し、アカウントの状態を読み取るユーザーやアプリケーションでは、移行作業はほとんど、またはまったく必要ありません。トランザクションと手数料の仕組みは変わりません。最も大きな調整が必要になるのは、ブロック、投票、ストリーム、コミットメントデータを利用するバリデータとインフラストラクチャです。
投票トランザクションがブロックからなくなり、confirmedとfinalizedは実質的に同一となり、ストリーミングインフラストラクチャには同一スロット内の競合するバンクを区別するための新しい情報が追加されます。
この記事では、Votorがブロック生成とファイナリティをどのように変えるかを含め、Alpenglowの仕組みを解説します。また、Agave 4.3のリリースサイクル全体で導入されるその他の注目すべき変更点も取り上げます。
段階的なロールアウト：まずVotor、次にRotor
Alpenglowは、Solanaの投票とファイナリティの仕組みを置き換えるVotorと、ネットワーク全体へのブロック伝播方法を再設計するRotorという2つの主要コンポーネントを中心に設計されています。この2つの仕組みは段階的にロールアウトされ、まずVotorが導入されます。
Agave 4.3では、既存のブロック伝播プロトコルであるTurbineを維持したままVotorを導入します。Rotorは、Alpenglowの初期アクティベーションを規定する提案であるSIMD-0326から明示的に除外されました。デプロイには独自のSIMDが必要です。初期ロールアウトではバリデータがコンセンサスに到達する方法は変わりますが、ブロックデータがネットワーク内を移動する方法はまだ変わりません。
Votor
Votorは、TowerBFTの投票トランザクションとロックアウトシステムを、より直接的なバリデータ間プロトコルに置き換えます。TowerBFTでは、バリデータはブロックに格納されるトランザクションを送信して投票し、最終的に十分なロックアウト深度が蓄積されるとブロックがファイナライズされます。一方、Votorではバリデータが署名付き投票メッセージを直接交換し、プロトコルがそれらの署名をコンパクトな証明書に集約します。
Votorは、32スロットにわたって投票が蓄積されるのを待つ代わりに、1回または2回の投票ラウンド後にブロックをファイナライズできます。TowerBFTでは約12.8秒かかるのに対し、このプロトコルは約150ミリ秒でのファイナリティを目指しています。
Votorには、並行して機能する2つのファイナリティ経路があります。
最初のラウンドでステークの80%以上がブロックを公証すると、それらの投票をFast-Finalization Certificateに集約でき、ブロックは直ちにファイナルになります。これはプロトコルの高速経路であり、必要な投票は1ラウンドのみです。
80%のしきい値に達しなかった場合でも、ステークの60%超がブロックの公証に投票していれば処理を進められます。これによりNotarization Certificateが生成され、2回目の投票ラウンドが可能になります。2ラウンド経路を通じてステークの60%超がファイナライズ票を投じると、Finalization Certificateが形成され、ブロックがファイナルになります。
したがって、完全なプロトコルにはNotarization、Notarization Fallback、Skip、Skip Fallback、Finalという5種類の投票があります。これらの投票のさまざまな組み合わせによって、公証、フォールバック、スキップ、ファイナライズの各証明書が生成されます。これらの証明書は、スロットの結果について十分なステークが合意したことを示すコンパクトな暗号学的証拠として機能します。
Votorは、応答する正直なステークが60%あれば処理を継続できるように設計されています。ステークの最大20%が敵対的に振る舞い、さらに20%がオフラインまたは無応答でも動作できます。これは意図的なトレードオフです。Alpenglowは、BFT設計で従来採用されてきた3分の1のビザンチンしきい値を手放す代わりに、クラッシュしたバリデータや利用不能なバリデータへの耐性を高めた20+20のレジリエンスモデルを採用しています。
Votorでは、Proof of Historyをコンセンサスクロックとして使用することもなくなります。代わりに、バリデータはローカルのタイムアウトタイマーを使用します。許容可能なブロックを受信しないまま十分な時間待機したバリデータは、スキップ票を投じてコンセンサスを先に進められます。これにより、TowerBFTと比べて計時とコンセンサスの関係が簡素化されます。
Rotor
RotorはAgave 4.3には含まれず、現時点で公開されたアクティベーション日はありません。そのため、Votorのアクティベーション後もTurbineが引き続きブロックデータを転送します。Rotorと、そのリレー選択に使用されるスマートサンプリングの仕組みは、後日、別の提案とロールアウトを通じて導入されます。
重要なのは、Solanaが1秒未満のファイナリティを実現するためにRotorを待つ必要はないという点です。現在のAlpenglowロールアウトでは、Turbineを維持したまま、Agave 4.3のVotorによって約150ミリ秒のファイナリティを実現することを目指しています。 Rotorはブロック伝播をさらに改善し、Alpenglowアーキテクチャ全体の効率を高めることを目的としていますが、Votorの新しいファイナリティモデルの前提条件ではありません。
投票トランザクションの廃止
Alpenglowによる最も目に見える変化の1つは、Solanaブロックから投票トランザクションがなくなることです。バリデータはこれらの投票にトランザクション手数料を支払っており、ネットワークはその処理と保存に帯域幅、コンピューティングリソース、台帳スペースを費やしています。
これまで、投票トランザクションはオンチェーンに記録される全トランザクションの約4分の3を占めていましたが、ブロック容量の増加に伴い、この比率は低下しています。投票トランザクションは安価（5,000 lamports）であり、全体のコンピュートのごく一部（約5%）しか占めませんが、ネットワークの生のトランザクション数と台帳の占有量を膨らませています。
Alpenglowでは、バリデータは代わりにBLS署名付き投票メッセージを互いに直接交換します。AgaveのConsensusPoolは観測した投票を追跡し、十分なステークを、Votorがコンセンサスを進めたりファイナライズしたりするために使用する証明書へ集約します。
ただし、バリデータ参加の証拠が台帳から消えるわけではありません。Alpenglowのブロックには、コンセンサス情報を含む新しいブロックフッターが導入されます。現在のAgave実装では、BlockFooterV1に最新のファイナライズ証明書のほか、notar_reward_certとskip_reward_certを格納できます。報酬証明書には、集約BLS署名と、投票したバリデータを識別するビットマップが含まれます。
現在Vote Programのトランザクションをインデックスしてバリデータが投票したかどうかを判定しているシステムは、代わりにAlpenglowの証明書と投票関連データを利用する必要があります。投票トランザクションを単純にフィルタリングする既存のトランザクションパイプラインは、通常、そのまま動作を続けられます。Alpenswitch後は、フィルターで除外する対象がなくなるだけです。
この切り替えにより、Solanaで広く使われてきたTPS統計にも不連続性が生じます。Alpenglowのアクティベーション後は、ユーザーアクティビティがまったく変わらなくても、投票トランザクションを含む生のTPS測定値が急減します。そのため、Alpenswitch前後のアクティビティを比較する際には、非投票TPSが有意な指標となります。投票トランザクションをなくすことで、Solanaの実際のスループットをめぐる長年の混乱要因が解消され、他のネットワークとの比較も容易になります。
投票トランザクションをなくすことで、一部の容量がユーザーに還元されます。ただし、投票がネットワークのコンピュート負荷に占める割合は比較的小さいため、その効果を過大評価すべきではありません。
コミットメントレベル
Alpenglowは、Solanaに長く存在してきた区別の1つである、confirmedとfinalizedのコミットメント間の差も解消します。
現在、アプリケーションは3つのコミットメントレベルから選択します。processedは最も新しい状態を提供しますが、クラスター全体での保証はありません。confirmedは、ステークの圧倒的多数がそのブロックに投票したことを意味し、通常は1〜2スロット以内に到達します。finalizedは決定論的ファイナリティを提供しますが、TowerBFTではブロックが最大投票ロックアウトに達する必要があり、確認からファイナライズまでに約32スロットの差が生じます。一般に、レイテンシが重視されるRPCリクエストにはconfirmedが推奨され、より強い保証が必要な場合にはfinalizedが推奨されます。
実際には、confirmedは極めて信頼性が高いことが実証されています。楽観的に確認されたSolanaブロックが、その後ファイナライズされなかった例は一度もありません。しかし、プロトコル上の保証は依然として弱いままです。確認済みブロックはまだ決定論的にファイナルではないため、ブリッジ、取引所、決済システムなど、残存するテールリスクを許容できないアプリケーションは、従来finalizedを待つ必要がありました。
Alpenglowはこのトレードオフを解消します。Votorが高速ファイナライズ証明書またはファイナライズ証明書を生成すると、ブロックはファイナルになります。Votorがファイナライズ済みバンクをルートとして選択すると、バリデータは確認済みの最高スロット、ルート、圧倒的多数による最高ルートを同時に更新します。
開発者にとって、これはAlpenswitch後にconfirmedとfinalizedが実質的に同じコンセンサス状態を指すことを意味します。RPCインターフェースは引き続きprocessed、confirmed、finalizedを受け付けるため、既存のアプリケーションはアクティベーション当日にコミットメント設定を変更する必要はありません。 ただし、後者2つのレイテンシ差はなくなります。
Votorの2つのファイナライズ経路の違いは、通常のRPC利用者には見えません。ブロックが1ラウンドで80%の高速ファイナライズしきい値に達する場合でも、60%をしきい値とする2ラウンド経路でファイナライズされる場合でも、外部から見える結果は同じです。
複数の候補ブロック
Alpenglowにおけるもう1つの重要な変更は、バリデータデータを利用するRPCプロバイダー、インデクサー、その他のインフラストラクチャを対象としています。今後はスロットを一意のブロック識別子として扱えません。
Solanaのスロットは、リーダーがブロックを生成できる時間枠です。一方、bankは、特定の候補ブロックを実行して生成された状態をバリデータがローカルに表現したものです。これらの概念は以前から別物であり、競合するバンクも新しいものではありません。しかし、多くの本番インフラストラクチャはこれまでスロットとブロックを同義として扱ってきました。
Alpenglowにより、この前提はこれまで以上に危険になります。
Agave 4.3では、アカウント、トランザクション、エントリ、ブロックの更新をストリーミングするためのバリデータインターフェースであるGeyserに、新しい識別子bank_idが追加されます。update_account_for_bank、notify_transaction_for_bank、notify_entry_for_bank、notify_block_metadata_for_bankなど、バンクを認識する新しいコールバックは、イベントをその生成元である特定のバンクに関連付けます。同様に、バンク単位のステータス通知にもbank_idが含まれます。以前のコールバックは、互換性のため4.3でも残されますが、非推奨となり、次のAgaveメジャーリリースで削除される予定です。
重要なのは、bank_idがグローバルに合意されたブロックではなく、ローカルのバンクインスタンスを識別するという点です。Agaveは、バリデータランタイムが保持するローカルなアトミックカウンターからバンクIDを生成します。そのため、2つのバリデータが同じブロックをリプレイしても、同じbank_idを割り当てるとは限りません。したがって、インフラストラクチャは単一のバリデータから届く競合ストリームを分離するために(slot, bank_id)を使用し、異なるバリデータや接続間でデータを照合する際にはブロックIDまたはブロックハッシュを使用する必要があります。
Alpenglowの今後の段階では、同じスロットに複数のバンクが存在することが、バリデータ運用の通常の一部になります。
最も分かりやすい例は、初期のVotorアクティベーション後にロールアウトされるAlpenglowコンポーネントの1つである高速リーダーハンドオーバーです。リーダーは、コンセンサスで受け入れられると予想する親ブロック上で、楽観的に構築を開始できます。代わりにVotorがその親をスキップすべきだと判断した場合、リーダーは親を切り替え、残りのリーダー時間枠で再構築できます。内部的には、同じスロットの1つのバンクを別のバンクに置き換えることを意味します。Agaveには、この切り替えを表現するために必要なUpdateParentの仕組みがすでに含まれています。高速リーダーハンドオーバーは、Agave 4.3でのAlpenglow初期アクティベーションには含まれず、4.4でロールアウトされる見込みです。
リーダーの二重投票も、広い意味で同じ結果を生む可能性があります。リーダーが同じスロットに対して2つの異なるブロックに署名し、配布した場合、バリデータは一時的に両方の候補を保持し、考慮する必要があります。Votorは非同期であり、バリデータはブロック、投票、証明書、ローカルタイムアウトが到着するたびに処理するため、ネットワークの異なる部分では、それらの候補が異なる順序で観測される可能性があります。
最近の変更により、MAX_ALTERNATE_BLOCKS_PER_SLOTは11から6に厳格化されました。したがって、バリデータが1つのスロットについて保持する必要がある候補ブロックは最大7つです。最終的にはコンセンサスによって、それらの候補が1つの履歴に確定されます。Votorでは、公証にステークの60%超が必要です。相当量のステークが両方に投票しない限り、競合する2つのブロックの両方が有効な公証証明書を取得することはできません。ビザンチン的に振る舞うステークが20%未満であるというAlpenglowの前提では、プロトコルの安全性の仮定に違反しない限り、競合する公証証明書は成立しません。
Geyserの利用者にとって実務上の教訓は明確です。一時的な状態をスロットだけでキー付けするのはやめるべきです。アカウントの変更、トランザクション、エントリ、ブロックメタデータは、コンセンサスが存続するバンクを特定するまで、(slot, bank_id)ごとに追跡する必要があります。同じスロットに別のバンクが現れた場合、そのイベントは別の候補状態に属しており、最初のバンクのイベントを暗黙に上書きしてはいけません。
バリデータ参加チケット
現在、Solanaバリデータの運用で最も大きなコストは投票トランザクションです。TowerBFTでは、バリデータは投票を送信するたびに標準トランザクション手数料を支払い、その合計はエポックあたり約2 SOLになります。Alpenglowでは、トランザクション手数料を、アクティブなコンセンサスセットへの参加が認められたバリデータにエポックごとに1回課される手数料に置き換えます。これはValidator Admission Ticket（VAT）と呼ばれます。
この移行の基盤はすでに稼働しています。SIMD-0387で規定されたBLS公開鍵の登録が7月にメインネットで有効化され、その直後にVATの機能ゲートであるSIMD-0357も有効化されました。VotorはBLS署名を使用するため、多数のバリデータの署名を1つのコンパクトな証明書に集約できます。各バリデータは、Alpenglowに参加する前に、投票アカウントにBLS公開鍵を登録する必要があります。VATゲートの有効化以降、BLS公開鍵を持たないバリデータはすでに投票セットから除外されています。
Alpenglowの導入前は、バリデータは引き続き通常の投票トランザクションを送信し、関連する手数料を支払います。この段階では、VATは主に参加フィルターとして機能します。対象となるバリデータにはBLS鍵が必要で、ステークに基づく有資格バリデータの上位2,000に入る必要があります。Alpenglowが有効になるとVATが開始され、投票トランザクションはなくなります。
Alpenglowの稼働後は、エポック境界付近で参加資格が再計算されます。バリデータの投票アカウントには、登録済みのBLS鍵と、チケットおよびrent免除を賄うのに十分なSOLが必要です。2,000を超えるアカウントが条件を満たす場合、システムはステークに基づいて順位を付け、ステーク量が最も多いバリデータを受け入れます。その後、システムは参加が認められた各バリデータの投票アカウントからチケット代を直接差し引き、Solanaのバーン用アカウントに送ります。そのため、バリデータは投票アカウントに十分な資金を維持する必要があります。従来のシステムでは、投票トランザクション手数料はバリデータのIDアカウントから差し引かれていました。
当初のAlpenglowとVATの提案では、エポックあたり1.6 SOLのチケットが規定されていました。これは、バリデータが従来投票トランザクションに費やしていた約2 SOLの80%程度です。この数値は、Solanaが従来目標としていた400ミリ秒のスロット時間を前提としていました。SIMD-0525では、代わりにスロット時間に応じてVATを調整します。スロット時間が200ミリ秒の場合、参加コストは0.8 SOLになります。
VATでは、このコストの送付先も変わります。現在、投票トランザクションが支払う5,000 lamportsの基本手数料は2分割され、50%がバーンされ、50%がブロックリーダーに渡ります。これに対し、VATは全額がバーン用アカウントに送られます。ただし、VATのより広い目的は、SOLのデフレ性を大幅に高めることではありません。投票トランザクション手数料がなくなった後も、コンセンサスセットへの参加に経済的コストを維持することです。
安全性と準備
稼働中のネットワークのコンセンサスプロトコルを置き換えることは、極めてリスクの高い作業です。そのため、Alpenglowでは、専用のコミュニティテストクラスターやバグバウンティを含め、通常のAgave機能アクティベーションよりもはるかに広範なテストと移行プロセスを実施しています。
5月以降、バリデータ運用者は専用のAlpenglow Community Clusterを運用しており、これは100ノード超に拡大しています。運用者は実際のバリデータハードウェアとネットワーク構成を使用するため、制御された環境では再現が難しい地理的分散、レイテンシの変動、ソフトウェア構成、再起動、運用ミスといった条件下でAlpenglowをテストできます。
その最も重要な目的の1つは、Alpenswitch自体のテストです。クラスターがすでにAlpenglowを実行している状態でVotorが動作するかを確認するだけでなく、運用者はTowerBFTから新しいコンセンサスシステムへの移行を繰り返し実施しています。
Alpenglowは、専用の敵対的レビューも受けています。8月、Anzaは最大50,000 SOLの賞金プールを設けた2週間のAlpenglow Bug Bounty Competitionを開始しました。常設のAgaveバウンティとは異なり、このコンペティションは、Votor、BLS署名と証明書の検証、バリデータ参加、TowerBFTからAlpenglowへの移行経路など、新しいコンセンサススタックに特化していました。参加は非常に活発でした。Anzaは300件を超える報告があり、25,000 SOL以上を報奨金として分配すると発表しました。
Alpenglowの導入に伴い、Frankendancerのサポートは終了します。Frankendancerは当初から移行用クライアントとして設計されており、Firedancerのネットワークおよびブロック生成コンポーネントと、実行およびコンセンサス用のAgaveコンポーネントを組み合わせています。このハイブリッドアーキテクチャで新しいコンセンサスシステムをサポートすると、保守とセキュリティの負担がさらに大幅に増えるため、Firedancerチームは代わりに完全版Firedancerクライアントの開発に注力しています。
バリデータ向けに共有されているガイダンスによると、Frankendancerも完全版Firedancerも、TowerBFTからAlpenglowへ移行する短い期間自体には対応しません。そのため、Firedancerの運用者はAlpenswitch前にAgaveバリデータへフェイルオーバーし、切り替え中はAgaveを使用し続け、クラスターがAlpenglowで正常に稼働した後にFiredancerへ戻す必要があります。
Alpenswitchの実際の流れ
Alpenglowは、任意の時刻にすべての場所で一斉に有効になるわけではありません。機能がアクティベートされると、プロトコルは5,000スロット後に移行境界を設定します。バリデータがこの境界を越えて、十分に強く確認されたブロックを探索する間も、TowerBFTは動作を続けます。その後、バリデータは選択されたAlpenglowジェネシスブロックにBLS署名し、それらのジェネシス投票を互いに直接配布します。
ステークの少なくとも82%が同じジェネシスブロックに署名し、Alpenglowジェネシス証明書が生成されると、切り替えが行われます。その証明書を受信して検証したバリデータは、ジェネシスブロック以降のTowerBFTを無効化し、合意済みの状態からVotorを初期化します。その後、証明書がバリデータセット全体に伝播し、残りのノードも境界を越えて移行します。
この証明書により、インフラストラクチャ運用者はクラスターがAlpenswitchのどちら側にあるかを簡単に判断できます。
Agave 4.3では、新しいRPCメソッドgetAgGenesisCertが導入されます。移行前、Agave 4.3ノードはnullを返します。クラスターの切り替え後は、ジェネシスブロックと集約BLS署名を含むAlpenglowジェネシス証明書を返します。このメソッドに対応していない古いノードは、代わりにMethod not foundを返します。CLIでも同じ情報を次のコマンドで確認できます：solana alpenglow-genesis-info。
したがって、移行に応じて処理を行う必要があるバリデータ、RPCプロバイダー、その他のインフラストラクチャでは、特定のタイムスタンプでAlpenglowが有効になったと仮定するよりも、ジェネシス証明書を確認する方が適切です。
新しい暗号学的syscall
Agave 4.3では、sBPFで直接実行するには極めてコストが高い処理に対応する新しいランタイムプリミティブが追加され、SVMの暗号ツールセットも拡張されます。
注目すべき追加機能は、SHA-512ハッシュと多倍長整数のモジュラーべき乗の2つです。どちらも追加機能であり、機能ゲートによって制御されます。既存のプログラムには影響せず、これらを利用するプログラムは、計算コストの高い暗号処理をバリデータランタイム内の最適化されたネイティブ実装に委任できます。
多倍長整数のモジュラーべき乗
SIMD-0529：多倍長整数ModExp Syscallでは、次の計算を行うsyscallであるsol_big_mod_expが導入されます：
result = (base ^ exponent) mod modulusモジュラーべき乗は、RSA署名検証、暗号学的アキュムレータ、一部の検証可能遅延関数、その他の数論的プロトコルを支える基本的な演算です。SVMプログラム内で任意精度整数演算を使って直接実装すると、特に2048、3072、4096ビットなど一般的なRSA鍵サイズでは、極めて多くのコンピュートを消費します。
新しいsyscallは、コストの高い算術演算をバリデータランタイムに移します。プログラムは底、指数、法をリトルエンディアンの符号なし整数として渡し、呼び出し元が用意したメモリで結果を受け取ります。各オペランドは当初512バイトに制限され、最大4096ビットの整数を扱えます。
最も分かりやすいユースケースはRSA検証です。たとえば、従来型のRSA署名を検証するプログラムは、大整数のべき乗を独自に実装する代わりに、一般的な公開指数65537を使ってsol_big_mod_expを呼び出せます。このsyscallは意図的に算術プリミティブのみに限定されています。ハッシュ、PKCS#1 v1.5やPSSなどのRSAパディング、鍵の検証、プロトコル固有のドメイン分離は、引き続きプログラム側で処理する必要があります。
また、多倍長整数のモジュラーリダクションも効率的に実行できます。指数として1を渡すと、演算は次のように簡略化されます：
base mod modulusこれにより、プログラムは汎用の多倍長整数実装にコストをかけることなく、SVMの組み込みマシンワードサイズを超える整数を剰余演算で縮約するためのネイティブプリミティブを利用できます。
この設計の考え方は、EIP-198で導入されたEthereumのModExpプリコンパイルに似ており、コンピュート計測モデルもEIP-198の演算複雑度の式に従っています。ただし、Ethereumとバイト単位で互換性があるわけではありません。Solanaはネイティブsyscall ABIを通じて機能を公開し、リトルエンディアン入力を使用します。また、法は1より大きい奇数である必要があり、偶数の法は拒否されます。
これにより、SolanaがEVMプリコンパイルインターフェース自体を採用することなく、このsyscallを相互運用に活用できます。Ethereum形式の暗号学的前提に基づく証明、署名、アテステーションを検証するプログラムは、呼び出し方法を調整しつつ、基盤となる同じ算術演算を再利用できます。
SHA-512
2つ目の追加機能ははるかにシンプルですが、すぐに役立ちます。
SIMD-0512：Sha512 Syscallではsol_sha512が追加され、オンチェーンプログラムはバリデータランタイムを通じてSHA-512ハッシュ関数に直接アクセスできるようになります。そのインターフェースは、Solanaの既存のsol_sha256、sol_keccak256、sol_blake3の各syscallに準じており、標準の64バイトSHA-512ダイジェストを返します。
SHA-512は特に、Solana自体が広範に使用している署名方式であるEd25519の中核プリミティブの1つです。AgaveとFiredancerはいずれも内部ですでにSHA-512に依存していますが、この変更までSVMプログラムはその最適化済み実装に直接アクセスできませんでした。SHA-512を必要とするプログラムは、代わりにアルゴリズムをソフトウェアで実装する必要がありました。
コンピュートの観点では、この違いは非常に大きなものです。SIMDの推定では、sBPF実装を使って短い入力をハッシュすると数千CUかかる一方、syscallで同じ処理を実行すると100 CU未満で済みます。sol_sha512は、Solanaの既存のSHA-256 syscallと同じ一般的なコンピュートコストモデルを使用します。
2つのsyscallは合わせて、一般的ではあるものの計算コストが高い暗号プリミティブを個々のプログラムから切り離し、標準化され、計測可能なランタイム処理へ移すというSVMの大きな流れをさらに推し進めます。上位レベルの暗号プロトコルは引き続きプログラムが定義しますが、コストの高い構成要素は、sBPF実装よりもバリデータではるかに効率的に実行できます。
まとめ
Agave 4.3の最大の変更点はAlpenglowです。TowerBFTをVotorに置き換え、ブロックから投票トランザクションをなくし、ファイナリティを秒単位からミリ秒単位に短縮し、バリデータやインフラストラクチャとコンセンサスの関わり方を刷新します。
ほとんどのユーザーとアプリケーション開発者にとって、この移行の大部分は意識せずに進みます。一方、バリデータ、RPCプロバイダー、インデクサー、インフラストラクチャチームにとって、Agave 4.3はSolanaがコンセンサスに到達する方法の大きな転換点となります。
関連リソース
- Alpenglowホワイトペーパーv1.2（2026年7月）
- Agave 4.3リリーススケジュール
- 機能ゲートトラッカーのスケジュール
- Agave 4.3変更履歴
- Agave 4.3プルリクエスト
- Alpenglowアップグレード - Solana Foundation
Heliusを購読
Solana開発の最新情報や新しい記事の公開通知を受け取れます