Alpenglow（アルペングロー）は、Solanaの合意形成をTowerBFTから刷新する新コンセンサスです。2026年10月21日にメインネットで稼働し、目標ファイナリティは約150ミリ秒。DEX取引やDeFi決済の確定待ちを短縮する一方、アプリ開発者にはデータ取得方法や監視指標の見直しが求められます。
Solana史上最大級の刷新、Alpenglowが稼働
CoinDeskは10月21日、Solanaが2020年のネットワーク開始以来で最大級となる基盤刷新「Alpenglow」を同日に有効化すると報じました。その後、Solana Foundationの公式ページは、エポック1064が始まった同日13時36分ごろ（UTC）にメインネットで稼働したと更新しています。移行の起点となったブロックはスロット459,652,999で、Alpenglowによる合意形成は次のスロットから始まりました。
今回置き換えられたのは、取引を実行するSolana Virtual Machine（SVM）ではなく、バリデータがブロックの順序と確定を決める合意形成層です。トランザクション形式、オンチェーンプログラム、アカウントモデル、手数料の仕組みは変更されていません。そのため、Jupiterでスワップする一般利用者が、新しい署名方式を覚えたり既存資産を移し替えたりする必要はありません。変化の中心は、送信後の取引を「覆らない」と判断できるまでの時間です。
約150ミリ秒のファイナリティは何を変えるのか
従来のTowerBFTでは、バリデータの投票自体がオンチェーンのトランザクションとして記録され、十分な投票が積み重なるまで待つ必要がありました。Solana公式資料では、従来の完全なファイナリティを約12.8秒、Alpenglowの目標を約150ミリ秒と説明しています。なお、この数値はブロック生成間隔ではありません。スロット時間を400ミリ秒から200ミリ秒へ短縮した別のアップグレードと、今回の合意形成刷新は分けて理解すべきです。
DEXでは、価格提示、署名、ネットワーク送信、約定、確定という複数段階があります。JupiterのSwap APIも、見積もり取得、トランザクション構築、署名・送信を別工程として扱います。Alpenglowが直接短縮するのは主に最後の確定部分です。したがって、相場急変時のスリッページ、優先手数料、RPCの混雑、ルート選択の品質まで自動的に改善するわけではありません。それでも、確定を待って次の処理へ進む決済、入出金、連続取引では、待ち時間の短縮が利用体験を改善する可能性があります。
Votorが投票をオフチェーン化する仕組み
Alpenglowの第1段階「Votor」では、バリデータが投票を通常のトランザクションとしてブロックへ書き込む方式をやめ、相互に直接送ります。集まった投票はBLS署名で集約され、必要なステーク比率の投票を示す証明書になります。公式SIMDでは、ステークの80％によるnotarize投票で1ラウンドの高速確定、または60％のnotarization証明書と60％のfinalization証明書による2ラウンド確定が定義されています。
重要なのは、Alpenglow全体が一度に導入されたわけではない点です。今回稼働したのはVotorで、ブロックデータの伝播方式を置き換える「Rotor」は将来段階として未スケジュールです。Jupiterのようなアプリが使うSVM実行環境は維持されます。高速化という見出しだけから、プログラム処理能力やDEXの価格発見まで同時に刷新されたと解釈するのは正確ではありません。
テストで失敗とロールバックを経験した理由
大規模な合意形成変更には、実装バグだけでなく、異なるデータセンター、遅延、バリデータ構成での挙動を確かめる必要があります。Galaxy Digitalは、2026年6月からコミュニティテストクラスターへ参加し、6回の再ジェネシス、ネットワーク全体で失敗した移行、ロールバック、その後の移行成功を経験したと説明しています。テスト環境は本番資産を扱わず、こうした障害を発見するために設けられたものです。
この経緯は「失敗したから危険」と単純化する材料でも、「本番は完全に安全」と断定する根拠でもありません。むしろ、Solana Foundation、Anza、Galaxyなどが本番前に移行手順を反復し、失敗条件を確認した事例です。メインネット稼働後も、ファイナリティの実測値、フォークやスキップの発生状況、RPC事業者ごとの差、アプリ側のタイムアウト設定を継続的に見る必要があります。
バリデータ費用とネットワーク統計の読み方
オンチェーン投票がなくなるため、従来の投票トランザクション手数料もなくなります。代わりにValidator Admission Ticket（VAT）が導入され、投票アカウントからエポックごとに0.8 SOLが徴収・バーンされます。投票アカウントが免除最低残高に加えて必要額を持たなければ、次のエポックで投票やブロック生成に参加できません。これはAgave、Jito-Solana、Harmonic Salsaを運用する事業者にとって重要な資金管理項目です。
一方、投票がブロックから消えることで、Solanaのトランザクション数は見かけ上、大きく減る可能性があります。Jupiterを含むアプリ上のユーザー取引が急減したとは限りません。ダッシュボード運営者は、ユーザー取引とバリデータ投票を混ぜた旧指標を基準にせず、Alpenglow稼働後の新しいベースラインを作る必要があります。表面的なTPS低下だけでネットワーク需要の減少を判断するのは避けるべきです。
DEX・DeFi利用者と開発者が確認すべき点
一般利用者は、Jupiterなどの画面で「送信済み」と「確定済み」を区別し、ウォレット残高とエクスプローラーの状態が一致してから次の操作へ進む基本を維持すべきです。高速確定になっても、偽トークン、価格影響、流動性不足、MEV、スマートコントラクトの不具合、署名内容の誤認といったリスクは残ります。レンディングやレバレッジ型ポジションでも、確定の短縮が市場価格変動や清算リスクそのものを消すわけではありません。
開発者側では、より具体的な対応が必要です。Solana公式は、GeyserやgRPCのストリームで1スロットに複数のbankが現れ得るため、(slot, bank_id)単位で一時保存し、確定したbankだけを採用するよう案内しています。複数プロバイダーのストリームを統合する場合、bank_idは接続ごとのローカル値なので、照合にはblockhashを使います。また、confirmedとfinalizedが同じ状態を示すようになったため、新規実装はfinalizedを使い、従来の秒単位の待機・再試行設定を再検証する必要があります。Jupiter連携サービス、独自インデクサー、清算ボット、会計基盤は、表示速度だけでなくデータ整合性を優先して移行すべきです。
まとめ
Alpenglowは、Solanaの実行環境を作り直すのではなく、バリデータの投票とファイナリティを刷新するアップグレードです。Votorの稼働により、投票はオフチェーンで交換・集約され、目標ファイナリティは約150ミリ秒になりました。JupiterのようなDEX・DeFiアプリでは、決済確定後に次の処理へ進むまでの待ち時間短縮が期待できます。
ただし、高速な合意形成はスリッページ、流動性、RPC品質、MEV、清算、コントラクトリスクを解決しません。利用者は確定状態と取引条件を引き続き確認し、開発者はbank単位のストリーム処理、blockhashによる照合、指標の再基準化を進める必要があります。稼働直後は公称目標だけで評価せず、Solana公式の運用情報と実測データを継続して確認することが重要です。
