公開2026.05.12更新2026.11.13 ブロックチェーン

Solana Alpenglowとは？2026年10月21日にメインネット稼働したVotorの仕組みと変更点

Alpenglow（アルペングロウ）は、Solanaの合意形成（コンセンサス）をTowerBFTから置き換えた新しいプロトコルです。2026年10月21日13時36分（UTC）ごろに始まったepoch 1064でメインネットの機能が有効化され、約18分後のスロット459,653,000から新方式で動いています。確定（ファイナリティ）までの時間は約12.8秒から約150msが目標になりました。この記事では、投票部分Votorの仕組み、Proof of Historyの廃止、開発者とバリデーター運用者が対応すべき変更点、まだ入っていないRotorまでを、公式ページとSIMD（Solanaの改善提案）の原文で確認した内容で整理します。

まとめ｜Alpenglowの要点

稼働状況：メインネットはepoch 1064（2026年10月21日）で有効化済み。devnetは2026年9月25日に先行。
入ったのはVotorだけ：投票を取引ではなくバリデーター間の直接通信にし、80%なら1回、60%なら2回の投票で確定。ブロック伝播を担うRotorは未導入で日程も未定。
150msの意味：取引が確定するまでの目標値。ブロックの間隔（スロット時間）は別の変更で2026年10月9日に400msから200msへ短縮済み。
開発者：confirmedとfinalizedが同じ状態を指すようになった。Geyserで受ける場合は1スロットに複数の候補ブロックが来る前提で作り直す。
運用者：Anzaが示す現在の最低サポート版（Agave v4.4.1・Firedancer v26.10.6）以上で動かし、投票アカウントにVAT（1エポック0.8 SOL）を残しておく。払えないと次のエポックは投票もブロック生成もできない。

Alpenglowとは｜TowerBFTとProof of Historyを置き換えた経緯

Alpenglowは、Solanaのクライアント開発を担うAnzaが2025年5月19日に発表ブログと白書で公開した合意形成プロトコルです。設計はETHチューリッヒのRoger Wattenhofer教授の研究室によるもので、Anzaは「Solanaのコアプロトコルで過去最大の変更」と位置づけています。置き換えの対象は2つで、投票と確定の仕組みだったTowerBFTと、時刻の証明に使っていたProof of History（PoH）です。取引の実行環境（SVM）・取引の形式・手数料の仕組みは変わっていません。

TowerBFTの確定時間と32スロットの投票

TowerBFTでは、バリデーターが投票を取引としてブロックに書き込み、32スロット分の投票が積み重なってはじめてブロックがfinalized（取り消し不能）になりました。これが約12.8秒です。投票取引は各バリデーターがスロットごとに送るため、ブロック内の取引のかなりの部分を占めていました。Alpenglowは投票をチェーンの外へ出し、1〜2回の投票で確定させることで、待ち時間と投票が使っていたブロックの空間の両方を減らしています。

発表からメインネット稼働までの年表

日付	出来事
2025年5月19日	Anzaが発表、白書v1.0公開
2025年7月25日	SIMD-0326を作成
2025年9月2日	ガバナンス投票で賛成98.27%
2026年7月8日	BLS公開鍵の登録（SIMD-0387）を有効化
2026年7月22日	VAT（SIMD-0357）を有効化
2026年9月25日	devnetでAlpenglow有効化
2026年10月9日	スロット時間200msへ短縮完了
2026年10月21日	メインネットで有効化（epoch 1064）

ガバナンス投票の内訳は賛成98.27%・反対1.05%・棄権0.69%で、ステークの約52%が投票しました（Solana Statusの集計を伝えたCryptoSlateの報道）。メインネットの切り替えでは、機能が有効になった後もTowerBFTのまま5,000スロット（約18分）動き、最後のスロット459,652,999が新方式の起点（ジェネシスブロック）になりました。この起点への証明書には、参加していた654のバリデーターのうち446が署名しています（Solana Foundationのアップグレードページ）。

Votorの仕組み｜80%なら1回、60%なら2回の投票で確定

Votorは、各バリデーターが投票を取引ではなく小さなメッセージとして互いに直接送り、集まった票を証明書（certificate）にまとめる方式です。票はBLS署名で1つに集約できるため、検証する側はバリデーターのBLS公開鍵と票があれば、誰でも証明書を組み立てて確かめられます。各スロットの最初の投票では、プロトコルに従うバリデーターは「承認（notarize）」か「スキップ」のどちらか一方を選びます。

確定に至る3つの経路

経路	条件	結果
高速経路	1回目で承認がステークの80%以上	その場で確定
2回の投票	1回目の承認が60%以上80%未満	2回目の確定票60%以上で確定
スキップ	スキップ票が60%以上	そのスロットは飛ばす

2つの経路は同時に進み、先に終わった方が採用されます。通常のRPCコミットメントには、どちらの経路で確定したかを示す別の状態はありません。公式ページは「近い場所に集まった60%は、地理的に散らばった80%が1回終えるより先に2回を終えうる」と説明しており、経路の速さはブロックの中身ではなくネットワークの遅延と配置で決まります。票が割れてどの基準にも届かないときは、安全に追加できると判定された時点で予備の票（fallback）を上乗せして決着させます。予備の票は最初の1票を置き換えるものではありません。

150msは目標値で、ブロック間隔とは別の数字

よく引用される「150ms」は、取引が確定するまでの時間の目標です。Anzaの発表では、当時のメインネットのステーク分布で模擬した中央値が約150ms、速いときは約100msで、計算の負荷は含めていません。公式ページも「定数ではなく期待値で、ステーク分布が変われば動く」と書いています。

ブロックの間隔は別の変更（SIMD-0525）で短くなりました。スロット時間の短縮ページによると、400msから4段階で下げ、最後の200msは2026年10月9日のepoch 1053から有効です。旧版の解説に多い「固定400msのブロック」は、今のメインネットには当てはまりません。

20+20の耐障害性と、その引き換え

Votorは、悪意のあるステーク20%と、応答しないステーク20%が同時にあっても合意を続けられる設計です。TowerBFTは確定にステークの3分の2超を必要とする方式でした。悪意のある参加者だけで見れば許容幅は3分の1未満から20%に下がっており、その代わりに単に落ちているノードを別枠で20%まで吸収します。SIMD-0326は、1回の投票での確定と40%のクラッシュ障害耐性を、この耐障害モデルを選ぶ利点として挙げています。公式ページは、同じスロットの2つのブロックがともに60%の承認を得るには合計120%のステークが要るため起こらない、と簡略に説明しています。正確には60%の集合どうしは少なくとも20%重なるので、二重の確定を防いでいるのは、正しく動くバリデーターが1スロットで1つのブロックにしか承認票を出さないことと、前述の耐障害の前提の組み合わせです。

Proof of History廃止で変わったこと

Proof of Historyは、SHA-256（エスエイチエー256）のハッシュを連続して計算し、その回数で時間の経過を示す仕組みでした。Alpenglowでは、PoHがブロック生成のペースを決めることはなくなり、各バリデーターは自分の時計でスロットの時間を測り、時間内にブロックが届かなければスキップ票を投じます。

影響が出るのは、PoHの刻み（tick）を時刻代わりに使っていた処理です。tickのエントリはデータの流れから消え、プログラムから読むClock.unix_timestampは、投票のタイムスタンプのステーク加重中央値ではなく、リーダーが「親ブロックの時刻から、経過スロット時間の2倍まで」の範囲で設定する値になりました。読み出しのコードは変えなくてよいものの、この値の精度に頼った判定がある場合は見直しが必要です。

Rotorは未導入｜ブロック伝播はTurbineのまま

Alpenglowは2段階で導入されます。第1段階のVotorはAgave 4.3で入り、epoch 1064から動いています。第2段階のRotorは、ブロックのデータを配る仕組みをTurbineの多段の木構造から1段の中継層に変えるもので、公式ページでは「Votorが稼働したので後の段階で行う。日程は未定」とされています。白書にあったスマートサンプリングや非同期実行も、別の提案に回っています。

仕様書のSIMD-0326は、2026年10月28日にほかのSIMDをまとめて「Activated」へ更新したときも「Review」のまま残されました。その更新（#710）の記録によると、SIMD-0326は白書のFast Leader Handover（次のリーダーが親ブロックの確定を待たずに作り始める仕組み）まで含んでおり、その機能ゲートがどのクラスタでもまだ有効になっていないためです。公式ページはFast Leader HandoverをAgave 4.4からとし、1スロットに候補ブロックが2つ以上できるのは1%未満のスロットと見込んでいます。

開発者への影響｜confirmedとfinalizedの統合

取引を送ってアカウントの状態を読むだけのアプリは、移行作業がありません。影響が出るのは、ブロックや確定状態を読む・流す・数える側です。

Alpenglow導入後のコミットメントレベル

レベル	TowerBFT	Alpenglow
processed	実行済み・未確定	変更なし
confirmed	200〜400ms・楽観的	finalizedと同じ状態
finalized	約12.8秒	約150msを目標・確定後は取り消し不能

confirmedは将来のリリースで廃止される予定なので、新しいコードはfinalizedを指定します。12.8秒の確定待ちを前提に組んだタイムアウト・再試行・画面の待機表示は、短くできるか見直す対象です。processedは今も「実行されただけ」の状態なので、確定扱いにしてはいけません。スロット短縮に伴い、ブロックハッシュの有効期限も60秒から30秒に縮んでいます。署名してから送るまでに時間がかかるウォレットやバッチ処理は、期限切れに注意してください。

Geyser・gRPC配信の識別キーとbank_id

1つのスロットに複数の候補ブロック（バリデーター内部では別々の「bank」）が来る場合があります。Agave 4.3からGeyserのイベントにはbank_idが付き、Yellowstone gRPCではv16.0.0-rc10+solana.4.3.0で対応しました。スロット番号だけで束ねると、競合した2つの候補を1つのブロックとして混ぜてしまうため、(slot, bank_id)ごとに溜めて、Confirmedに達したbankだけを残します。bank_idはノードごとの連番で、別の接続の値とは一致しません。複数のRPC事業者の配信を突き合わせるときは、接続ごとにバッファーを分け、両方のbankが完成してブロックハッシュを取得できてから照合します。

Alpenglow移行状態のRPC確認

Agave v4.3で追加されたgetAgGenesisCertは、TowerBFTのままならnull、移行済みならAlpenglowの起点ブロックの証明書を返します。日付やバージョン文字列ではなく、この応答で判定するのが公式の推奨です。

curl https://api.mainnet-beta.solana.com -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getAgGenesisCert"}'

2026年11月13日に公開RPCへ送ると、"block":{"blockId":[56,223,...],"slot":459652999}とBLSの集約署名が返り、公式ページの起点スロットと一致しました。同じ時点でgetEpochInfoはepoch 1084・1エポック432,000スロットを返しています。200msのスロットなら1エポックは約24時間です。古いRPCノードはこのメソッドにMethod not found（-32601）を返すため、「まだTowerBFT」と区別して扱います。Solana CLIではsolana alpenglow-genesis-info、TypeScriptでは@solana/kit 8.3.0以降のrpc.getAgGenesisCert()で同じ情報を取れます。

投票取引の撤廃によるTPS集計の変化

投票取引がブロックから無くなったので、取引数やTPSのダッシュボードは利用が減っていなくても大きく下がって見えます。投票命令からバリデーターの参加状況を読んでいた処理は、ブロック末尾のフッターに入る証明書（Geyserのnotify_block_footer）から読む形に作り替えが必要です。Yellowstoneのフッターメッセージは、現時点では証明書を転送しません。

バリデーター運用の変更｜最低サポート版とVAT 0.8 SOL

メインネットで投票とブロック生成を続ける条件は2つです。1つ目は対応するクライアントで動かすことです。移行時はAgave系のv4.3.2（Agave・Jito-Solana・Harmonic Salsa）が指定され、FiredancerとFrankendancerはTowerBFTからの移行そのものには対応していませんでした。10月22日のSolana Changelogは、その後FiredancerがAlpenglowの合意に参加できたと報告しています。AnzaのFeature Gate Trackerでは、Alpenglowのゲート単体の最低バージョンがAgave v4.3.0・Firedancer v26.10.4（Frankendancerは「NOT SUPPORTED」）ですが、2026年11月13日に確認した各クラスタの最低サポート版はAgave v4.4.1・Firedancer v26.10.6に上がっています。今から動かすならこちらの下限に合わせます。

2つ目はVAT（Validator Admission Ticket、SIMD-0357）の支払いです。投票が取引でなくなったため投票手数料は無くなり、代わりに投票する各バリデーターから1エポックあたり0.8 SOLが投票アカウントから差し引かれ、全額バーンされます。エポックNの開始時に払った分がエポックN+1の参加料で、最初の徴収はepoch 1064の開始時でした。投票アカウントにレント免除の最低額とは別に0.8 SOL以上が無いと、次のエポックは投票もブロック生成もできず、その分の報酬を失います。アイデンティティアカウントに入れても払われません。

SIMD-0357の本文には「1エポック1.6 SOL」とあり、Anzaの運用ドキュメントの0.8 SOLと数字が違います。SIMD-0326は当初の水準を「1日あたり約0.8 SOL（1エポック1.6 SOL）」と書いており、1エポックが約2日だった400ms時代の換算です。スロットが200msになり1エポックが約24時間になったため、1日あたり約0.8 SOLという水準は同じです。投票者数はステーク上位2,000に上限があり、BLS公開鍵をオンチェーンに登録していないバリデーターは参加者から外れます。

solana vote-update-commission-collector <VOTE_ACCOUNT_ADDRESS> block-revenue <VOTE_ACCOUNT_ADDRESS> <AUTHORIZED_WITHDRAWER_KEYPAIR>

手動の入金を減らしたい場合は、上のコマンド（SIMD-0232）でブロック収益の受け取り先を投票アカウントに向けられます。ブロック収益の受取先変更は、Solana FoundationとAnzaの両資料とも、変更したエポックEから2エポック後のE+2に反映されると説明しています。報酬で足りる保証も無いため、最初の1回分は自分で入金しておきます。

Alpenglowを前提にしてよい場面・まだ待つべき場面

Solana上で完結する入金反映や決済の確認は、finalizedを待つ設計のまま待ち時間が秒未満に縮むため、すぐに恩恵を受けられます。取引所の入金のように、これまでfinalizedの12.8秒を待っていた処理は、待機時間とユーザーへの表示を短くできます。

反対に、ブリッジやオラクルはSolana側の確定が速くなっても、それだけでは速くなりません。送金全体の時間には、送信元での処理、メッセージの認証や中継、宛先での処理が含まれるためです。USDCのチェーン間移動の例はCCTPの送金時間の解説で扱っています。また、150msは確定までの目標で、取引が届いて実行されRPCから返るまでの時間を保証する数字ではありません。サービスの応答時間を約束する前に、自分の経路で測り直すべきです。ブロック伝播の改善（Rotor）はまだ入っていないので、伝播の遅延を理由にした性能の見込みは、Rotorの日程が出てから立てるのが安全です。

Solana全体の仕組みや手数料はソラナ（Solana）の解説、確定を速める別の方向として、メインチェーンの外で処理をまとめる方式はロールアップの解説が参考になります。