キーワードを入力してください

リサーチ・技術解説公開 2026-07-23更新 2026-07-24

Solana の次期アップグレード「Alpenglow」とは?ファイナリティ短縮とステーカー・運用者への影響を解説

本記事の概要

Solana の Alpenglow は、ブロックの合意形成ルールを、Votor という新しい投票プロトコルへ置き換える大型アップデートです。合意形成とは、どのブロックを正しいチェーンとして採用するかをネットワーク全体で決める処理(コンセンサスとも呼ぶ)を指します。

ここでファイナリティとは、取引が巻き戻されたり取り消されたりせず、確定したと見なせるまでの時間です。

従来は TowerBFT という合意形成プロトコルを用いており、ファイナリティは約 12.8 秒で成立していましたが、Alpenglow 以後は 150ms となります。この高速化のために、バリデータの投票のしくみそのものを作り替える必要がありました。solana-alpenglow

バリデータとは、SOL をステーク(担保として預け入れること)してブロックに投票し、報酬を得るノードです。従来このブロックへの投票はチェーン上の取引でしたが、Alpenglow では、ファイナリティ高速化のため、各バリデータの投票を結合した結果だけをチェーンに登録する方式です。simd-0326

代わりに、この仕組みに適合した署名鍵である BLS 鍵の作成・登録と、投票への参加費の支払いが必要になります。solana-bls-vat

この記事では、Alpenglow が何を変えるのかを押さえたうえで、SOL ステーカー・DeFi 等の SOL チェーンユーザー・ノード運用者のそれぞれへの影響を順に整理します。

また、Alpenglow の実装に合わせ、Vote Account v4 やブロック収益分配なども同一タイミングで実装されています(有効化タイミングは異なる可能性があります)。solana-network-upgrades

本稿では、Alpenglow 本体(合意形成)と周辺の SIMD (Solana の仕様変更提案(Solana Improvement Documents))を分けて扱います。

特に SIMD-0123 で実装される 「リーダーブロック報酬をデリゲータ(バリデータに SOL を預ける委任者)へ分配できる」機能は、委任先のバリデータ次第でステーカーの利回りが変わります。simd-0123

注: 本稿は 2026 年 7 月 24 日時点の一次情報を基にしています。Solana の feature gate(機能のオン・オフを切り替えるスイッチ)、Agave(Solana の主要なバリデータ用クライアント)のバージョン、メインネット適用時期は変わり得ます。最新の状況は、Solana Foundation、Anza、各クライアントの一次情報をご確認ください。

Alpenglow と関連 SIMD の全体像

Alpenglow では中核になる SIMD-0326 が新しいネットワークにおける合意形成ルールを定め、関連する SIMD によってアップデート前後の移行、移行後のバリデータの署名鍵であるBLS 鍵、移行後のバリデータの支払う手数料、ブロック生成時の情報が定められます。solana-alpenglow simd-0326

まず、Alpenglow本体 というべき主要な SIMD は次の 5 本です。

  • SIMD-0326: Votor(新たな合意形成ルール)、合意形成に伴うバリデータ間の投票メッセージ、ネットワークの合意形成のプロセスを定める。従来、投票はオンチェーンのTXだったが、全バリデータの結果が結合されチェーンに記録され、ファイナリティの実現までの流れが変わる。
  • SIMD-0337: 高速なファイナリティ実現・ブロック処理の効率化のため、ブロックに情報を追加する(Fast Leader Handover 用の BlockHeader / UpdateParent marker を追加)。ブロック生成時に、親ブロック情報の扱いが変わる。
  • SIMD-0357: バリデータの支払う手数料(Validator Admission Ticket(VAT))を定める。BLS 鍵、vote account 残高、2,000 validator 上限等のバリデータの参加条件を規定する。
  • SIMD-0384: TowerBFT から Alpenglow への移行手順を定める。移行する瞬間のスロットの指定を行う。
  • SIMD-0387: BLS 鍵を vote account に登録する手順を定める。VAT 有効化前に BLS 鍵登録を済ませる必要がある。

これに加えて、vote account と収益の扱いを変える同一タイミングで実装される次の SIMD があります。solana-network-upgrades

  • SIMD-0185: Vote Account v4を定める。BLS 鍵、collector account、手数料率、未払いの委任者への報酬といった情報を vote account に持たせる。
  • SIMD-0232 / SIMD-0291 / SIMD-0464: collector account の指定、basis points 料率、新規 vote account でのまとめ設定。
  • SIMD-0123: ブロック報酬をバリデータが指定した手数料の控除後に委任者へ分配できるようにする。
  • SIMD-0286 / SIMD-0296 / SIMD-0268: TXの上限緩和(100M CUへの上限変更、larger transaction、CPI nesting 上限)。主に開発者のUX改善。

SIMD-0123 によるブロック報酬の委任者への分配や、vote account の仕様変更が、バリデータの運用・収益に関わる部分です。simd-0185 simd-0123

現行 Solana、Alpenglow 本体、周辺の収益・会計 SIMD を 3 列で比べる図。現行 Solana は TowerBFT、vote transactions、ed25519、identity account に集まる block revenue を示す。Alpenglow 本体は Votor、バリデータ間の直接メッセージ、BLS、VAT、admitted set を示す。周辺の収益・会計 SIMD は Vote Account v4、collector account、basis-points commission、block revenue sharing を示し、SIMD-0123 は Alpenglow 本体ではなく周辺 SIMD として扱うことを明示する。

バリデータの合意形成はどう変わるのか

Alpenglow で最も大きな変化は、バリデータが「ブロックにどう投票し、どうファイナリティに達するか」というネットワークの合意形成ルールです。VATと呼ばれるバリデータの支払う手数料やBLS 鍵の導入も、この結果です。まずは現在の仕組みを理解しましょう。

今の Solana:投票を「取引」としてチェーンに書き込む(TowerBFT)

現在の Solana は、Proof of History(PoH)と TowerBFT という 2 つの仕組みで合意形成しています。PoH はブロックの順序と時刻を暗号的に刻む仕組みです。TowerBFT は、どのブロックを承認するかをバリデータの投票で決める仕組みです。simd-0326

今の投票は、投票トランザクション(vote transaction)としてブロックに書き込まれます。投票そのものがトランザクションなので、投票のたびに手数料がかかり、ブロックの領域も消費します。solana-alpenglow

この方式では、ファイナリティに約 12.8 秒かかります。取引の想定される実行結果を先に返す pre-confirmation でも、約 400ms を要します。Alpenglow が短縮を狙うのは、この時間です。solana-alpenglow

Alpenglow:投票をバリデータ間のメッセージに変える(Votor)

Votor は、投票をチェーン上の取引からバリデータ間のメッセージへ移す新しい投票プロトコルです。投票はブロックに書き込まれず、バリデータ同士が直接やり取りします。simd-0326

個々の投票は、certificate(証明書)という形にまとめられます。certificate は、一定割合の stake を保有するバリデータ群が同一の投票をしたことを示す集約署名です。stake とは、そのバリデータに割り当てられた SOL の量を指します。simd-0326

この集約には BLS 署名を使います。BLS は多数の署名を 1 つにまとめられる署名方式で、現在の ed25519 署名はこの集約に向きません。そのため、バリデータは BLS 用の鍵を新たに登録します。simd-0387

Votor では、バリデータは投票の意味ごとにメッセージを使い分けます。主なものは notarize(そのブロックを正しいと承認する)、skip(そのスロット=ブロックを作る時間枠を飛ばす)、finalize(ファイナリティを確定させる)の 3 つです。simd-0326

バリデータ間の通信が届かないときには、 fallback が用意されています。1 ラウンド目は notarize か skip で、届かなければ 2 ラウンド目の finalize へ進む流れです。どちらの経路になるかは、集まった投票のstakeのネットワーク全体に対する割合で決まります。simd-0326

80% で 1回で確定、届かなければ 60% で 2回で確定(fast path / slow path)

Alpenglow のファイナリティには、80%のstakeが集まった際の fast path と、届かなかったとき、2回目の投票で60%のstakeが集まった際の slow path という 2 つがあります。どちらに進むかは、集めた投票の stake 割合で決まります。simd-0326

fast path では、stake の 80% 以上が notarize に投票すると、1 ラウンドでファイナリティに達します。この経路なら、約 150ms でファイナリティが成立します。solana-alpenglow

80% に届かない場合は、2 ラウンド目に入ります。slow path では、stake の 60% を閾値に、ファイナリティか skip かを決めます。2 段階でも、現在の 12.8 秒より大幅に短い水準です。simd-0326

Alpenglow のファイナリティ 2 経路を示す分岐図。集めた notarize 投票の stake 割合が起点となり、stake の 80% 以上が notarize に投票すれば fast path に進み、1 ラウンドでファイナリティに達して約 150ms を狙う。80% に届かなければ slow path に進み、2 ラウンド目に入って stake の 60% を閾値にファイナリティか skip かを決める。slow path の 2 段階でも現在の約 12.8 秒より大幅に短い水準であることを示す。

ブロックデータの配布方法も変わる:Turbine から Rotor へ

Alpenglow が変えるのは、投票のしくみ(Votor)だけではなく、ブロックデータのネットワークへの配布方法も、あわせて見直されます。solana-alpenglow

現在の Solana は、Turbine という方式でブロックを配信します。ブロックを作ったバリデータ(リーダー)が全ノードへ直接配るのではなく、まず一部のノードへ送り、受け取ったノードがさらに次のノードへ中継する仕組みです。連絡網のように多段の中継を経るため、段が増えるほど全体へ伝わるまでの時間もかさみます。simd-0326

Alpenglow では段階的に構成変更が行われ、第一段階では投票プロトコル(Votor)のみが変わり、ブロック配信は Turbine のままになります。solana-alpenglow

Turbine を置き換える Rotor は、Alpenglow 本体とは別の SIMD として、第二段階であとから導入される予定です。simd-0326

Rotor では、リーダーがブロックを小さな断片に分け、各断片を 1 つの中継ノードへ渡し、その中継ノードが担当の断片を全バリデータへ一斉に配ります。中継を多段から 1 段に減らすことで、ブロックが行き渡るまでの遅延を抑えます。simd-0326

現行 Turbine と第二段階の Rotor で、ブロックデータの配り方を比較した図。左の Turbine は、リーダーが一部のノードへ送り、そのノードが次の層へ多段で中継してすべてのバリデータへ届ける。段が増えるほど全体に伝わるまでの遅延が積み上がる。右の Rotor は、リーダーがブロックを小さな断片に分け、各断片を 1 つの中継ノードへ渡し、その中継ノードが担当の断片を全バリデータへ一斉に配る。中継が 1 段になるため、ブロックが行き渡るまでの遅延が小さくなる。

つまり、ここで変わるのは 3 点です。投票が取引からメッセージへ、署名が ed25519 から BLS へ、ファイナリティが約 12.8 秒から約 150ms へと動きます。ここから、この変化がステーカー・ユーザー・運用者にどう効くのかを見ていきます。

現行 Solana と Alpenglow の合意形成を左右で対比した比較図。合意形成の仕組みは現行が Proof of History(PoH)と TowerBFT、Alpenglow が新しい投票プロトコル Votor。投票の形は現行が投票トランザクションとしてブロックに書き込む方式(手数料がかかりブロック領域を消費)、Alpenglow がバリデータ間の直接メッセージ(ブロックに書き込まない)。署名は現行が集約に向かない ed25519、Alpenglow が多数の署名を 1 つにまとめる BLS 署名で certificate に集約。ファイナリティは現行が約 12.8 秒(pre-confirmation でも約 400ms)、Alpenglow が約 150ms を狙う目標であることを示す。

ステーカーにとって何が変わるか

ステーカーが受け取る報酬は、これまで基本的にインフレ報酬(新規発行される SOL)だけでした。SIMD-0123 が有効化され、バリデータが手数料率を設定すれば、ブロック生成で得た収益が手数料を差し引いた後に委任者へ分配されます。Alpenglow 自体ではなく SIMD-0123 が、委任するバリデータ次第で利回りを変えます。simd-0123

預け先の選び方も変わります。Alpenglow では投票に参加できるバリデータに 2,000 の上限が置かれ、参加には VAT(入場料)と BLS 鍵の登録が前提になります。この手数料を支払う収益性を持たない小さなバリデータもあり、バリデータのリストは変動する可能性があります。simd-0357

DeFi ユーザーにとって何が変わるか

体感として、ファイナリティが約 12.8 秒から約 150ms へ縮むと、ウォレットで取引を送信した後、取引が確定するまでの待ち時間が短くなります。スワップや清算の結果が早く確定し、価格がずれるリスクや、取り消しに備える待機時間は小さくなります。

ただし、150ms はあくまでファイナリティの目標です。ウォレット表示、取引所やブリッジの入金確認、indexer(チェーンのデータを整理して提供する仕組み)の反映まで、すべてが 150ms になるわけではありません。体感の改善は、こうした周辺システムの対応も前提になります。solana-alpenglow

ノード運用者にとっての変更点

1. 投票コストは消えるのではなく、形が変わる

投票の費用は、トランザクション手数料から epoch ごとの VAT(Validator Admission Ticket、投票への入場料)へ移ります。epoch とは報酬計算などの区切りで、Solana ではおおむね 2 日前後です。solana-bls-vat

Alpenglow 後は投票がオンチェーンに載らず、代わりに登録されたバリデータに紐づく vote account から epoch ごとに VAT が差し引かれます(SIMD-0357)。simd-0357

「投票費用がゼロになる」わけではなく、従来約 2 SOL であった投票費用が、VAT としてエポックごとに 1.6 SOL へ変わる形です。solana-bls-vat

差し引き元が vote account になるため、identity account だけでなく vote account の残高管理が重要になります。simd-0357

2. BLS pubkey 登録が参加条件になる

Alpenglow は多数の投票を 1 つの certificate に集約するため、現在の ed25519 署名とは別に BLS pubkey(BLS の公開鍵)が必要です。simd-0387

登録手順は SIMD-0387 が定めます。登録時には proof of possession(その鍵を実際に持っている証明)を添えて、他人の鍵で集約署名を偽造する rogue-key attack を防ぎます。simd-0387

VAT が有効になると、BLS pubkey のないバリデータは合意形成に参加できず、SOLのインフレ報酬も得られません。BLS 鍵の未登録は、そのまま収益ゼロに直結します。solana-bls-vat

ただし、BLS/VAT の有効化と Alpenglow 本体の有効化は別物です。VAT はバリデータの出入りを制御する feature gate(機能のオン・オフを切り替えるスイッチ)です。solana-bls-vat

合意形成そのものの切り替えは、Agave 4.3 で実装され、別のタイミングで有効になります。BLS/VAT 対応は、その事前準備にあたります。solana-bls-vat

3. validator set には 2,000 の上限が置かれる

投票に参加できるバリデータは、最大 2,000 に制限されます(SIMD-0326・SIMD-0357)。BLS pubkey を持ち必要残高を満たす vote account を stake の多い順に並べ、2,000 を超える分は上位から選ぶ設計です。simd-0326 simd-0357

投票しない RPC ノード(アプリからの照会などに応答する接続用ノード)は対象外で、影響を受けるのは投票報酬やブロック収益を得る voting validator です。stake が小さい運用者は、正しく動かすだけでは足りず、上位 2,000 に入る stake 量を保てるかが収益の前提になります。

収益・会計まわりの変更(Vote Account v4 と SIMD-0123)

Vote Account v4(SIMD-0185)は、Alpenglow とブロック収益分配に共通する土台です。simd-0185

vote account に、インフレ報酬とブロック報酬のそれぞれの手数料率、受け取りアカウント、未払い委任者報酬、BLS鍵の情報を持たせ、収益源ごとに手数料や送り先などの扱いを分けられるようにします。simd-0185

従来、ブロック報酬は選択の余地なく identity account に送金されていました。identity account はノード間通信の署名に使うため、バリデータのサーバーに秘密鍵を置くホットウォレット(オンラインで頻繁に使う鍵)に近いものです。simd-0185

収益の受け口をこのホットウォレットから切り離せることが、Vote Account v4 の実務的な意味です。simd-0185

あわせて、各種報酬の受け取りアカウント(collector account)(SIMD-0232)や、手数料率を細かく扱う basis points 設定(SIMD-0291)も含まれます。simd-0232 simd-0291

SIMD-0123:ブロック収益分配

「リーダーブロック報酬を委任者に分配する機能」は、Alpenglow 本体ではなく SIMD-0123 の範囲です。Vote Account v4 を土台にしますが、有効化は別の feature gateとなります。simd-0123 simd-0185

現在の委任者は、インフレ報酬だけを受け取ります。バリデータがブロック生成で得るトランザクション手数料等(ブロック報酬)は、これまで委任者に配布されませんでした。solana-network-upgrades

SIMD-0123 は、このブロック報酬を手数料控除後に委任者へ自動分配できるようにする提案です。simd-0123

分配の有無と割合は、バリデータが設定するブロック報酬の手数料率で決まります。初期値は 100%(=従来どおりバリデータが全て取得)で、委任者がブロック報酬を受け取るのは、100%より低い手数料率を設定した場合のみです。simd-0123

ブロック収益分配の資金フロー図。起点はブロック収益(block revenue)で、ブロック処理後に runtime がブロックを作ったバリデータの vote account を参照する。vote account に commission rate と collector account が設定されていれば、プロトコルは commission と委任者分を分けて処理する。commission は block revenue に commission rate を掛けて計算され、collector account が vote account 自身、または条件を満たす custom collector であればそこへ入り、それ以外なら burned(焼却)されて誰の手にも渡らない。commission を差し引いた残りは vote account の pending_delegator_rewards に入り、次の epoch の開始時に active stake の比率に応じて各 stake account(委任者)へ分配される流れを矢印で示す。

分配は次のように処理されます。ブロックの提案後、runtime(取引を実行するプログラム)が vote account から 手数料率・受け取りアカウントを取得し、バリデータの取得する手数料・委任者分の報酬を分離します。simd-0123

手数料は collector account(vote account 自身か、条件を満たす custom collector)へ入りますが、どちらでもない設定だとバーン(焼却)され、誰の手にも渡りません。simd-0123 simd-0232

委任者分の報酬は pending_delegator_rewards として加算され、次の epoch 開始時に、ステーク量の比率で各アカウントへ配られます。simd-0123

まとめ

Alpenglow の中心は、ファイナリティを約 12.8 秒から約 150ms の目標へ縮める合意形成ルールの変更です。投票は取引からメッセージへ、署名は ed25519 から BLS へと移ります。solana-alpenglow simd-0326

ステーカーや DeFi ユーザーがまず感じるのは、確定までの待ちが短くなり、決済やスワップの体感が変わることです。

利回りを動かすのは Alpenglow 本体ではなく SIMD-0123(ブロック収益分配)で、バリデータ次第でこれまでより利回りが上がる場合があります。VAT や 2,000 上限は、バリデータリストの変動にかかわります。simd-0123 simd-0357

運用者にとっては、BLS pubkey、VAT、vote account 残高、2,000 上限が参加と収益の前提です。あわせて、Vote Account v4、各報酬の手数料率、受け取りアカウント、ブロック報酬の分配も検討が必要です。simd-0185 simd-0232 simd-0123

Omakase は、ステーキングの運用代行事業者(SSP, Staking Service Provider)として、Alpenglow のような Solana の大規模なアップデート、BLS 鍵・VAT 対応、ブロック収益分配まわりの運用変更を継続的に追っています。

参考リンク

本稿は、以下の参考資料を基に作成しています。詳しく知りたい方はこちらをご確認ください(参照日:2026 年 7 月 24 日)。

  • Solana「Alpenglow」(コンセンサスの概要とファイナリティ目標)solana-alpenglow
  • Solana「BLS Pubkey & Validator Admission Ticket」solana-bls-vat
  • Solana「Solana Network Upgrades」solana-network-upgrades
  • Solana Improvement Documents「SIMD-0123: Block Revenue Distribution」simd-0123
  • Solana Improvement Documents「SIMD-0185: Vote Account v4」simd-0185
  • Solana Improvement Documents「SIMD-0232: Custom Commission Collector」simd-0232
  • Solana Improvement Documents「SIMD-0268: Raise CPI Nesting Limit」simd-0268
  • Solana Improvement Documents「SIMD-0286: Raise Block Limits to 100M CUs」simd-0286
  • Solana Improvement Documents「SIMD-0291: Commission Rate in Basis Points」simd-0291
  • Solana Improvement Documents「SIMD-0296: Larger Transaction Size」simd-0296
  • Solana Improvement Documents「SIMD-0326: Alpenglow」simd-0326
  • Solana Improvement Documents「SIMD-0337: Markers for Alpenglow Fast Leader Handover」simd-0337
  • Solana Improvement Documents「SIMD-0357: Alpenglow Validator Admission Ticket」simd-0357
  • Solana Improvement Documents「SIMD-0384: Alpenglow Migration」simd-0384
  • Solana Improvement Documents「SIMD-0387: BLS Pubkey Management in Vote Account」simd-0387
  • Solana Improvement Documents「SIMD-0464: Vote Account Initialize V2」simd-0464

あわせて確認したいページ

FAQで確認したい論点

比較検討や社内説明で出やすい疑問を、一次説明に戻れる形で確認できます。

次の一手

次に読みたいページ

Solana の SGP-0002・SGP-0003 とは?インフレ抑制と手数料バーンがバリデータ経済に与える影響を解説

SolanaのDoubleZeroとは?バリデータ向け専用ネットワーク層の仕組み

SolanaのMEVとは?Jito・bundle・Tip Distributionの仕組み