Solanaの次世代コンセンサス「Alpenglow」が、devnetとtestnetの両公開テストネットワークで稼働を開始した。 目標は、現在約12.8秒を要するコンセンサス上のファイナリティを約150ミリ秒へ短縮することだ。 ただし、メインネット導入日は未定であり、実市場と同等の負荷でも目標性能を維持できるかは今後の検証課題となる。
Alpenglowが2つの公開テストネットで稼働
CoinDeskが2026年9月26日に報じたところによると、Solanaのコンセンサス刷新計画Alpenglowは、devnetとtestnetの両方で稼働する段階に入った。Anzaは9月25日にdevnetの移行を発表しており、その前日にはtestnetも移行を完了している。
devnetは、価値を持たないテスト用トークンを使い、ウォレットやJupiter、Raydium、Orcaのようなアプリケーションに接続するソフトウェアを検証する環境だ。一方のtestnetは、主にバリデータ運用やネットワークソフトウェアの負荷試験に使われる。性格の異なる両ネットワークでAlpenglowが動き始めたことで、アプリ開発者とインフラ事業者がメインネット移行前に問題を洗い出せるようになった。
今回の到達点はメインネット実装ではない。Solana Foundationの移行資料も、各クラスターは個別のスロットで切り替わるため、予定日やソフトウェアのバージョンだけで稼働状態を判断しないよう求めている。実際の判定には、新しいRPCメソッドgetAgGenesisCertまたはCLIのsolana alpenglow-genesis-infoを利用する。
約150ミリ秒のファイナリティとは何か
ファイナリティとは、承認された取引がコンセンサス上で覆らない状態に達することを指す。現行のTowerBFTでは、早い段階のconfirmedはおおむね1スロットで得られる一方、より強いfinalizedの保証には約12.8秒を要する。AlpenglowのVotorは、この最終確定を約150ミリ秒へ短縮することを目標としている。
高速経路では、ステークの80％によるnotarize票がそろうと、1回の投票ラウンドでブロックを確定する。高速経路が成立しない場合は、60％を基準とする証明書と2回目の投票を使うフォールバック経路へ進む。したがって「すべての取引が常に150ミリ秒で確定する」という保証ではなく、正常なネットワーク状態で狙う目標値として理解すべきだ。
Solana Foundationによれば、Alpenglowはコンセンサスを変更する一方、SVMによるプログラム実行、取引形式、手数料、アカウントモデルは変更しない。Phantomなどのウォレットで署名する一般利用者に、移行作業は予定されていない。
DEX・DeFiで期待される実用上の効果
ファイナリティの短縮は、DEXの約定エンジン自体を高速化する変更ではない。Jupiterのルート探索、RaydiumやOrcaのAMM計算、Solana上のプログラム実行速度は別の処理だからだ。それでも、確定状態を待つ周辺工程には大きな影響があり得る。
例えば、取引所がSOLやUSDCの入金を確認して残高へ反映する場面では、finalizedを待つ時間を短縮できる可能性がある。DeFiのフロントエンドも、スワップ、担保追加、返済などの操作について、より強い確定状態を早く利用者へ表示できる。決済アプリでは、店舗側が支払い完了を判断するまでの待ち時間を短くできる。
一方、ユーザーが体感する時間はファイナリティだけで決まらない。RPCへの送信、リーダーへの到達、優先手数料、混雑、アプリ側の再試行、価格更新なども関係する。Alpenglowを根拠に、JupiterやRaydiumの全取引が一律150ミリ秒で完了すると説明するのは正確ではない。
バリデータ投票がブロックから消える
Alpenglowでは、バリデータが投票をブロック内の取引として記録する方式をやめ、投票を相互に直接送信する。集めた投票はBLS署名による証明書へ集約され、Votorがブロックの確定やスキップを判断する。
この変更により、Solanaの総トランザクション数やTPSの見え方が変わる。従来の統計にバリデータ投票が含まれている場合、Alpenglow移行後は、JupiterのスワップやUSDC送金など利用者の活動が同じでも表示上の取引件数は減少する。これは利用減や処理能力低下を直接意味しない。
Duneなどの分析基盤、ブロックエクスプローラー、独自ダッシュボードを運用する事業者は、vote transactionを含む旧指標と、ユーザー取引中心の新指標をそのまま比較してはいけない。アラートの基準値や過去チャートにも、新しい集計条件を明記する必要がある。バリデータの参加状況も、従来のVote Program命令ではなく、Alpenglowのブロックフッターに含まれる証明書から取得する設計へ変わる。
DEX開発者とインデクサーが確認すべき変更
単に取引を送信し、確定済みのアカウント状態を読むアプリは、基本的に大幅な移行を必要としない。注意が必要なのは、GeyserやYellowstone gRPCを使い、処理途中の取引・アカウント・ブロック情報を低遅延で読むサービスだ。DEXの価格配信、清算監視、ポートフォリオ表示、MEV対策基盤などが該当する。
Agave 4.3では、同一スロットに複数の候補bankが存在する状況を扱うため、ストリームへbank_idが追加される。受信側はスロット番号だけでイベントをまとめず、接続ごとの(slot, bank_id)で候補を分離し、Confirmedへ到達したbankだけを採用する必要がある。候補を混ぜると、実在しない取引履歴やアカウント状態を組み立てる恐れがある。
さらに、bank_idは各ノードが割り当てるローカルな値である。複数のRPC・gRPCプロバイダーからデータを統合する場合、異なる接続のbank_id同士を照合してはならない。プロバイダー間の突合には、確定後のblockhashを利用する。
開発チームはdevnetで、スワップ送信、残高更新、再接続、重複イベント、候補bankの破棄を試すべきだ。testnetでは、バリデータ障害や負荷がある状況でもインデクサーが不整合を起こさないか確認したい。Yellowstoneのブロック購読を利用する場合も、Agave 4.3対応版への更新状況とリリースノートを確認する必要がある。
メインネット移行前に残る注意点
Alpenglowのメインネット開始日は、今回の報道時点で設定されていない。約150ミリ秒という値も目標であり、実資金が動くメインネットの地理的分散、混雑、障害、敵対的な通信条件で継続的に達成された実績ではない。
技術面では、コンセンサスをTowerBFTから置き換える大規模な変更であること自体がリスクになる。AnzaはAlpenglowの中核実装を対象とする監査やバグ報奨金プログラムを実施している。バリデータにはBLS公開鍵の登録と対応するAgaveへの更新が必要であり、アプリ側にもストリーム処理や統計基準の見直しが求められる。
DeFi事業者は、本番導入前にタイムアウト値を一律で短縮するのではなく、クラスターが実際にAlpenglowへ移行したことをRPCで確認する設計にすべきだ。TowerBFT稼働中にfinalized前提へ早期移行すると、従来どおり約12.8秒待つことになり、かえってUXを悪化させる可能性がある。
まとめ
Alpenglowがdevnetとtestnetの両方で稼働したことは、Solanaの約150ミリ秒ファイナリティ構想が、仕様検討から公開環境での検証へ進んだことを示す。Jupiter、Raydium、OrcaのようなDEXを利用する一般ユーザーに直接の移行操作は予定されていないが、入金確認、決済完了表示、DeFi操作の確定待ちには改善余地がある。
開発者にとって重要なのは、速度の数字だけではない。投票取引の消失に伴うTPS統計の再定義、bank_id単位の候補管理、複数データプロバイダーの正しい突合が実務上の焦点となる。メインネット日程と実環境での性能はまだ確定していないため、現段階では公開テストネットで互換性と障害時の挙動を検証することが現実的な対応である。
