Alpenglow：Solanaのコンセンサスを根本から刷新

実践的なポイント 

• AlpenglowがSolanaにもたらす最大のメリットは、トランザクションのファイナリティ到達時間を100分の1に短縮することです。バリデータの地理的位置に応じて、12.8秒から100〜150msに短縮されます。これにより、Solanaはより中央集権的なWeb2インフラと競争できるようになり、リアルタイムアプリケーションも実現できます。
• Alpenglowは、Proof of History、Tower BFT、ゴシップベースの投票伝播など、Solanaの複数のレガシーコンポーネントを廃止し、コンセンサスを簡素化します。Proof of Historyの代わりに、Alpenglowは400msの固定ブロック時間を導入し、ネットワーク全体のタイミングを調整します。これは、グローバルに同期されたクロックを持つことと同じではありません。
• このプロトコルは、2つの基盤コンポーネントを中心に構成されています。Rotorは、Solanaの既存のTurbineアーキテクチャを拡張・改良したブロック伝播プロトコルです。Votorは、Tower BFT、Proof of History、投票伝播におけるゴシップの使用を置き換える新しい投票メカニズムです。
• すべてのコンセンサス処理がオフチェーンに移行します。投票証明書は引き続きオンチェーンに記録されますが、スロットごとの投票トランザクションは軽量なBLS証明書システムに置き換えられます。この変更により、現在のような投票手数料がなくなります。投票手数料は歴史的にバリデータの主要な運用コストだったため、小規模オペレーターのバリデータ経済性が大幅に改善されます。正確な経済モデルは現在も策定中です。
• Alpenglowは「20+20」の耐障害モデルを提供します。最大20%のステークが攻撃者に支配されても安全性を維持し、それとは別の20%のステークがオフラインまたは応答不能でもライブネスを維持します。これにより、敵対的なネットワーク状況と不安定なネットワーク状況の両方に耐えられます。
• Votorは、2段階の並行投票システムをコンセンサスに使用します。高速ファイナリティ経路では、ブロックが第1ラウンドで80%以上のステーク承認を得ると、高速ファイナリティ証明書によって直ちにファイナライズされます。S低速ファイナリティ経路では、ブロックが60%以上のステーク承認を得た時点で第2ラウンドが始まります。このラウンドでも60%以上の承認に達すると、ブロックはファイナライズ済み証明書によってファイナライズされます。
• ファンアウト200の多層ツリー構造に依存するTurbineとは異なり、Rotorはリレーノードがシュレッドの配布を担うシングルホップモデルを採用します。各シュレッドは、消失訂正符号化された単一パケットとして送信されます。また、Rotorの設計はDoubleZeroなどのマルチキャストシステムとネイティブに互換性があります。Rotorは、Votorとは別のSIMDになる可能性が高い点に注意してください。
• 現時点では、Alpenglowは来年初頭までにSolanaメインネットへ導入される見込みです。プロトコルのリファレンス実装はGithubで確認できます。

はじめに

Alpenglowコンセンサスアルゴリズムは、これまでで最も大規模なSolanaコアプロトコルの刷新です。ブロックチェーン研究の最新成果を取り入れ、ネットワーク全体でコンセンサスを形成する方法を根本から再設計します。

Alpenglowは、世界有数のコンピューターサイエンス研究機関であるETH ZurichのRoger Wattenhofer教授が率いる、Anzaの新しい研究部門による成果です。分散システムの第一人者であるWattenhofer教授は、Solanaの現行コンセンサスプロトコルに存在し得るライブネスの脆弱性を明らかにした2024年の論文「Halting the Solana Blockchain with Epsilon Stake」を共同執筆しています。Anzaでは、かつての博士課程の教え子であるKobi Sliwinski氏とQuentin Kniep氏もWattenhofer教授のチームに加わっています。

チームの任務は、Turbineベースのアーキテクチャを維持しながら、Solanaのコンセンサスアルゴリズムをより高性能かつ正しさを証明可能なものへ再設計することでした。Alpenglowには、特に敵対的なネットワーク挙動への対応を中心に、分散システム研究の最新成果が数多く取り入れられています。

Alpenglowという名前は、「アルプスの輝き」を意味するドイツ語のAlpenglühenに由来します。日の出や日没時に山頂で見られる印象的な光を指し、このプロトコルがスイスで生まれたことにも敬意を表しています。

Alpenglowにはどのようなメリットがありますか？

以下は、Alpenglowがもたらすと期待される主なメリットの概要です。各項目については、この記事の残りの部分で詳しく説明します。

より高速なファイナリティ

AlpenglowがSolanaにもたらす最大のメリットは、トランザクションがブロックチェーンネットワーク上でルート化されるまでの時間、つまりトランザクションのファイナリティ到達時間を100分の1に短縮することです。バリデータの地理的位置に応じて、12.8秒から100〜150msに短縮されます。これにより、Solanaはより中央集権的なWeb2インフラと競争できるようになり、リアルタイムアプリケーションも実現できます。

• 現在のSolanaのファイナリティ： 12.8秒 
• 現在のSolanaの楽観的確認： 500〜600ミリ秒
• Alpenglowのファイナリティ： 150ミリ秒（中央値）*
• 競合で最速のファイナリティ： 400ミリ秒（自己申告）

*地理的位置とクラスター分布によって変動します。

投票トランザクションの廃止

Alpenglowでは、すべてのコンセンサス処理がオフチェーンで行われます。これにより、トランザクション処理ユニット（TPU）とリプレイの負荷が軽減され、投票トランザクションを処理する必要がなくなります。

Alpenglowは、小規模バリデータの経済性も大幅に改善します。投票トランザクション手数料は、バリデータにとって最大の運用費用です。オフチェーン投票によってこの手数料をなくすことで、参加コストが劇的に低下します。小規模なバリデータも運用しやすくなり、ネットワークセキュリティへの貢献を始める際の障壁も下がります。

投票トランザクションがブロックスペースを消費せず、台帳サイズを膨張させなくなるため、コミットメントロジックの簡素化や台帳の増加ペースの低下といった利点もあります。

この移行には、Solanaの秒間トランザクション数（TPS）指標の曖昧さを解消するという追加のメリットもあります。現在、TPSは投票トランザクションを含む総TPSと、投票以外のトランザクションのみを数える実TPSという2つの方法で報告されることがよくあります。

より合理化されたプロトコル

Alpenglowは、Proof of History、Tower BFT、投票伝播におけるゴシップの使用など、Solanaの複数のレガシーコンポーネントを廃止し、コンセンサス形成プロセスを合理化します。現代のブロックチェーン研究における最先端の進歩を取り入れながら、不要な複雑さは導入しません。

AlpenglowのVotorとRotorは、非同期実行や複数の並行リーダー（MCL）など、将来のアップグレードの基盤となります。これにより、Solanaはさらなる性能向上とプロトコル進化に向けて有利な位置に立てます。

Solanaの現在のコンセンサスメカニズムとは？

Proof of History

Proof of History（PoH）は、コンセンサスアルゴリズムではありません。正確には、コンセンサス形成を補助するツールです。混同が生じるのは、おそらくその命名に理由があります。「Proof of X」という名称は、Proof of WorkやProof of Stakeを知る人にとって、その対象がコンセンサスアルゴリズムであることを示唆するためです。PoHは、効率的なトランザクション処理によってコンセンサスを合理化する「プレコンセンサス」アルゴリズムと考える方が適切です。

大まかに言えば、PoHは敵対的なネットワーク内で時刻を証明するための分散型クロックです。より厳密には、PoHはノード同士が通信せずにイベントの順序について合意できるようにする暗号学的タイムスタンプ関数です。逐次的な原像計算困難性を持つハッシュ関数を使用して、ハッシュチェーンを作成します。リーダーはこれらのハッシュを使ってブロックにタイムスタンプを付け、一定時間が経過したことを証明します。すべてのハッシュが連結されているため、PoHは特定の時点でデータが存在したことを証明する履歴記録を提供します。 

このアプローチは、コンセンサス形成中にブロックの順序を決め、その後でタイムスタンプを追加することが多い他のチェーンとは異なります。Solanaでは、まず暗号学的に検証可能なクロックを構築し、そのクロックに沿ってトランザクションをストリーミングし、コンセンサスによって事前に順序付けされたトランザクションログを検証します。ハッシュの連結により、時間順序に異議を差し挟む余地がなくなります。 

Tower BFT

Tower BFTは、シュレッド（部分的なブロック）が他のバリデータに伝播され、ネットワークがそれらをリプレイして、そのブロックを台帳の一部にするかどうかを判断する段階で動作します。概念的にはpBFTに似たコンセンサスアルゴリズムで、Proof of Historyのネットワーク全体のクロックを活用するように設計されています。各スロットで同期的なコンセンサスラウンドを行う代わりに、バリデータはすでに観測したProof of Historyシーケンスに基づいて将来のスロットへ事前コミットし、継続的なブロック生成を可能にします。

バリデータは、投票アカウントで署名した投票トランザクションをスロットごとに1つ送信します。特定のフォークへの投票には、そのフォークに対するロックアウト（タイムアウト）が発生します。ロックアウトとは、バリデータが別のフォークに投票できない、指定されたスロット期間です。これは、バリデータを1つのフォークにコミットさせ、フォークを切り替える場合にはロックアウトを指数関数的に延長するための仕組みです。各投票にはロックアウトカウンターがあり、バリデータが子孫スロットに投票するたびに倍増し、コミットメントの「投票タワー」を形成します。したがって、バリデータがブロックXに投票すると、競合するフォークには、将来のスロット数が指数関数的に増える期間（例：1、2、4、8…）にわたって投票できなくなります。ロックアウト違反は証明でき、処罰の対象になりますが、スラッシングはまだメインネットに導入されていません。

SolanaはTower BFTの下で、楽観的確認と決定論的ファイナリティという2段階のファイナリティを実現します。 

新しいブロックが生成され、66%以上のステークが投票すると、そのブロックは先頭、つまり正規フォークの一部として認識されます。これは楽観的確認と呼ばれます。圧倒的多数が投票した時点で、ブロックに「confirmed」というコミットメントレベルが付与されるためです。楽観的確認は、正式にファイナライズされる前にブロックをファイナライズ済みとして扱い、UXを改善するため、Solana Labs（現在のAgave）クライアントのv1.3で導入されました。

Solanaのジェネシスブロック以降、楽観的確認済みのブロックがロールバックされたことは一度もありません。 ロールバックするには、66%がすでに誠実に投票した後で、総ステークの少なくとも3分の1が競合フォークを明らかにする必要があります。別の言い方をすると、ブロックの楽観的確認数がステークの~87%に達した時点で、攻撃者はその同じステークの20%以上を使って二重署名する必要があります。これは、スラッシング可能であることを証明できる行為です。厳密なコンセンサス理論上の意味で絶対的なファイナリティではありませんが、楽観的確認は実用上、強力な保証を提供します。ほぼすべてのユースケースで、これらのブロックをファイナライズ済みとして扱えます。そのため、実用上のSolanaのファイナリティは一般に500〜600ミリ秒とされています。

真の決定論的ファイナリティを得るには、ブロックが投票タワーで最大ロックアウトに達する必要があります。これは、そのブロックを確認する32個の投票が積み重なることを意味します。つまり、ブロックが「ファイナライズ済み」、またはネットワークにルート化されたと見なされるには、その上にさらに32個のブロックが構築される必要があります。32スロットという要件と~0.4秒のスロット時間から、ブロックが決定論的ファイナリティに達するまでの時間は~12.8秒です。ロックアウト投票の深さによってロールバックが不可能になると、決定論的ファイナリティが成立します。

Solanaの現在のコンセンサスメカニズムにはどのような制約がありますか？

Proof of HistoryとTower BFTにより、Solanaは高いスループットと高速な楽観的確認を実現しました。しかし、この設計にはコスト、レイテンシ、ライブネス、バリデータ運用に関する複数の制約があります。

投票の大きなオーバーヘッドとコスト

すべてのバリデータは、コンセンサスに貢献するため、各スロットで継続的に投票しなければなりません。投票は、投票プログラムとやり取りし、ネットワークリソースを消費し、手数料を支払うトランザクションです。 

Solana上のトランザクションの約4分の3は投票トランザクションです。これらはネットワークに大きなオーバーヘッドを生じさせる一方で、各スロットにおいてバリデータに実コストを負わせます。絶え間ない投票への不要な依存により、処理するスロット数とクラスター内のバリデータ数に比例して増加する大きなオーバーヘッドとコストが発生します。 

ファイナリティのレイテンシ

楽観的確認は高速ですが、決定論的ファイナリティはそうではありません。~12.8秒という時間は、ファイナリティ到達時間~500msを誇るSuiのMysticetiなど、新しいコンセンサスプロトコルと比べると低速です。これは、取引所など、運用に絶対的な確実性を必要とするアプリケーションに問題をもたらします。実際には、ユーザーは確認済みブロックを信頼しています。しかし、ファイナライズ前に小規模な再編成が発生する可能性に備え、ネットワークは依然として長いフォーク履歴を維持する必要があります。 

楽観的確認と決定論的ファイナリティのレイテンシの差は、トレードオフの結果です。Tower BFTは、ファイナリティが遅くなる代わりに、短いフォーク発生可能期間を設けてライブネスを優先します。攻撃やコンセンサスのバグが一切なくても、~12.8秒のファイナリティは、高速ファイナリティチェーンや既存のWeb2インフラと比べて見劣りします。

ライブネスとネットワーク分断への耐性

Tower BFTで新しいブロックを確認し、ファイナライズするには、圧倒的多数のバリデータがオンラインで応答可能である必要があります。ステークの3分の1を超える部分がオフラインになるか、ネットワークが深刻に分断されると、コンセンサスが停止する可能性があります。Solanaはライブネスを優先してブロック生成を続ける可能性がありますが、ネットワークがそれらのブロックを楽観的に確認するための投票しきい値に達しないことがあります。最悪の場合、Solanaで最近発生した停止のように、バリデータが投票待ちのまま動けなくなったり、楽観的フォークを処理できなくなったりすると、協調的な再起動が必要なネットワーク停止につながる可能性があります。

これは、BFTコンセンサスにおける古典的な制約です。Solanaには、多数のバリデータが一時的に応答しなくなる状況を許容する仕組みが組み込まれていません。そのため、極端な状況では、コンセンサスに必要な圧倒的多数のしきい値を下回った場合にプロトコルが適切に対処できず、Solanaのライブネスが損なわれました。Tower BFTは、オンラインのステークが60%未満でもブロックを生成し続ける必要がありました。つまり、それらのブロックは楽観的確認に到達できず、ロールバックされる可能性があります。

バリデータ運用の複雑さ

Tower BFTは、バリデータに多くを要求します。継続的な投票トランザクション、堅牢なネットワーク、クライアントのアップグレード、稼働不良の回避、「タワー状態」の永続化が必要です。バリデータが再起動したり、最新のタワー状態を失ったりすると、以前のロックアウトコミットメントに違反する投票を行い、投票クレジットを失うリスクがあります。

このプロトコルは、Proof of Historyの継続的なハッシュ処理と投票のゴシップ伝播に依存しています。そのため、バリデータはSolanaの~400msというスロット時間に追従するために多大な処理を行います。Solanaのハードウェア要件は時間とともに低下しているものの、依然として無視できません。さらに、ステーク量に関係なく、報酬を最大化するためにすべてのバリデータが各スロットで投票する必要があります。つまり、小規模なバリデータも、大規模なバリデータとほぼ同じ手数料を支払い、同じ作業負荷を負います。リーダースロットはステークに比例して割り当てられるため、ステークが多いバリデータほど多くのブロックを生成し、他のバリデータが支払う投票手数料をより多く受け取ります。その結果、投票手数料を通じて、実質的にステーク量の多いバリデータへ資本が再分配される循環的な価値フローが生じます。

さらに、Solanaの現在のコンセンサスメカニズムでは、クライアントが同じスロットの複数の候補を管理する必要があるため、重複ブロックのリプレイが極めて複雑になります。Votorの証明書システムは、各スロットが単一のハッシュまたは明示的なスキップのいずれかにコミットすることを保証し、重複ブロックのリプレイを容易にします。

Tower BFTの設計は革新的である一方、バリデータ運用にかなりの複雑さをもたらしていることが分かります。

Alpenglowはどのように機能しますか？

Alpenglowは、2つのコアコンポーネントを中心に構築されています。

• Rotor：既存のTurbineアーキテクチャを基盤に強化された、アップグレード版のブロック伝播プロトコルです。
• Votor：Tower BFT、ゴシップベースの投票伝播、コンセンサス参加におけるProof of Historyを置き換える新しい投票プロトコルです。

以降のセクションでは、これらのコンポーネントを詳しく説明します。

Rotor：新しいデータ配布レイヤー

Rotorは、Solanaの既存のTurbine設計を基盤として、効率性とシンプルさを大きく向上させたブロック伝播プロトコルです。ファンアウト200の多層ツリー構造を使用するTurbineとは異なり、Rotorはシングルホップモデル（2δ）を使用します。 

ブロックはスライスに分割され、各スライスはReed-Solomon消失訂正符号を使って複数のシュレッドに符号化されます。シュレッドの真正性を保証するため、リーダーはシュレッドのハッシュからMerkleツリーを作成し、そのルートに署名します。各シュレッドには、このツリー内のパスとリーダーの署名が含まれます。

各シュレッドはリレーノードへ直接送信されます。次にリレーは、次のリーダーを最優先にして、自身のシュレッドをネットワーク内のすべてのノードへブロードキャストします。この単一レイヤーのアプローチはレイテンシを短縮し、伝播経路を簡素化します。また、驚くほど高速です。

リーダーとシュレッドリレーはどちらも、ステーク加重サンプリングによって選択されます。つまり、各ノードは自身のステークに比例した量のデータ送信を担当します。消失訂正符号化により、ノードはシュレッドの一部を受信するだけで元のブロックスライスを復元できます。

Turbineとの大きな違いは、Rotorが各シュレッドについて消失訂正符号化された単一のバージョンだけを送信することです。Turbineのように、データシュレッドとリカバリーシュレッドを個別に送信する必要がありません。冗長性、つまりデータ拡張率は変わりませんが、この設計により、データシュレッドの転送に関する不自然な駆け引きがなくなり、プロトコル設計が簡素になります。

Rotorのアーキテクチャは、DoubleZeroのようなマルチキャストシステムとも互換性があり、ブロックの配信方法に柔軟性をもたらします。ブロック伝播は大量の帯域幅を消費するため（現在、大規模なバリデータでは1秒あたりの送信パケット数が150,000に近づいています）、Rotorはデータを配布したリレーに報酬を与えるモデルを導入し、ネットワーク性能を支えるインセンティブを整合させます。

Alpenglowホワイトペーパーでは、報酬の計算や配布に関する具体的なメカニズムは定義されていません。ただし、Rotorの報酬では消費した帯域幅を考慮し、より多くのデータを中継したノードがより多くの報酬を受け取るべきだと記されています。

Blokstorとは？

Blokstorは、ノードがRotorから受信したブロックデータを保存、管理する場所です。より厳密には、Blokstorはスライスの保存を管理するデータ構造です。シュレッドを受信すると、次の条件を含む一定の要件を満たしている場合に、その内容がBlokstorへ追加されます。

• Blokstorに該当インデックスのシュレッドがまだ含まれていないこと
• 有効なリーダー署名があること
• 有効なMerkleツリーパスがあること

Blokstorは、slot(b)について最初の完全なブロックbを受信すると、イベント「Block(slot(b), hash(b) hash(parent(b)))」を発行します。Blokstorは、同じスロットの代替ブロックを収集して保存する修復手順も実行できます。ブロックがファイナライズされると、Blokstorは該当するスロットにそのブロックだけを保存する必要があります。

Votor：新しい投票・ファイナライズエンジン

VotorはAlpenglowの新しい投票・ファイナライズエンジンで、ブロックの公証とファイナライズにおいてTower BFTを置き換えます。効率性とシンプルさを高めるため、Simplexの一連の研究から着想を得て、それをProof of Stakeのコンテキストに適用しています。 

Simplexは、ネットワーク遅延の厳密な上限が分かっていれば、ローテーションリーダー方式のProof of Stake環境で、非常に小さなメッセージを使って効率的にビザンチン合意へ到達できることを示しています。Votorはこの知見を基に、1回または2回のラウンドでコンセンサスを形成します。

大まかに言えば、Votorは各スロットについて、そのスロットがスキップされたことを示すスキップ証明書、または公証済みブロックの正規チェーン上に構築された公証済みブロックのいずれかが存在することを保証します。ブロックを公証するには、有効な証明書が必要です。バリデータは投票をゴシップに大量送信する代わりに、従来のSolanaゴシップではなく、一種の「直接送信」メッシュとして、ステーク加重されたピア集合へ軽量な投票メッセージをブロードキャストします。定足数に達すると、どのノードでもBoneh–Lynn–Shacham（BLS）署名方式を使って、これらの署名を1つの証明書に集約できます。オンチェーンに記録されるのは集約された証明書ヘッダーであるため、スロットごとの投票トランザクションが不要になります。

Votorの投票メカニズムはどのように機能しますか？

Votorは、次の2つの投票経路に分かれた、段階的かつ並行する投票メカニズムを使用します。

• 高速ファイナリティ：提案されたブロックが第1投票ラウンドで80%以上のステーク承認を得ると、ブロックは直ちにファイナライズされ、高速ファイナリティ証明書が生成されます。80%のステークは圧倒的多数のしきい値を十分に上回るため、ファイナライズに第2投票ラウンドは必要なく、1ラウンドでファイナライズできます。
• 低速ファイナリティ：第1投票ラウンドで得たステーク承認が<80%かつ60%以上の場合、Votorは直ちに第2投票ラウンドを開始します。この第2投票ラウンドが60%以上のステーク承認に達すると、ファイナライズ済み証明書が生成されます。

両方の経路は並行して実行され、最初にしきい値を満たした経路がブロックをファイナライズします。リーダーは親ブロックの取り込みを完了すると、投票がまだ集まっている間でも次のブロックの送信を開始できます。そのため、Solanaの旧コンセンサスと同様に、~400msごとに1つのブロックが生成されます。この設計により、第1ラウンドが80%以上のステーク承認を得られなかった場合、Votorは第2投票ラウンドへフォールバックします。また、ステークが重複するため、競合する2つのブロックが両方ともファイナリティに達することはありません。

VotorのPoolデータ構造とは？

Poolは、すべてのノードが維持するデータ構造であり、投票活動と証明書生成のローカル台帳として機能します。各スロットと各ノードについて受信した投票をメモ化します。十分な投票を受信すると、対応する証明書が生成されます。新たに受信した証明書または自身で構築した証明書がPoolへ追加されると、他のすべてのノードへブロードキャストされます。 

複数のバリデータがほぼ同時に証明書を作成する可能性はありますが、定足数のしきい値を満たす証明書であれば、署名集合に含まれる具体的なバリデータに関係なく、コンセンサス上の機能は同等です。唯一の例外はファイナライズ済み証明書です。最大3つの異なる証明を流通させる必要がある場合があるためです。特定のスロットについて、すべての種類を合わせても一意な証明書が4つを超えることはなく、各一意な証明書は1回だけブロードキャストされます。このアプローチにより、投票スパムを防ぎながら、Poolが定足数を示した瞬間に、どの誠実なノードでも証明書を構築して共有できます。

重要なポイント

投票は単一のUDPパケットとしてすべてのバリデータへストリーミングされます。各バリデータは、スロットとノードごとに受信した投票をメモ化します。Votorにおける特定のブロックの公証とファイナリティは、次の3つの条件によって決まります。

• 第1投票ラウンドで80%以上のステーク承認を得ること。
• 第1投票ラウンドと第2投票ラウンドで60%以上のステーク承認を得ること。
• ブロックがファイナライズされたことを示す有効な証明書を、別のバリデータから受信すること。

Proof of Historyの廃止

Rotorはブロックデータを1ホップで伝播し、Votorの目標レイテンシ上限は~150msであるため（次のセクションで詳しく説明します）、Solanaに分散型クロックは不要になります。代わりに、単純なローカルクロックで十分です。Alpenglowは、Proof of Historyをローカルタイムアウトタイマーに置き換えます。

Votorのタイムアウトメカニズムはどのように機能しますか？

実際のタイムアウトシステムは、次のように動作します。

• リーダーウィンドウ：リーダーは、スロットあたりΔblock ≈ 400msの4スロットウィンドウを担当します。
• データ到着またはタイムアウト：リーダーの親ブロックが公証された瞬間に、各バリデータはタイムアウトを起動し、スロットごとに1つ、合計4つの期限をt = now + Δtimeout + slotIndex * Δblockとして事前設定します。ここで、Δblock ≈ 400msです。これらのタイマーはリセットされず、上限として機能する点に注意してください。ブロックのシュレッドが時間内に到着すると、そのスロットにはNotarVoteメッセージで投票し、保留中のタイムアウトは何も実行しません。一方、シュレッドが到着する前に時間切れになると、バリデータはリーダーが不正または稼働不良であると判断し、SkipVoteを発行します。
• 証明書生成：前述のとおり、公証済みブロックには高速ファイナリティ証明書またはファイナライズ済み証明書が生成されます。スキップされたスロットには、スキップ証明書も生成できます。

Alpenglowは、各バリデータがローカルかつ独立してタイムアウトを測定するシステムを導入します。そのためSolanaには、Proof of Historyのようなハッシュ駆動型の単一クロックが不要になります。メッセージは単一のUDPパケットで、Rotorもシングルホップであるため、ハッシュ処理なしでも400msという上限は現実的です。バリデータはハッシュを継続的に計算する必要がなくなり、ロックアウトを課されることなくブロックに反対票を投じられます。また、Firedancerなどの代替クライアントも、AgaveクライアントのProof of History実装を再現する必要がなくなります。

スロットのスキップ

バリデータは、SkipVoteメッセージを送信してスロットをスキップすることもできます。60%以上のステークがSkipVoteメッセージを送信すると、スキップ証明書が生成され、そのスロットは正式にスキップされます。スキップ投票は公証投票と同じ報酬ウェイトを持つため、リーダーが不正な挙動をしているときにバリデータが沈黙するインセンティブはありません。Alpenglowの経済モデルが確定すると、この点が変更される可能性があります。

バリデータは、スロットのブロックをファイナライズできないと判断した場合、そのスロットにSkipVoteを送信します。原因としては、タイムアウト、ブロックの欠落、無効または不正な形式のブロックの生成などが考えられます。リーダーの4スロットウィンドウの最初のスロットでこれらの条件のいずれかが発生すると、バリデータはウィンドウ全体を不良と判断します。その後、ウィンドウ内の残りのスロットを順に処理し、まだ投票していないすべてのスロットへSkipVoteを発行します。そのため、4スロットのウィンドウ全体を1回のスキップラウンドにまとめられます。各投票の対象は依然として1つのスロットですが、ほとんどのバリデータが同じ一斉送信を行うため、保留中の3スロットはほぼ同時に60%のしきい値へ到達します。これは、オフラインのリーダーがタイムアウトするまで、クラスターが空の3スロットをさらに待機する事態を防ぐためです。

当然ながら、これによりブロック生成に空白が生じます。しかし、この高速なスキップ証明書により、スロットの進行は中断されません。スキップ証明書は該当スロットの正規の「nullブロック」として機能し、すべての誠実なノードがスキップを結果として採用するため、フォーク選択が簡素化され、一貫性が向上します。したがって競合フォークは発生せず、スキップが永続的なフォークにつながることもないため、通常のブロック生成タイミングを維持できます。

バリデータ報酬

Votorにおけるバリデータ報酬は、投票と証明書生成への参加に基づきます。ブロックへの賛成（NotarVote）または反対（SkipVote）の投票を行ってコンセンサスに貢献したノードは、同じ報酬を受け取ります。これにより、ノードが多数派を予測したり、多数派に合わせたりするのではなく、自身の状態に基づいて投票する誠実な参加が促されます。

現時点では、具体的な報酬実装は定められていません。

Alpenglowのパフォーマンスベンチマークとシミュレーション結果

Anzaのシミュレーションによると、Alpenglowは、Fast-FinalizationまたはFallback（すなわちSlow-Finalization）のどちらの経路でブロックが公証されるかに応じて、およそ100〜150msでブロックをファイナライズします。Fast-Finalization経路は~100msのレイテンシを目標とし、Slow-Finalization経路は~150msを目標とします。

レイテンシのヒストグラム

ネットワークレイテンシは、あらゆる分散システムにおける通信の根本的な下限を決めます。たとえば、リーダーがニューヨークにあり、ステークの過半数がヨーロッパにある場合、ノードが他のネットワークノードへ情報を送信する際の片道レイテンシの中央値は約200ミリ秒に達することがあります。地理的に近いノード（同じデータセンターやリージョン内のノードなど）ではレイテンシが低く、グローバルサウスなどの遠隔地にあるノードでは大幅に高くなります。

• ネットワーク： インターネット経由で他のノードに1ビットを送信する際のネットワークレイテンシです
• Rotor： この下限と比べてRotorがどの程度遅いかを示します
• 公証： ステークの60%から公証済みの投票を受信するまでの時間です（さらにもう1ラウンドの投票を行うこともでき、受信後にファイナリティを開始できます）
• ファイナリティ： ファイナライズにかかる時間です

Alpenglowのファイナリティは全体として下限の2倍です。つまり、コンセンサスのオーバーヘッドは、生のネットワーク下限に対して2倍の係数となります。そのため、リーダーと特別多数のステークとの間で最長の片道ホップが、たとえば~70ms（すなわち~140ms RTT）であれば、高速経路のファイナリティは120〜150msの範囲に収まるはずです。

Anzaのシミュレーションによるレイテンシヒストグラムでは、ステークの65%が生のネットワークレイテンシから50ms以内にファイナライズしています。これは、ほとんどのバリデータがデータの到着直後に投票することを意味します。

Alpenglowでは、決定論的なコミットメントが競合するどのL1よりも大幅に短くなり、Solanaのオンチェーン体験が従来のWeb2サービスに大きく近づきます。

Alpenglowのセキュリティと耐障害性の分析

Alpenglowのコンセンサスは、ネットワークのステークの最大33%を支配する敵対者に対して耐性を維持する従来のBFTコンセンサスを改良したものです。これは「3f + 1」と表されます。Alpenglowは、MartinとAlvisiがFast Byzantine Consensusで導入した5f + 1の境界に基づき、この上限をネットワークのステークの20%まで引き下げます。セキュリティを次の2つに分ける「20+20」耐性モデルを採用しています。

• ビザンチン障害 ≤ 20%：総ステークの20%未満が敵対的なバリデータに支配されている場合、安全性が維持されます。これは数十億ドル規模の莫大な金額であり、容易に特定して処罰できます。そのため、攻撃者はステーク全額を失うリスクを負い、このような攻撃は経済的に成立しません。
• 悪意のない事象 ≤ 20%：敵対的なステークとは別に、総ステークの最大20%がオフライン、クラッシュ、またはその他の理由でコンセンサスに参加していない場合でも、ライブネスが維持されます。これには、ネットワーク障害、設定ミス、ソフトウェアのバグが含まれます。そのため、かなりの少数のバリデータが応答しなくても、ネットワークはブロックをファイナライズし続けられます。

安全性

敵対的な総ステークが≤20%であり、1つのフォークで少なくとも60%の誠実な参加を妨げられない限り、安全性が保証されます。これらの条件により、プロトコルが最終確定とみなす投票しきい値（すなわち、1ラウンドの高速経路と2ラウンドの低速経路）は、別のフォークで競合するしきい値に到達できないほど高くなります。敵対的なバリデータが二重投票（すなわち、2つの異なるフォークへの投票、または同じスロットでの2つの異なるブロックの生成）を試みた場合、誠実なノードは最終的に競合する署名を受信します。これは容易に特定でき、将来的には理想的に、スラッシングなどの処罰対象となる違反につながります。 

さらに、リーダーが無効なブロックを生成しようとしても、誠実なバリデータは単に投票を拒否します。Alpenglowの投票における直接通信モデルでは、悪意のある主体が誠実なノードをステーク上で孤立させたり、エクリプス攻撃を仕掛けたりすることは困難です。最終的には、誠実な多数派の投票によって露見するためです。悪意のあるリーダーにできるのは、せいぜいコンセンサスを低速経路へ移行させるか、1スロットの遅延を引き起こすことだけで、チェーンを永続的に停止または分岐させることはできません。

ライブネス

障害しきい値が守られている限り、部分同期の条件下でライブネスが保証されます。つまり、一定のネットワーク遅延の後、誠実なバリデータは通信し、いずれかのブロックでステークの≥60%を集められます。総ステークのちょうど20%がオフラインでも、残りの誠実なノードがすべて投票すれば、高速経路が成功する可能性があります。総ステークの20%をわずかに超える量がオフラインの場合、ネットワークは一貫して2回目の投票を行う低速ファイナライズ経路を使用します。遅くはなるものの、ファイナリティは引き続き保証されます。したがって、良性の障害は主にパフォーマンスに影響し、安全性には影響しません。

高いクラッシュ耐性

Alpenglowは、過酷なネットワーク状況に対処できるよう、高いクラッシュ耐性を明確に念頭に置いて設計されています。つまり、ステークの20%が悪意を持ち、20%が応答しない状況でも、Alpenglowは安全性を維持して動作し続けます。 

ただし、これは考え得るあらゆる障害に対する万能薬ではありません。AlpenglowはSolanaにとって大幅な改善ですが、前提条件が破られた場合のネットワーク停止や障害のリスクを完全に排除するものではありません。新しいブロックの生成にはステークの≥60%が必要であり、ステークの≥20%が悪意を持って行動すると、コンセンサスを妨げたり障害を引き起こしたりする可能性があります。それでも、定義された範囲内であれば、Alpenglowは1回または2回の投票ラウンドで安全性とライブネスを保証します。

Proof of Historyを廃止するとセキュリティは低下しますか？

Solanaの現在の運用に不可欠ではありますが、Proof of Historyを廃止しても、セキュリティが実質的に低下することはありません。前述のとおり、Proof of Historyのハッシュクロックは一律の400ms境界に置き換えられます。ネットワークで大幅な遅延が発生しても、Votorのステークの重複（すなわち、1ラウンドでは≥80%、2ラウンドでは≥60% + ≥60%）により、誠実なバリデータが2つの異なるフォークを承認することはありません。

ただし、ライブネスは同期メッセージに依存するため、ライブネスの保証は変化します。誠実なメッセージがこの遅延の範囲内に到着する限り、ライブネスは維持されます。Rotorの1ホップでのデータ配信と単一パケットの投票により、高負荷時でもレイテンシは400msの範囲内に十分収まります。

総合すると、Proof of Historyを廃止することで、継続的なハッシュ計算への依存がなくなり、ハッシュ停止を利用した攻撃ベクトルも排除されます。前述のとおり、ライブネスの保証も変化します。しかし、Proof of Historyを廃止しても、セキュリティが実質的に低下することはありません。

主なポイント

Alpenglowは、ビザンチン耐性をわずかに下げる代わりに、1秒未満の決定論的ファイナリティ、大規模な良性障害への安定した対応、悪意のあるバリデータの特定の容易さを実現します。主なポイントは次のとおりです。

• ステークの≥20%が二重署名しない限り、競合する2つのブロックが両方ともファイナライズされることはありません。二重署名は容易に証明でき、処罰可能な行為です。
• 残りのステークがオフラインでも、ステークの≥60%が通信できる限り、Solanaはブロックをファイナライズし続けます。
• 最悪の場合、ファイナリティは~150msのレイテンシを目標とする2回目の投票にフォールバックします。これにより、攻撃は安全性を脅かす前にチェーン速度を低下させます。
• 20%のビザンチン上限を突破するコストは非常に高く、より小規模な不正行為は検出可能です。メインネットでスラッシングが稼働すれば、社会的にも経済的にも処罰できます。

Alpenglowはバリデータにどのような影響を与えますか？

投票コストは、Solanaバリデータを運用する際の最大の参入障壁です。バリデータの運用に必要なSOLの厳密な最低額はありません。しかし、コンセンサスへの参加に必要な各スロットでの投票トランザクション送信には、1日あたり最大~1 SOLかかることがあります。

Alpenglowは、スロットごとの投票トランザクションをコンパクトな証明書システムに置き換え、現在のような投票手数料を事実上なくすことを目指しています。各バリデータは軽量な投票メッセージを他のすべてのノードにブロードキャストします。クォーラムに達すると、どのノードでもBLS署名方式を用いてそれらの署名を1つの証明書に集約できます。投票がBLSで集約されるため、オンチェーンに記録されるのは証明書ヘッダーだけです。実際には、バリデータ1台あたり1日~1 SOLのコストがなくなります。 

前述のとおり、Alpenglowでは、各ブロック提案が並行する2つの投票経路で評価されます。

• Fast-Finalization（1ラウンド）
  • 1回目の投票で、特定のブロックに対する公証済み投票数がステークの≥80%に達すると開始されます
  • Fast-Finalization Certificateを生成します 
  • レイテンシ目標は~100msです
• Slow-Finalization（2ラウンド）
  • 1回目の投票で、特定のブロックに対する公証済み投票数がステークの≥60%に達すると開始されます
  • 2回目の公証済み投票数がステークの≥60%に達すると、Finalization Certificateを生成します
  • レイテンシ目標は~150msです

Votorは両方の経路を並行して実行します。つまり、両方の集計値が同じ1回目の投票ストリームから更新され、最初にしきい値を超えた証明書がブロックをファイナライズします。ステーク集合の重複（すなわち≥60%）により、競合する2つのブロックが両方ともファイナリティに達することはありません。

この新しい設計がバリデータの運用にもたらす影響は良好です。

運用コストの削減 

投票手数料をなくすことで、将来のバリデータにとって参入障壁が大幅に下がります。また、投票手数料があることで、弱気相場では小規模なバリデータほどインフレ報酬への依存度が高くなっていました。議論を呼んだSIMD-228の投票を踏まえると、その廃止はSolanaのインフレに関する今後の議論につながる可能性があります。現在議論されているAlpenglowの実装では、Cogent Cryptoのバリデータ収益計算ツールによる計算上、この削減により収益化に必要なSOLの最低額が~4850 SOL（~80万米ドル）から~450 SOL（~7万5,000米ドル）へ減少します。

鍵管理の簡素化 

Solanaバリデータでは、スロットごとの投票署名が不要になります。これにより、パフォーマンス上のリスクを伴わずにバリデータのID鍵をハードウェアセキュリティモジュール（HSM）内に保管でき、ホットウォレットのリスクを効果的に軽減できます。

リーダースロットのネットワーク負荷軽減

エポックごとの数千件の個別投票トランザクションをブロックごとの1つの証明書に集約して置き換えることで、リーダースロットのネットワーク負荷が軽減されます。 

ロックアウト計算の廃止

SolanaのTower形式の指数関数的ロックアウトテーブルは廃止されます。バリデータは最新の証明書チェーンだけをメモリ上で追跡すればよくなり、再起動時間が短縮されます。

AlpenglowはRPCプロバイダーにどのような影響を与えますか？

この新しい設計がRPCプロバイダーの運用にもたらす影響はおおむね良好ですが、スケーラビリティ上の潜在的な懸念もいくつかあります。

コミットメントレベルの簡素化 

この新しいファイナリティレベルにより、confirmed（すなわち楽観的）とfinalized（すなわちルート化済み）のコミットメントレベル間にあった従来の差がなくなります。たとえば、2つの確認レベルを待つUXロジック（ファイナライズされるまでスピナーを表示するなど）を、1回の証明書チェックに減らせます。

台帳サイズの削減

Solanaの現在の需要を前提とすると、投票トランザクションがなくなることで、台帳の増加量はおよそ4分の3減少します。これは、スナップショットとアーカイブのサイズ縮小も意味します。ただし、ブロック上限のCU引き上げについて予測されている目標を考慮すると、実際にどのような結果になるかはまだ明らかではありません。

WebSocketファンアウトのボトルネック

Alpenglowでは、ファイナリティが~100〜150msで到達し、単一の証明書にエンコードされるため、トランザクションをポーリングする意味がなくなります。アプリ、ブラウザ、またはボットの稼働中は開いたままになるプッシュチャネルを通じてファイナリティ情報を取得し、購読中のすべてのクライアントに新しい証明書をブロードキャストする方が合理的です。ボトルネックは、数百万件の小さなHTTPポーリングから数十万件のリアルタイムソケットへ移ります。

リアルタイムキャッシュの鮮度

証明書によってブロックが100〜150ms以内に確定するため、アカウントデータを4分の1秒より長く保持するキャッシュは、古いデータを表示する可能性があります。エッジキャッシュ、CDN、レイヤー7プロキシには、極めて短いTTL、または証明書を認識するパージフックが必要になります。

Alpenglowの開発スケジュールは？

Alpenglowは5月下旬、ニューヨークで開催されたAccelerateカンファレンスで正式に発表されました。次の段階では、正式なSolana Improvement Document（SIMD）を公開し、GitHub、Solanaガバナンスフォーラム、Solana Tech Discordを通じてコミュニティからのフィードバックを募ります。

コミュニティによるレビュー期間を終えると、この提案はバリデータコミュニティによるオンチェーンガバナンス投票へ進みます。並行して、パフォーマンスとセキュリティを確保するため、新しい設計に対する広範なテストが実施されます。

すべての段階が計画どおりに進めば、来年初頭までにSolanaメインネットへデプロイされる見込みです。

Alpenglowのリスクと未解決の課題

新しいコンセンサスアルゴリズム

新しいコンセンサスプロトコルへの移行は大きな取り組みですが、有意義な先例があります。Ethereumの2022年のMergeでは、大規模な稼働中ネットワークが運用を中断することなく、Proof-of-WorkからProof-of-Stakeへ中核のコンセンサスメカニズムを移行できることが実証されました。つまり、依然として多くのリスクはあるものの、まったく前例のない領域ではありません。

また、このような移行には、Alpenglowがconfirmedとfinalizedのコミットメントレベルを単一の証明書チェックに統合しても、アプリ、SDK、ウォレット、ボットが気づかないうちに動作しなくなることを防ぐ移行ガイドが必要です。2つのコミットメントレベルを明示的にポーリングするコードや、デフォルトでconfirmedコミットメントレベルを使用するコードは動作しなくなります。Alpenglowの稼働開始前に、ドキュメント、lint警告、RPCメソッド、コードアーキテクチャ全般について、エコシステム全体で連携した取り組みが必要です。 

ガバナンス

ガバナンスリスクも考慮すべき要因です。最近のSIMD-228投票は、Solanaが真に分散化されたネットワークとして運営されており、コア開発者や著名なコミュニティメンバーが支持する提案であっても、可決が保証されないことを示しています。しかし、Alpenglowが導入する今後の変更、特に投票コストの削減は、バリデータ、とりわけ小規模な運用者に広く有利です。そのため、ガバナンス上の抵抗が生じる可能性は比較的低いと考えています。

報酬

これまでに公開されたAlpenglowのホワイトペーパーおよび関連資料では、バリデータの投票活動に報酬を与える正確な仕組みや、Rotorリレーの帯域幅使用を補償する方法が明記されていません。また、ホワイトペーパーでは二重投票が処罰対象であることを明記していますが、実際に誰が処罰を申請するのか、処罰の規模はどの程度か、対象となる処罰が自動執行かガバナンス主導かについては規定されていません。こうした欠落により、バリデータ経済の重要な側面が未定義のままとなっており、エコシステム内で議論を呼ぶ争点になる可能性があります。

MEV

Alpenglowは、Solanaにおける現在のMEV環境も根本的に再構築します。一部の収益性の高い戦略は、TPUトラフィックのミラーリングや、トランザクションが楽観的に確認される前に特定の順序でスパム的にキャンセルと置換を行うことに依存しているため、レイテンシは引き続きMEVを左右する要因です。これらはすべて現在の~500〜600msの時間枠内で行われますが、Alpenglowはこれを~150msまで短縮しようとしています。一見すると、リーダー、特にカスタマイズされたブロック構築インフラをすでにホストしているバリデータは、より大きな割合のMEVを獲得できる立場にあります。一方、独立系のレイテンシ裁定業者は、さらに高速で粒度の高い取引システムを開発し続けない限り、優位性を失う可能性があります。

複数の同時リーダー

Alpenglowの設計は、Solanaの現在のコンセンサスアーキテクチャと比べて、Multiple Concurrent Leaders（MCL）と呼ばれるマルチリーダーフレームワークをはるかに柔軟に導入できます。Anatoly Yakovenkoが指摘したように、初期のMCLプロトタイプでは、同じRotorセットを共有する2つのAlpenglowインスタンスを立ち上げ、すべてのshredを同時に公開する形が考えられます。Rotorは並列ストリームをファンアウトし、Votorは各レーンを公証します。ただし、実行レイヤーに関するいくつかの疑問が生じます。具体的には、

• 2つのリーダーのブロックが同じアカウントをロックしないように、書き込みセットをどのように分割すべきでしょうか。また、ロックが重複する場合、競合解決を決定論的かつ低コストにするにはどうすべきでしょうか？
• リプレイコストを倍増させずに、レーンごとの証明書を1つの正規状態ルートへ統合するにはどうすればよいでしょうか？
• レーンが資産をめぐって競合する場合、どのような手数料市場のロジックが適用されるのでしょうか？
• これにより、どのようなクロスレーンMEV戦略が可能になるのでしょうか？
• レーン上限がなければ、単一の高ステークバリデータが同時スロットを独占する可能性はあるでしょうか？ 

Alpenglowの設計は、コンセンサスレベルの障害を取り除くことでMCLを現実的なロードマップ項目にするのに役立ちますが、これらの未解決の疑問に答えが出るまでは、依然として有望な将来の取り組みです。

まとめ

本レポートでは、Alpenglowの中核コンポーネントを取り上げ、それらがSolanaのコンセンサスモデルをどのように再構築するかを検証しました。また、技術的な改善、バリデータ経済の変化、ネットワークレベルの影響、パフォーマンス、シンプルさ、スケーラビリティのメリットについても分析しました。

Alpenglowのホワイトペーパーは、プロトコル設計だけでなく、開発思想においてもSolanaの転換点となります。Solanaは初めてコンセンサスアルゴリズムの正式な正当性証明を公開し、従来の経験的でエンジニアリング主導のアプローチから、より厳密で研究に裏付けられた基盤への移行を示しました。この進化は、引き続きパフォーマンスを重視しながら、形式検証という規律も取り入れる、成熟しつつあるエコシステムを反映しています。

Proof-of-History（PoH）の廃止は、ネットワークのアイデンティティにおいても同様に象徴的な転換を意味します。PoHの実用上の重要性はしばしば過大評価されてきましたが、長年にわたりSolanaを象徴するイノベーションとして技術解説で大きく取り上げられ、ブランドの代名詞となってきました。その廃止は、1つの時代の終わりと新たな時代の始まりを示します。Solanaは成熟しつつあります。

その他のリソース

• AccelerateでのAlpenglowプレゼンテーション資料 - Roger Wattenhofer
• Alpenglow：Solanaの新しいコンセンサス - Anzaブログ
• Alpenglowリファレンス実装 - GitHub
• Alpenglowホワイトペーパー - Quentin Kniep、Jakub Sliwinski、Roger Wattenhofer
• Solanaのコンセンサス - Heliusブログ
• Accelerate 2025のScale or Die：Solanaの新しいコンセンサスAlpenglowを紹介 - YouTube動画