---
title: "Solana Alpenglow: Solana史上最大のコンセンサス改修"
description: "AlpenglowはProof of HistoryとTower BFTの両方を置き換える新しいコンセンサスアーキテクチャで、ファイナリティを12.8秒から150ミリ秒に短縮し、Solanaのブロックスペースオーバーヘッドの75%を削減する。"
---

# Solana Alpenglow: Solana史上最大のコンセンサス改修

<ImageBlock
  src="https://media.alchemy.com/solana-alpenglow-blog-header.png"
  alt="Solana Alpenglowコンセンサスアップグレード解説"
  width={1920}
  height={900}
  priority
/>

Solanaのトランザクションがファイナライズされるまでには12.8秒かかる。Alpenglow導入後は、これが150ミリ秒まで下がる。

だが速度は表面的な話にすぎない。AlpenglowはProof of HistoryとTower BFTという、Solanaのコンセンサスを立ち上げ以来定義してきた2つのシステムを取り除き、よりシンプルなアーキテクチャに置き換える。これによりオンチェーンの投票トランザクションも排除される。この投票は現在、Solanaのブロックスペースの約75%を消費している。ガバナンス投票では98.27%の賛成で可決され、現在はプライベートクラスターでのテスト段階にあり、メインネットへの導入は2026年後半が見込まれている。

## Alpenglowとは何か

Alpenglowは、Solanaのコンセンサス層を完全に置き換えるものだ。新しいアーキテクチャでは、12.8秒ではなく100〜150ミリ秒でトランザクションがファイナライズされる。バリデーターの投票をオフチェーンに移すことで、実際のユーザートランザクション用にブロックスペースの約4分の3が解放される。

[SIMD-0326](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md)として正式化されたこのアップグレードは、2つの新しいプロトコルを軸に構築されている。

- Votor: Tower BFTを置き換える新しい投票・ファイナライゼーションシステム
- Rotor: Turbineを置き換える新しいブロック伝播システム

こう考えるとわかりやすい。Tower BFTは32段階の承認プロセスのようなもので、各ブロックは複数層の確認を経て上に上がっていく。Alpenglowはこれを1〜2回の素早いラウンドに凝縮する。このアップグレードでは、Solanaの元々の暗号学的時計であるProof of Historyも廃止される。連続的なハッシュチェーンを回す代わりに、バリデーターは固定400msのブロック時間とローカルタイムアウトを使用する。

## 誰が開発しているのか

この研究はETHチューリッヒのWattenhofer教授率いる分散システム研究室から生まれた。[Agaveバリデータークライアント](/blog/preparing-for-the-agave-2-0-upgrade)の中核チームである[Anza](https://www.anza.xyz/blog/alpenglow-a-new-consensus-for-solana)が実装を主導している。Jump CryptoのFiredancerチームはマルチクライアント互換性について協力している。

## 現在の進捗状況

- **2025年5月**: ニューヨークのSolana Accelerateで発表
- **2025年9月**: ガバナンス投票が可決、賛成98.27%、全ステークの52%が参加
- **2026年前半**: プライベートクラスターでのテスト用に、Agaveのmasterブランチで利用可能に
- **2026年第3四半期**: Agave 4.1をターゲットに正式リリース
- **2026年後半**: コミュニティテストとセキュリティ監査を経て、メインネットでの有効化を見込む(2026年4月時点では本番クラスターにはまだ未導入)

## Alpenglowはどう動くのか

変更点は3つある。

### 1. Votor: ブロックがファイナライズされる仕組み

現行システム(Tower BFT)は32回の段階的な確認を必要とする。各層はロックアウト期間を追加する。

Votorはこれを1〜2ラウンドの投票に置き換える。

- **ファストパス(約100ms)**: 最初のラウンドでバリデーターの80%以上が承認すれば、ブロックは確定する。それで終わりだ。
- **スローパス(約150ms)**: 1ラウンド目で60〜80%が承認した場合、2ラウンド目が実行される。再び60%以上が承認すれば確定する。

両方のパスは同時に走る。先に完了した方が勝つ。

バリデーターは投票をオンチェーントランザクションとしてではなく、軽量なUDPメッセージとして直接お互いに送信する。Votorはこれらの投票を[BLS署名集約](https://en.wikipedia.org/wiki/BLS_digital_signature)を使ってまとめる。何千もの個別署名が1つのコンパクトな証明に圧縮される。オンチェーンに乗るのは集約された証明書(約1,000バイト)のみで、これが現在各スロットで記録されている約500KBの投票データに取って代わる。

これは大きな意味を持つ。現在、Solanaの全トランザクションの約75%はバリデーターの投票だ。Alpenglowはこれを完全に排除する。

### 2. Rotor: ブロックデータが伝播する仕組み

*注: Rotorは、Alpenglowの構想全体の一部ではあるが、中核となるVotorのコンセンサス変更とは別のSIMDとして出荷される。*

現在、Solanaは200ノードのファンアウトを持つマルチレイヤーのリレーツリーであるTurbineを使用している。ブロックデータは複数の層を経由して伝わる。伝言ゲームのようなものだと考えるとよい。

Rotorはこれをシングルホップのブロードキャストに置き換える。ブロックプロデューサーが少数のリレーノードにデータを送信し、それらのリレーが全員に一斉にプッシュする。電話網からグループ配信への転換だ。

[Alpenglowホワイトペーパー](https://www.anza.xyz/alpenglow-1-1)の数値によれば、1Gb/sの帯域幅で1,500シュレッドを送信するのに18msかかる。全ステークの80%に到達するには、約150ノードで約2msあれば十分だ。

### 3. Proof of Historyの廃止

Alpenglowは、Solanaの暗号学的時計を廃止する。代わりに、バリデーターは固定400msのブロック時間と、タイムアウト付きのローカル時計を使用する。

- タイムアウト前にブロックが到着した場合: 承認する(NotarVote)
- ブロックが届かずタイムアウトが切れた場合: スキップする(SkipVote)

このプロトコルは、時計のずれに比例して許容度を持つ。5%のずれには、5%のタイムアウト延長だけで対応できる。

## セキュリティモデルはどう変わるのか

Alpenglowは「20+20」の耐障害性フレームワークを導入する。

<EmbeddedTable
  table={{
    columns: [
      { key: "scenario", width: 200, title: "Scenario", dataType: "object" },
      { key: "traditional", width: 200, title: "Traditional BFT", dataType: "object" },
      { key: "alpenglow", width: 200, title: "Alpenglow", dataType: "object" },
    ],
    data: [
      {
        scenario: { title: "Malicious validators", tooltip: "", icon: "" },
        traditional: { title: "Up to 33%", tooltip: "", icon: "" },
        alpenglow: { title: "Up to 20%", tooltip: "", icon: "" },
        id: 0,
      },
      {
        scenario: { title: "Offline validators", tooltip: "", icon: "" },
        traditional: { title: "Up to 33%", tooltip: "", icon: "" },
        alpenglow: { title: "Up to 20%", tooltip: "", icon: "" },
        id: 1,
      },
      {
        scenario: { title: "Both at once", tooltip: "", icon: "" },
        traditional: { title: "Up to 33%", tooltip: "", icon: "" },
        alpenglow: { title: "Up to 40%", tooltip: "", icon: "" },
        id: 2,
      },
    ],
  }}
/>

なぜこれがうまくいくのか。安全性については、80% + 60% = 140% > 100%であるため、競合するフォークが両方ともクォーラムに達することはできない。活性については、ステークの20%がオフラインになってもネットワークはスローパスを通じてファイナライズを継続できる。

トレードオフとして、純粋なビザンチン耐性は33%から20%に下がる。しかし実際には、現実世界の障害は複合的だ。悪意のあるノードもあれば、単にオフラインになっているだけのノードもある。40%という組み合わせ耐性は、従来のBFTの33%よりもこのシナリオにうまく対応する。

## パフォーマンス向上の内容は

<EmbeddedTable
  table={{
    columns: [
      { key: "metric", width: 220, title: "Metric", dataType: "object" },
      { key: "current", width: 200, title: "Current Solana", dataType: "object" },
      { key: "alpenglow", width: 200, title: "With Alpenglow", dataType: "object" },
    ],
    data: [
      {
        metric: { title: "Transaction finality", tooltip: "", icon: "" },
        current: { title: "~12.8 seconds", tooltip: "", icon: "" },
        alpenglow: { title: "100–150ms", tooltip: "", icon: "" },
        id: 0,
      },
      {
        metric: { title: "Optimistic confirmation", tooltip: "", icon: "" },
        current: { title: "500–600ms", tooltip: "", icon: "" },
        alpenglow: { title: "100–150ms (deterministic)", tooltip: "", icon: "" },
        id: 1,
      },
      {
        metric: { title: "Max theoretical TPS", tooltip: "", icon: "" },
        current: { title: "~65,000", tooltip: "", icon: "" },
        alpenglow: { title: "~107,000", tooltip: "", icon: "" },
        id: 2,
      },
      {
        metric: { title: "Vote transactions (% of block space)", tooltip: "", icon: "" },
        current: { title: "~75%", tooltip: "", icon: "" },
        alpenglow: { title: "0%", tooltip: "", icon: "" },
        id: 3,
      },
      {
        metric: { title: "Validator vote cost", tooltip: "", icon: "" },
        current: { title: "~1 SOL/day", tooltip: "", icon: "" },
        alpenglow: { title: "Eliminated", tooltip: "", icon: "" },
        id: 4,
      },
      {
        metric: { title: "Min. profitable stake", tooltip: "", icon: "" },
        current: { title: "~4,850 SOL", tooltip: "", icon: "" },
        alpenglow: { title: "~450 SOL", tooltip: "", icon: "" },
        id: 5,
      },
      {
        metric: { title: "On-chain vote data per slot", tooltip: "", icon: "" },
        current: { title: "~500KB", tooltip: "", icon: "" },
        alpenglow: { title: "~1,000 bytes", tooltip: "", icon: "" },
        id: 6,
      },
    ],
  }}
/>

シミュレーション結果によれば、ステークの65%は生のネットワークレイテンシから50ms以内にファイナライズされる。片道最長で約70msのネットワークホップを想定すると、ファストパスのファイナリティは120〜150ms程度に収まる。

## バリデーターにとって何が変わるのか

経済性が変化する。

- **投票手数料が消える。** 現在はバリデーター1つあたり約1 SOL/日。Alpenglowは全ての投票をオフチェーンに移す。
- **新たなコスト: Validator Admission Ticket(VAT)。** 約0.8 SOL/日で、インフレ抑制のため全額バーンされる。
- **バリデーター数の上限: 2,000**(ステーク上位から選出)。
- **参入障壁が約90%低下する。** 最低限利益が出るステーク量が約4,850 SOLから約450 SOLになる。
- **運用コストが全体で20〜50%低下する。**
- **HSM対応。** アイデンティティキーは高頻度の投票トランザクションに署名する必要がなくなるため、ハードウェアセキュリティモジュール上に置くことができる。

## 開発者とユーザーにとって何が変わるのか

**開発者にとって**、最大の変化は速度の数字そのものではない。ファイナリティが単一のものになるという点だ。

現在、Solanaには3つのコミットメントレベルがある。`processed`、`confirmed`(約500ms、確率的)、`finalized`(約12.8秒、決定的)だ。開発者は機能ごとに選択を迫られる。ロールバックのリスクを受け入れて高速な結果をユーザーに見せるか、12.8秒待って確実性を得るかだ。取引所の入金反映、ブリッジの確認、清算エンジンはいずれも`finalized`を待つ。わずかなロールバックリスクでも許容できないからだ。それ以外はすべて`confirmed`を使い、うまくいくことを願うしかない。

Alpenglowはこれを1つのレベルに集約する。すべてのトランザクションで100〜150ms、決定的なファイナリティが得られる。コミットメントレベルのトレードオフはない。消えたトランザクションのためのリトライロジックもない。1回のチェックで完了だ。

これが新しいパターンを実現可能にする。オンチェーンのオーダーブックは、マーケットメイカーが自分のクォート状態が150msで確定すると分かっているため、より狭いスプレッドを提示できる。パーペチュアル取引所はJITオークションでのレイテンシコストを下げられるかもしれない。クロスチェーンブリッジは、Solana側のファイナリティのボトルネックを解消する。そして取引所の入金反映は、13秒の待ち時間から即時反映へと変わる。

**ユーザーにとって**、トランザクションは体感的に瞬時と言えるほど速く確認される。より大きな変化はキャパシティだ。投票トランザクションが排除されることでブロックスペースの75%が解放され、手数料の低下と高トラフィック時の混雑緩和につながる。

**[Solana上で金融機関を構築する場合](/overviews/complete-guide-to-solana-for-financial-institutions)**、決定的でサブセカンドのファイナリティは、従来の決済インフラとの差を縮める。ステーブルコインの決済、トークン化された国債の運用、国境を越えた送金は、もはや13秒のバッファを必要としない。

## この先何が来るのか

Alpenglowは、Jump CryptoがC/C++で書いた独立のバリデータークライアントである[Firedancer](https://jumpcrypto.com/firedancer/)にとっても、開発を楽にする。Firedancerは単一ノードの性能を改善するものであり、Alpenglowはノードがコンセンサスに到達する方法を再設計するものだ。プロトコルがシンプルになることで、2つ目のコードベースに再実装すべきコンセンサスの複雑さが減る。これはマルチクライアントの多様性にとって実務上の利点となる。

[SIMD-0326](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md)がカバーするのはVotorのコンセンサス変更のみだ。[Alpenglowホワイトペーパー](https://www.anza.xyz/alpenglow-1-1)に含まれる3つの要素は、今後の提案に先送りされている。

- Rotor(ブロック伝播)、別のSIMD
- Smart Sampling(帯域最適化)
- 遅延/非同期実行(Lazy/Asynchronous Execution)

メインネットに至るまでの道筋: 2026年第3四半期にAgave 4.1をリリース、第4四半期を通じてコミュニティテストとセキュリティ監査を実施、2026年後半にメインネットで有効化。

## AlchemyでSolana上に構築する

AlpenglowはSolanaを速くするが、それを土台に構築するには、やはり信頼できるインフラが必要だ。

[AlchemyのSolanaプラットフォーム](https://www.alchemy.com/solana)は、他のプロバイダーより[最大20倍高速なアーカイブデータアクセス](/blog/how-alchemy-built-the-fastest-archival-methods-on-solana)、半額でのgRPCストリーミング(6,000ブロック分の再接続リカバリー付き)、そして`getProgramAccounts`のような負荷の高いメソッド呼び出しの10倍の高速化を提供する。

- 接続断絶をなくす**スマートWebSocket**、加えて信頼性の高いトランザクションルーティングのためのステーク済み接続
- エンドユーザーの摩擦を取り除く**ガスレストランザクション対応**
- マルチリージョン展開と3〜5層の自律的フェイルオーバーによる**99.99%の信頼性**

[Solflare](https://www.alchemy.com/dapps/solflare)、Robinhood、OpenSea、Circleはすでに[AlchemyのSolanaインフラ](/blog/solana-infrastructure)上で稼働している。従量課金制の料金体系で、長期契約は不要だ。

[無料のSolana RPCエンドポイントを始める →](https://www.alchemy.com/solana)

## よくある質問

### Solana Alpenglowとは何ですか

Alpenglowは、Solanaのコンセンサス層を完全に置き換えるもので、トランザクションのファイナリティを12.8秒から100〜150ミリ秒に短縮し、オンチェーンの投票トランザクションを排除することで、ブロックスペースの約75%をユーザートランザクション向けに解放します。

### Alpenglowは、Solanaの現行アーキテクチャの何を置き換えますか

AlpenglowはProof of History、Tower BFT、そしてオンチェーンの投票トランザクションを取り除き、代わりにVotor(新しい投票システム)、Rotor(新しいブロック伝播システム)、そしてローカルタイムアウトを伴う固定400msのブロック時間に置き換えます。

### Alpenglowはいつメインネットにローンチしますか

Alpenglowは、2026年第3四半期のAgave 4.1リリースと、それに続く2026年第4四半期までのコミュニティテストおよびセキュリティ監査を経て、2026年後半にメインネットで有効化される見込みです。

### Alpenglowはどのようにしてより高速なファイナリティを実現しますか

Votorは、現行の32段階の確認プロセスを1〜2ラウンドの投票に凝縮します。ファストパスではバリデーターの80%以上の承認で約100msでファイナライズされ、スローパスでは2ラウンドにわたって60%以上の承認で約150msでファイナライズされます。

### Alpenglowはバリデーターのコストにどう影響しますか

Alpenglowは、オンチェーン投票トランザクションにかかる約1 SOL/日のコストを排除し、最低限利益が出るステーク量を約4,850 SOLから約450 SOLに引き下げます。ただし、バリデーターは新たに約0.8 SOL/日のValidator Admission Ticket手数料を支払うことになり、これはバーンされます。

### Alpenglowのセキュリティ面でのトレードオフは何ですか

Alpenglowは、悪意のあるバリデーターを最大20%、オフラインノードを最大20%(または合計で最大40%)まで許容します。これは従来のBFTの33%という上限と比較されるもので、ファストパスのファイナリティには80%のクォーラムを、スローパスのファイナリティには60%のクォーラムを使用し、競合するフォークの発生を防ぎます。

### Alpenglowは開発者向けのコミットメントレベルをどう変えますか

Alpenglowは、Solanaの3つのコミットメントレベル(processed、confirmed、finalized)を、100〜150msでの単一の決定的ファイナリティに集約し、速度とロールバックリスクのどちらかを選ぶ必要をなくします。

### Alpenglow開発の現在の状況はどうなっていますか

Alpenglowは2025年9月にガバナンスで98.27%の賛成を得て可決され、2026年前半時点でAgaveのmasterブランチ上でプライベートクラスターでのテストが可能な状態にあり、2026年4月時点では本番クラスターにはまだ導入されていません。

## 主要な参考資料

- [Alpenglow Whitepaper v1.0](https://www.anza.xyz/alpenglow-1-0) | [v1.1](https://www.anza.xyz/alpenglow-1-1)
- [SIMD-0326 Proposal (GitHub)](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md)
- [Anza Blog: Alpenglow, a new consensus for Solana](https://www.anza.xyz/blog/alpenglow-a-new-consensus-for-solana)