ソラナのAlpenglowを解説：Votorでコンセンサスはどう変わるか

要点

• Solana（ソラナ）は2026年10月21日（水）、mainnet-betaでコンセンサスをTowerBFTから、Alpenglow設計の前半部分であるVotorに切り替える予定です。バリデータクライアントAgaveの開発元であるAnzaは、稼働時刻をUTC 14時50分ごろとしています。
• Solana Foundationによると、ファイナリティ（取引の最終確定）までの時間は約12.8秒から、目標値で約150ミリ秒に短縮される見込みです。同財団はこの数値を「期待値であり、定数ではない」としています。
• Anzaによると、Votorは悪意あるステーク20%と、オフラインのステーク20%が同時に存在しても動作を続けられます。TowerBFTが許容できた悪意あるステークは33%未満でした。
• Alpenglowの後半部分であるRotorは、ブロック伝播層Turbineを置き換えるものです。今回の切り替えには含まれず、リリース日も決まっていません。
• 移行は稼働中のネットワーク上で再起動なしに行われます。ステークの82%が「ジェネシス証明書」に署名する必要があり、移行に参加できるのはAgaveベースのクライアントのみです。

Alpenglowとは

Alpenglowは、Anzaの研究者が設計したSolanaの新しいコンセンサスプロトコルです。コンセンサスとは、どのブロックが確定したかについてバリデータが合意するための仕組みです。Solanaはローンチ以来、暗号学的な時計であるProof of Historyと結びついた投票システム、TowerBFTを使ってきました。TowerBFTでは、バリデータは投票を通常のオンチェーン取引として送信します。こうした投票はブロック容量の大きな割合を占め、ブロックは何度もの確認ラウンドを経て初めて確定したとみなされます。

Alpenglowはこの役割を2つの構成要素に分けます。Votorは投票とファイナリティを担当します。Rotorはバリデータ間でのブロックデータの伝送を担当します。Anzaは10月21日の切り替えをフェーズ1と位置づけており、既存の伝播層Turbineを残したままVotorを稼働させます。バリデータは2025年9月のガバナンス投票でAlpenglow提案全体を承認しました。Decryptによると、投じられた票の約98%が賛成でした。

Solana Compassが伝えたAnzaの発表によると、Anzaはこの移行を、稼働中のネットワークでコンセンサスエンジンを入れ替える世界初の事例だとしています。これはAnza自身の主張であり、Bullquillは独自に検証していません。同社はまた、この取り組みを、1スロットで完了する移行のための18か月にわたる作業だと説明しています。

Votorでコンセンサスはどう変わるか

Solana Foundationのアップグレードページは、主な変更点として次の3つを挙げています。

投票がチェーンの外へ

Votorでは、バリデータは投票を取引としてではなく、互いに直接送り合います。その投票はBLS署名を使ってコンパクトな証明書に集約されます。準備段階として、バリデータのBLS鍵は2026年7月8日にメインネットで有効化されました。証明書は個々の投票取引としてではなく、ブロックの「フッター」に記録されます。

ファイナリティへの2つの経路

Votorは2つの投票経路を同時に走らせ、先にブロックを確定させた経路が採用されます。高速経路では、ステークの80%以上がブロックの公証（notarize）に投票すれば、1ラウンドで確定します。この閾値に届かない場合は、2回目のラウンドでステークの60%によってブロックが確定します。公証証明書とスキップ証明書にも同じ60%の閾値が適用されます。AnzaのAlpenglowページによると、投票の速さはバリデータの所在地に左右されるため、どちらの経路が先に確定するかは地理的要因の影響を受けます。

Proof of Historyはブロックのペースを決めなくなる

同財団によると、tickは台帳から除かれ、Clock sysvarのタイムスタンプはブロックリーダーが一定の範囲内で設定します。そのため、Proof of Historyはブロック生成のペースを決めなくなります。これとは別に、スロット時間は2026年10月に4段階で400ミリ秒から200ミリ秒に短縮されました。同財団は、ブロック時間とファイナリティは別の指標だと強調しています。

数値：確定した設計値と目標値

次の表は主な数値と、それぞれがどのような性質の主張かを示したものです。「設計パラメータ」はプロトコル仕様に書かれたルールを、「目標」はメインネットでまだ測定されていない性能目標を意味します。

データは2026年10月21日の本記事調査時点のもので、出典は下記のとおりです。

目標が達成されれば、12.8秒から150ミリ秒への短縮により、ファイナリティは約85倍速くなります。2026年5月、Anzaのリードエコノミストであるマックス・レズニック（Max Resnick）氏はDecryptに対し、テストクラスターをTowerBFTからAlpenglowに切り替えた際、ファイナリティまでの時間が「約100分の1になった」と語りました。どちらの数値も、メインネットの本格的な負荷のもとではまだ測定されていません。

切り替えの手順

移行手順は、AnzaのKobi Sliwinski氏、Ashwin Sekar氏、Carl Lin氏が執筆したSIMD-0384で定められています。Solana Foundationのページと同仕様は、次の流れを説明しています。

1. フィーチャーゲート。Alpenglowの機能はエポック1064の開始時に有効化されます。Anzaは「すぐに移行するものは何もない」としています。エポックの最初の5,000スロットの間はTowerBFTが動き続けます。
2. 投票専用ブロック。その5,000スロットの後、ブロックにはバリデータの投票しか含めることができなくなります。この間、ユーザー取引は一時停止します。同財団は、コンセンサスの引き継ぎをスロット459,653,000としています。
3. ジェネシス証明書。バリデータは直近のブロックをAlpenglowの起点となる「ジェネシスブロック」として選び、それに対するBLS投票に署名します。ステークの82%以上が署名すると、ジェネシス証明書が形成されます。
4. ロールバックと引き継ぎ。バリデータはジェネシスブロック以降の投票専用ブロックを破棄し、コンセンサスをVotorに引き渡して、ユーザー取引を再開します。SIMD-0384は、ユーザー取引への影響は「楽観的に見て、移行境界スロットから1スロット分のみ」としています。Anzaは引き継ぎに数百ミリ秒かかると見込んでいます。

時刻はあくまで推定

公表されている時刻にはずれがあります。Solana Foundationは、エポック1064の開始をUTC 13時20分ごろと推定しています。Solana Compassが伝えたAnzaの発表では、稼働時刻はUTC 14時50分ごろです。Solana Compassは、14時50分がフィーチャーゲートの有効化を指すのか、引き継ぎを指すのかをAnzaが明らかにしていないと指摘しました。エポックの境界はスロットの生成速度に左右されるため、正確な時刻は前後する可能性があります。AnzaのAlpenglowページも、観察期間でこれまでのテスト結果が確認された後にメインネット移行を「発表する」としています。本記事の執筆時点で、Bullquillはメインネットのジェネシス証明書が形成されたことを示す公式な確認を見つけていません。

日付自体も変わりました。9月下旬には、有効化が9月28日になる可能性があるとの報道がありました。KuCoin Newsによると、Solana共同創業者のアナトリー・ヤコヴェンコ（Anatoly Yakovenko）氏とAnzaの研究責任者ロジャー・ワッテンホファー（Roger Wattenhofer）氏は、X上でこれらの報道を否定しました。その後、10月21日の日程が決まる前に、テストネットが9月24日、デブネットが9月25日に移行しました。

バリデータが準備すべきこと

• クライアント。Solana Foundationによると、バリデータはエポック1064までに、Agave、Jito-Solana、Harmonic Salsaのいずれかのv4.3.2を稼働させる必要があります。移行期間中、FiredancerとFrankendancerはサポートされません。
• 投票アカウントの残高。バリデータは、Validator Admission Ticketの支払いに備え、投票アカウント（アイデンティティアカウントではない）に、レント免除の最低額を0.8 SOL以上上回る残高を維持する必要があります。最初のチケット代はエポック1064の開始時に徴収され、エポック1065分に充てられます。支払えないバリデータは、次のエポックで投票もブロック生成もできません。
• サポート対象外クライアントのステーク。Solana Compassは10月13日時点で、上位500バリデータのステークのうち約15.8%がFiredancer系クライアント上にあると集計しました。同社の計算では、サポート対象のクライアントに残るのは約84%で、ジェネシス閾値の82%をわずかに上回る水準です。このデータは1週間前のもので、その後クライアントを切り替えた運営者もいる可能性があります。
• Jito BAM。Solana CompassによるJitoの変更履歴の読み解きによると、JitoはメインネットのBAMノードを有効化前にメンテナンスモードに移行するとし、移行期間中はFireBAMやFrankenBAMを稼働させないよう勧めています。

開発者と利用者が気づく変化

• 取引数は減るが、活動の減少を意味しない。投票がブロックから外れるため、すべての取引を数えるダッシュボードでは急減が表示されます。Solana Compassが引用した10月10〜12日のデータでは、投票は平均で毎秒約3,060件、ユーザー取引は毎秒約1,780件でした。同財団はこれを「会計上の変更」と呼んでいます。
• コミットメントレベル。processed、confirmed、finalizedはいずれも残り、有効化当日にコードを変更する必要はありません。有効化後はconfirmedとfinalizedが同じ状態を示すようになり、confirmedは今後のリリースで削除されます。同財団は、コードをfinalizedに切り替えるのはAlpenglowの稼働後にするよう勧めています。
• 切り替え済みかどうかの確認。RPCメソッドgetAgGenesisCertは、クラスターがTowerBFTで動いている間はnullを返し、移行後は証明書を返します。v4.3より古いRPCノードは「Method not found」エラーを返します。同財団は、Alpenglow固有の処理を日付ではなく、この呼び出しの結果に基づいて切り替えるよう勧めています。
• データパイプライン。1つのスロットに複数の候補ブロックが含まれる場合があります。同財団は、GeyserやgRPCの利用者に対し、データをスロットとbank_idごとにバッファリングするよう勧めています。

一般の利用者にとって想定される主な変化は、取引が取り消し不能な完全なファイナリティにはるかに速く到達することです。同財団は、Votor単独で手数料や処理能力が具体的にどう変わるかについては約束していません。

確定済み、予定、未検証の事項

影響と意味

Alpenglowは、これまでで最大のSolanaコアプロトコルの変更です。ネットワークがローンチ以来使ってきた投票システムを置き換えます。Votorが目標を達成すれば、決済、取引所、クロスチェーンブリッジなど決済の確実性を必要とするアプリケーションは、10秒以上待つことなく、1秒にも満たない時間で取引を確定済みとして扱えるようになる可能性があります。投票がブロックから外れることでネットワーク活動の測り方も変わるため、10月21日の前後で1秒あたりの取引数を比べても、同じ条件での比較にはなりません。

実行面のリスクも現実に存在します。引き継ぎは、ステークの82%が適切なタイミングでサポート対象のソフトウェアを稼働させていることが前提であり、Firedancer系クライアント上のステークの割合を考えると、余裕はわずかです。移行中はクライアントの多様性が低下します。耐障害性のモデルは新しく、テストネットワークでしか試されていません。150ミリ秒という数値は、ステークの分布と地理的条件に左右されます。注目すべき点は、ジェネシス証明書が予定どおり形成されるか、ユーザー取引の停止がどのくらい続くか、最初の数日間のファイナリティ時間がどうなるか、そしてFiredancerとRotorの日程がいつ決まるかです。

出典

• Solana Foundation: Alpenglow upgrade page
• Anza: Alpenglow
• SIMD-0384: Alpenglow migration (Solana Improvement Documents)
• Solana Compass: Anza sets Alpenglow mainnet date
• Decrypt: Solana Alpenglow upgrade begins testing ahead of full rollout
• KuCoin News: Solana developers deny Alpenglow mainnet activation on September 28
• Jito BAM changelog, September 23 to October 9

この記事は情報提供のみを目的としており、投資助言ではありません。