Solanaの大型更新「Alpenglow（アルペングロー）」は2026年10月21日にメインネットで稼働し、合意形成はTowerBFTからVotorへ移りました。最大の変更は、バリデーターの投票をBLS署名の証明書にまとめ、条件がそろえば約150msでファイナリティ（取引が覆らないと合意された状態）を目指せることです。この150msはプロトコル上の高速経路の目標で、画面表示までの保証時間ではありません。
立場別の読み方
- 一般ユーザー：「Votorへの変更」「150msの成立条件」「一般ユーザーへの影響」で要点をつかめます。
- 開発者・RPC運用者：「TPS」「一般ユーザー・開発者・RPC事業者への影響」で指標、commitment、再接続を確認してください。
- バリデーター：「Agave 4.3とBLS鍵対応」に運用要件をまとめています。
TowerBFTからVotorへ、合意形成はどう変わったか
まなぶ「クリプ先生、AlpenglowはSolanaを丸ごと別のチェーンに入れ替えたんですか？」
クリプ「いや、同じSolanaの中で合意の取り方をVotorへ切り替えたんだ。資産を別チェーンへ移す更新ではないよ。」
Alpenglowの中核はVotorと呼ばれる投票合意プロトコルです。従来のTowerBFTでは、バリデーターの投票が通常のトランザクションとしてブロックに含まれ、複数slotにわたるロックアウトの積み重ねによって確定性を高めていました。Votorでは、バリデーター同士が投票を直接交換し、十分なステーク重みの署名を証明書へ集約します。
「合意」は、参加者が同じ履歴を正しいものとして認める手続きです。「ファイナリティ」は、その履歴が覆らないと扱える状態に達したことを指します。ブロックが作られた瞬間と、最終確定した瞬間は同じではありません。Votorが短くしようとしているのは、主にこの最終確定までの合意経路です。
投票合意をVotorへ一スロットで移行
移行の難しさは、旧方式と新方式が中途半端に混在すると、同じ履歴について異なる確定判断が生じ得ることです。SIMD-0384は、TowerBFTの最後の確定状態を出発点にし、VotorのGenesis certificateへつなぐ手順を定義しました。これにより、利用者側から見れば同じ台帳が続きながら、内部の投票方式は明確な境界で変わります。
「一スロットで移行」という表現は、準備が一瞬で済んだという意味ではありません。クライアント配布、BLS鍵登録、試験網での移行、対応率の引き上げなどは事前に段階的に進められました。一スロットなのは本番台帳上の切り替え境界です。
ブロック伝播は当面Turbine、Rotorは後続段階
Alpenglowの初期構想では、投票合意のVotorと、データ伝播を担うRotorが一緒に語られることがありました。しかし今回のメインネット移行で中心的に導入されたのはVotorです。ブロックデータの伝播には当面、既存のTurbineが使われます。したがって「Alpenglow稼働＝Rotorも全面稼働」と理解するのは正確ではありません。
ブロック提案者がデータをネットワークへ届ける工程と、届いたブロックへ投票して確定させる工程は関連しますが、役割が違います。後者を高速化しても、前者で大きな遅延が起きれば全体の時間は伸びます。約150msを見るときも、Votorだけでなく伝播と処理の時間が体感に加わる点を忘れないでください。
200msスロットとファイナリティは別の指標
Solanaでは別の更新として200msスロットへの短縮が進められてきました。スロット時間はブロック提案機会の間隔、ファイナリティは提案された履歴が最終確定するまでの時間です。両方とも「速さ」の話なので混同されやすいものの、測っている対象は異なります。
たとえば、200msごとにブロックが提案されても、合意に複数の往復が必要なら最終確定はもっと後です。反対にVotorの高速経路が短くても、ブロックの受信や実行、RPC反映が遅ければアプリの表示は150msを超えます。200msスロットの運用上の論点は、既存記事「Solanaの200msスロットとは？」でも詳しく整理しています。
約150msファイナリティが成立する条件
公式ページが示す約150msは、Votorの高速経路が狙うファイナリティです。ネットワークの全地点で常に同じ時間になるサービス水準保証ではありません。投票するステークの割合、ノード間の距離、パケット損失、CPU負荷、ブロック実行時間などによって観測値は変わります。
ここで割合の基準になるのは単純なノード台数ではなく、投票参加者に委任されたステークの重みです。100台中80台が投票したかではなく、投票したバリデーターが対象ステークの何%を占めるかで証明書の成立を判断します。
80%のステークなら一巡で確定
Votorの高速経路では、対象ブロックについて80%のステーク重みが一巡目で投票すると、即時確定に使える証明書が成立します。十分に多くの投票が短時間で集まる正常時を想定した経路です。通信が良好で参加率が高いほど、この経路に乗りやすくなります。
80%という数字は「保有者の80%が手動で賛成ボタンを押す」という意味ではありません。合意参加バリデーターがプロトコルに従って投票し、その委任ステークを含む重みが閾値へ届くという意味です。ウォレット利用者に毎回の操作は求められません。
60%なら二巡で確定
一巡目で80%に届かなくても、60%以上のステークが参加する二巡の経路で確定を目指せます。これは、正常に動く参加者が一時的な遅延や欠落に直面しても、ただちに合意が止まらないようにする仕組みです。ただし投票の往復が増えるため、一巡の高速経路より時間はかかります。
この二つの経路があるため、「150msを超えたらAlpenglowが失敗」と単純には言えません。速い経路が成立しなかったとき、より時間をかけた経路で安全に確定することには意味があります。性能評価では中央値だけでなく、遅いケースの分布であるテールレイテンシや、確定が継続しているかを見る必要があります。
150ms・200ms・観測値は測っている対象が違う
| 数字 | 対象・起点と終点 | 位置づけ |
|---|---|---|
| 約150ms | 提案後、80%超のステーク投票が一巡で証明書になる高速経路 | 条件付きの設計目標。保証値ではない |
| 約200ms | 次のブロック提案機会までのslot時間 | ブロック生成の周期で、確定時間ではない |
| 二巡の経路 | 60%以上のステーク投票を二段階で証明する経路 | 一巡より通信段階が増えるため150ms経路とは分けて評価 |
| devnetの202〜403ms | 外部媒体が試験網で観測したファイナリティ | 一次計測ログで再確認できない参考値 |
202〜403msはYFarmXによる二次情報で、記事作成時点では同じ測定条件の一次ログや独立した複数計測を確認できません。そのため性能の根拠にはせず、試験網での参考値としてのみ扱います。ウォレットや取引所の画面表示にはRPC応答、ポーリング、事業者の内部確認も加わるため、プロトコル確定とは別に測る必要があります。
Solana「Alpenglow」はメインネットで稼働した
Alpenglowは、Solanaのブロックについて「どの状態を最終的なものとして合意するか」を決める仕組みを大きく変える更新です。調査資料では、2026年10月21日13時54分（UTC）ごろ、メインネットのslot 459,653,000で切り替わったと報告されています。日本時間では同日22時54分ごろに当たります。Solana Explorerでは移行境界に関係するGenesis slotが459,652,999と表示されました。
ここでいうslot（スロット）は、ブロックを提案する機会を区切る時間単位です。ブロック高や時刻と似た目印としてニュースに登場しますが、同じ意味ではありません。Alpenglowの開始点を確認するときは、カレンダー上の日付だけでなく、移行用に決められたslotと、新方式の証明書が生成されたかを合わせて見ることが重要です。
切り替えはepoch開始ではなくslot 459,653,000付近
Solanaでは複数のslotをまとめた期間をepoch（エポック）と呼びます。基礎から確認したい場合はSolanaの仕組みの入門解説も参照してください。Alpenglowはepoch 1064で有効化されましたが、epochが始まった瞬間に新しい合意へ変わったわけではありません。事前に固定された移行slotまで旧方式で進み、移行境界をまたいでVotorへ切り替える設計でした。「epoch 1064に入った」という情報だけで稼働済みと判断すると、実際の切り替えとの時間差を見落とします。
移行仕様のSIMD-0384は、TowerBFTで確定した利用者取引を巻き戻さず、新しい合意へ状態を引き継ぐ境界を定めています。境界付近ではユーザー取引の取り込みを止め、投票を中心とする移行処理を行う段階が置かれました。大規模な方式変更を一つのslotで行う一方、前後の状態を明確に区切ることで、どの方式がどのブロックを確定したかを曖昧にしないためです。
時刻だけでなくGenesis certificateなどで稼働を確認
予定時刻を過ぎたことは、稼働確認の十分条件ではありません。ノードやRPCを運用する側は、新方式の起点となるGenesis certificateが得られること、認証済みブロックが継続して進むこと、想定するcommitmentでRPCが応答することを確認します。移行前の案内では、getAgGenesisCertなど新方式に対応した情報を使う考え方が示されました。
一般ユーザーが証明書を直接検証する必要はありません。ただし、ウォレット画面の一時的な遅延やRPCエラーだけを見て「チェーン全体が停止した」と判断するのは早計です。合意層が前進していても、利用中のRPCや索引サービスが再接続中なら表示が遅れる場合があります。チェーンの状態と、自分が接続するサービスの状態を分けて考えるのが基本です。
投票トランザクションをなくすBLS証明書の仕組み
まなぶ「投票がトランザクションから消えたら、誰も投票していないように見えませんか？」
クリプ「投票自体がなくなるわけではないよ。個別取引として記録する代わりに、署名をまとめた証明書で結果を確認するんだ。」
Votorでは、バリデーターが投票を通常トランザクションとしてブロックへ書き込む方式をやめ、ネットワーク上で直接交換します。集まった投票はBLS署名の性質を使って集約され、閾値を満たしたことを示す証明書になります。多数の署名を一つずつ運ぶより、検証に必要なデータをまとめやすい設計です。
BLSは暗号署名方式の一種で、複数の署名を集約できる点が重要です。ここでの目的は投票参加者を匿名にすることではなく、多数の投票を効率よく証明することです。通常の利用者トランザクションの署名方式がすべてBLSへ置き換わったわけでもありません。
個別投票を直接交換し証明書へ集約
従来は投票トランザクションがブロックに含まれるため、エクスプローラーや分析基盤は通常取引と似た流れで投票を数えられました。新方式では、投票は合意ネットワークで交換され、成立した証明書が合意結果を表します。データの意味が変わるため、単に従来と同じトランザクション一覧を読むだけでは投票状況を再現できません。
証明書は、あるブロックに必要なステーク重みの投票が集まったことを検証可能にします。集約後も「十分な重みが署名したか」を確認できる一方、ダッシュボードや監視ツールは証明書由来の情報を扱う必要があります。Solanaの公式週報では、rank map RPCやSuperbankなど周辺実装の対応が紹介されました。
BLS公開鍵をVote Account v4で管理
バリデーターがBLS署名を使うには、対応する公開鍵をネットワークが正しく認識できなければなりません。SIMD-0387は、Alpenglow投票用のBLS公開鍵をVote Accountへ登録・管理する方法を定めています。その受け皿となるVote Account v4には、Alpenglowに必要な状態を格納する拡張が含まれます。
公開鍵の登録は、署名がどのVote Accountに対応するかを検証するための前提です。鍵の生成や登録、アカウント設定に不備があれば、ノードが稼働していても新方式の投票へ正常参加できない可能性があります。これは一般のSOL保有者ではなく、バリデーター運用者が対応すべき項目です。
bank_hashをブロックフッターへ移して実行不一致を検知
bank_hashは、ブロックを実行した結果の状態を識別するための値です。従来は投票に関連付けて扱われていましたが、投票トランザクションがなくなると同じ置き場所を使えません。SIMD-0298はbank_hashをブロックフッターへ移し、バリデーター間で実行結果が一致しているかを検知できるようにします。
これは「同じブロックを見たのに、実行後の状態が異なる」という重大な不一致を見逃さないための変更です。Votorの証明書が投票結果を示し、ブロックフッターのbank_hashが実行結果の整合性確認を支えます。投票の運び方だけを変えるのではなく、旧方式が担っていた検証情報を別の場所へ移す周辺変更が必要でした。
TPSと取引数はなぜ見かけ上減るのか
Alpenglow移行後は、総トランザクション数やTPSが急に下がって見える可能性があります。理由は、従来カウントされていた投票トランザクションがオンチェーンの通常取引から消えるためです。利用者の送金やアプリ操作が同じ量でも、集計の分母・対象が変わればグラフは連続しません。
比較には、投票を除いた利用者トランザクション数、成功率、手数料、実行ユニットなど、定義を固定できる指標を使います。
従来のTPSには投票取引が含まれていた
従来の総TPS表示では、ユーザーが送る取引に加え、バリデーターの投票取引が含まれる場合がありました。投票は合意維持に不可欠ですが、決済やDeFi操作といった利用者需要とは性格が異なります。Alpenglowを境に投票が証明書へ移ると、同じ名称の「総TPS」でも移行前後で中身が変わります。
時系列分析では、切り替え地点に注記を入れ、可能なら投票を除外した指標で再計算する必要があります。前年同時期との単純比較や、移行直前と直後の増減率だけを示すと、仕様変更を需要変化と誤認させるおそれがあります。
証明書由来の投票情報をRPCで補う
分析基盤が必要とする投票情報そのものは消えていません。取得元が通常のトランザクション履歴から、証明書や新しいRPCが提供する情報へ変わります。rank mapのような仕組みは、証明書に反映された投票状況を外部ツールが利用できるようにするための対応です。
開発者は、自分のコードがvote programのトランザクションを前提に参加率やバリデーター行動を算出していないか確認してください。スキーマが同じでも意味が変わる場合があるため、値が取得できるだけでなく、新旧の意味をテストすることが欠かせません。
移行前後のネットワーク活動を同じ指標で比べない
比較するなら、利用者由来の成功トランザクション数、失敗率、手数料、プログラム呼び出し数など、定義を固定できる指標を選びます。ファイナリティは中央値だけでなく上位パーセンタイルや未確定時間も確認します。単一のTPSランキングだけでネットワーク品質を判断しないことが大切です。
メディアやダッシュボードを見る際は、「投票を含むか」「観測地点はどこか」「確定の基準は何か」「集計期間はいつか」の四点を確認すると、数字の誤読を減らせます。
一般ユーザー・開発者・RPC事業者への影響
影響は立場によって大きく異なります。一般ユーザーは原則として資産移行をする必要がありません。一方、RPC、gRPCストリーム、索引データ、確定判定に依存するサービスは、新方式に合わせた挙動確認が必要です。
| 立場 | 主な影響 | 確認事項 |
|---|---|---|
| 一般ユーザー | 原則、資産移行なし | 公式アプリか、便乗詐欺でないか |
| アプリ開発者 | 確定が速くなる可能性 | commitment、再送、タイムアウト |
| RPC・索引事業者 | 移行時の切断やデータ定義変更 | 再接続、欠損補完、投票情報 |
| バリデーター | クライアントと鍵の対応が必須 | Agave 4.3、BLS鍵、Vote Account |
一般ユーザーは原則として追加操作不要
Alpenglowは同じSolanaメインネット上の合意更新であり、SOLやトークンを「新Alpenglowチェーン」へ送る作業はありません。秘密鍵の再入力、資産の交換、特別なエアドロップ申請を求める案内は警戒してください。公式情報と利用中のウォレット・取引所の告知を確認し、不審なリンクへウォレットを接続しないことが重要です。
取引所の入出金が一時停止した場合も、資産移行が必要とは限りません。事業者がネットワークの安定や確定判定を確認するために停止することがあります。再開時刻や対応は各サービスの公式告知で確認します。
RPC・gRPC・索引基盤はcommitmentと切断を確認
アプリはprocessed、confirmed、finalizedなどのcommitmentを使い分けています。合意方式が変わると、それぞれが返るタイミングや再編を想定した待機設計を改めて検証する必要があります。確定が速くなる期待だけでタイムアウトを極端に短くすると、一時的な遅延で誤エラーを増やしかねません。
gRPCストリームやWebSocketは移行中に切断される可能性があります。大きな取引形式を扱う実装では、Transaction v1の変更点も合わせて確認してください。クライアントは指数バックオフなどで再接続し、最後に処理したslotから欠損を補完できる設計が望まれます。索引基盤では移行境界をまたぐデータに重複や欠落がないか、取引・ブロック・証明書を突き合わせます。
RPC URLを変えなくても再接続と再送を検証
エンドポイントが同じでも、合意切り替え時の応答や確定タイミングまで同じとは限りません。送信側は署名状態を照会してから再送を判断し、読み取り側は切断後に最後の処理slotから欠損を補完します。単一RPCの一時応答だけで重大処理を確定しない設計も必要です。
運用時はAgaveの推奨リリースと既知の問題を確認し、node unhealthy、preflight、未確定slot、ストリーム再接続をテストします。
バリデーターに必要なAgave 4.3とBLS鍵対応
まなぶ「一般ユーザーに操作がないなら、アップデートは誰が準備したんですか？」
クリプ「主にバリデーターや基盤運用者だよ。対応クライアント、BLS鍵、Vote Accountの設定をそろえて合意へ参加するんだ。」
バリデーターは一般ユーザーと違い、Alpenglow対応が運用の前提になります。Agave 4.3系への更新、BLS公開鍵の生成と登録、Vote Accountの状態確認、監視項目の変更が必要です。旧版のまま、または鍵設定が不完全なままでは、投票へ参加できず報酬やネットワーク健全性に影響する可能性があります。
Agave 4.3は10%・25%・一般推奨へ段階導入
Anzaのリリース日程では、Agave 4.3をメインネットへ一斉導入するのではなく、10%、25%、一般推奨という段階を踏んで拡大しました。大規模ネットワークでは、少数導入で問題を観測し、対応率を引き上げる方法が移行リスクを抑える助けになります。
移行直前に公開されたv4.3.2にも、BLS証明書検証やVoteState処理などAlpenglow関連の修正が含まれました。バージョン番号が4.3で始まるだけで十分とは限らず、運用者は推奨される具体的なリリース、既知の問題、アップグレード手順をAnzaの公式情報で確認する必要があります。
BLS公開鍵とVote Account設定が投票参加の前提
運用者はBLS秘密鍵を安全に生成・保管し、対応する公開鍵を正しいVote Accountへ登録します。公開鍵の不一致や登録漏れは、証明書に有効な署名として加われない原因になります。秘密鍵をオンライン環境で安易に共有したり、第三者の非公式手順へ貼り付けたりしてはいけません。
監視では、プロセスが起動しているかだけでなく、Votor投票が送受信できているか、証明書が検証できるか、期待するactive setに入っているか、遅延が継続していないかを確認します。切り替え後は旧来の投票トランザクション数だけを死活監視に使えません。
active set上位2000という参加条件
Alpenglowの合意とリーダー選出に関するactive setは、ステーク上位2000へ制限する設計が議論・採用されています。これは合意メッセージの規模を抑える一方、小規模バリデーターの直接参加やステーク集中への影響を継続して見る必要がある論点です。
上限だけを見て直ちに「中央集権化した」または「問題ない」と結論づけることはできません。上位2000内のステーク分布、事業者の独立性、地理・インフラの偏り、上限外ノードの役割を合わせて評価します。仕様上の人数と、実質的な支配主体の数は同じではありません。
稼働直後に残る未検証点と今後の焦点
メインネットで稼働した事実と、長期にわたって安定した事実は別です。Alpenglowは合意方式を全面的に置き換える大きな更新であり、本番稼働から長期間の障害率、地理条件ごとの遅延、負荷ピーク時の挙動は、今後の観測で評価されます。
公式仕様も実装と移行の複雑さを欠点として認識しています。ニュースの初動だけで成功・失敗を断定せず、確定停止、証明書生成、クライアント別の挙動、RPC障害、ステーク参加率など複数の指標を追う姿勢が必要です。
本番前の再起動とロールバックから見る移行リスク
CoinDeskの報道によれば、本番前には試験網で6回の再起動があり、移行失敗後にロールバックした例もありました。試験で問題を発見して修正すること自体は開発工程の一部です。同時に、本番の変更が単純な設定切り替えではなく、慎重な検証を要することも示しています。
試験網で成功したから本番でも同じ結果が保証されるわけではありません。ステーク分布、トラフィック、参加者の運用環境が異なるためです。一方、試験中の失敗だけを根拠に本番が失敗すると決めつけるのも適切ではありません。修正後の版と本番観測を区別して評価します。
テールレイテンシと長期安定性は観測継続が必要
平均や最速値だけでは、利用者が遭遇する遅延を十分に表せません。大半が速くても、ごく一部の確定に長時間かかるなら、取引所や決済アプリはその遅いケースを考慮する必要があります。時間帯、地域、ネットワーク負荷、クライアント版ごとの分布を継続観測することが重要です。
また、プロトコル確定が速くても、サービスが独自に追加確認を待つ場合があります。取引所の入金反映時間が直ちに150msになるわけではありません。事業者はリスク管理や内部処理に応じて反映基準を決めるため、利用者は各サービスの表示を確認してください。
20%悪意・20%オフライン耐性と分散性を監視
公式説明では、Alpenglowは20%の悪意あるステークと、別の20%のオフラインなステークがある状況への耐性を掲げています。これは設計上の障害モデルであり、「合計40%がどんな行動をしても必ず150msで確定する」という意味ではありません。安全性と進行性、速い経路が成立する条件を分けて読みます。
障害耐性はステークが独立した運用主体へ分散しているほど実効性を評価しやすくなります。リーダー配置の地域的な偏りについては地理対応リーダースケジュールの解説が参考になります。同じクラウド、地域、クライアント構成への偏りがあれば、別々のバリデーターでも同時障害が起こり得ます。active setの集中度とインフラ相関は、ファイナリティの数字と並ぶ監視項目です。
次段階の複数提案者化は将来計画
2026年10月9日の開発者議論では、テストネットとdevnetでの有効化後、将来の方向として複数提案者構成などが示されました。これは今後の技術的な検討であり、今回のメインネット稼働時点ですべて実装済みという意味ではありません。Rotorと同様、現在の機能と将来計画を分けて扱う必要があります。
まとめ：150msの数字より、条件と観測方法を見る
Alpenglowは2026年10月21日、slot 459,653,000付近でSolanaメインネットの合意をTowerBFTからVotorへ切り替えました。Votorは投票を直接交換し、BLS集約署名による証明書を作ることで、十分な投票が速く集まる場合に約150msのファイナリティを目指します。80%のステークによる一巡の高速経路と、60%による二巡の経路があり、150msは固定保証ではありません。
一般ユーザーは原則として資産移行やウォレット操作が不要です。開発者とRPC・索引事業者はcommitment、再接続、投票情報の取得方法、TPS定義を見直し、バリデーターはAgave 4.3系、BLS鍵、Vote Accountを確認する必要があります。稼働直後は、長期安定性、テールレイテンシ、active setの集中度、将来機能を継続して観測する段階です。
今後の情報を見るときは、①プロトコル上の確定時間か利用者体感か、②高速経路の条件を満たしたか、③投票を除いた活動指標か、④現在の実装か将来計画か、の四点を確認してください。この区別ができれば、「150ms」という目立つ数字だけに引っ張られず、更新の実像を判断できます。
