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

Solanaのトランザクションがファイナライズされるまでには、現在12.8秒かかる。2026年10月21日から、これがメインネット全体で150ミリ秒に短縮される。

この変更がAlpenglowだ。Solanaがローンチ以来最大のコンセンサスアップグレードとなる。Alpenglowは、ネットワークが合意に至る方法を初日から定義してきた2つのシステム、Proof of HistoryとTower BFTを取り除き、よりシンプルで大幅に高速な設計に置き換える。ガバナンス投票では98.27%の賛成で可決され、epoch 1064(10月21日の13:20 UTC頃に開始)でメインネット上で稼働を開始する予定で、Votorはその約18分後のスロット459,653,000で引き継ぐ。

ここでは、切り替え時に何が起こるのか、Alchemyがどのように準備しているのか、そして内部で実際に何が変わるのかを解説する。プロトコルレベルの一次情報については、Solana FoundationのAlpenglowアップグレードページと、仕様を定めたガバナンス提案であるSIMD-0326を参照してほしい。

メインネット切り替え時に何が起こるのか

10月21日の13:20 UTC頃に、新しいepoch(Solanaの約2日間のスケジューリング単位)が始まる。epochの長さは常に一定であるため、切り替えが起こるスロットはすでに分かっている。459,653,000だ。ただし、epochが始まった瞬間にネットワークが切り替わるわけではない。最初の約18分間は従来のコンセンサス方式であるTower BFTを使い続け、そのスロットでAlpenglowの後継であるVotorに切り替わる。これが変えるのはネットワークが内部でトランザクションに合意する方法だけで、ネットワークへのアクセス方法は変わらない。そのため、RPC、WebSocket、gRPCのエンドポイントは、その間も通常どおり動作し続ける見込みだ。

切り替え自体には、ネットワークの十分な割合が準備完了を確認するまでの間、約2ブロック、およそ400ミリ秒かかる見込みだ。この短い間、新しいブロックにはバリデーターの投票のみが含まれ、ユーザートランザクションは含まれない。拒否されるものはないはずだ。そのタイミングで送信されたトランザクションは、切り替えが完了した直後に反映される。

チームに事前に伝えておくべき副次的な影響がある。有効化の直後は、公開ダッシュボード上のトランザクション数とTPSが低く見える。これは利用が減ったからではなく、バリデーターの投票がトランザクションとして数えられなくなるためだ。Alpenglowがブロックスペースの75%を解放するのも同じ理由による。投票が以前はその大部分を占めていたが、今後はそうではなくなる。

有効化が起きた後は、getAgGenesisCertを呼び出すことで、特定のネットワークがすでに切り替わったかどうかを確認できる。切り替え前は何も返さず、切り替え後は(正確なスロットなどの詳細を含む)結果を返す。

AlchemyはAlpenglowにどう備えたか

AlchemyのSolana RPCノードはすべて、有効化に先立ってAlpenglow対応のクライアントをすでに実行している。そのため、RPC、WebSocket、Yellowstone gRPCのエンドポイントに、お客様側での変更は必要ない。また、当社のトランザクションルーティングは、新しいファイナリティのタイミングにバリデーターが一時的に遅れた場合に別のバックエンドで再試行する仕組みをすでに備えている。現在、通常の遅延サーバーに対応しているのと同じ保護だ。

Phantom、Solflare、Cielo Financeなど、Solana上の主要チームが利用している、最高水準のSolana RPC、アーカイブデータ、gRPCストリーミングをAlchemyで活用してほしい。

• 平均読み取りレイテンシ9.21ms。2026年9月29日までの24時間で計測し、次点のプロバイダーより約26%高速
• アーカイブクエリは最大20倍高速、getProgramAccountsのような重いコールは10倍高速で、大規模な履歴クエリでも200ms未満のレスポンスタイム(Solflareが本番環境で検証済み)
• 99.99%のアップタイムSLAと、前世代のスタックと比べて2倍のスループット
• 平均配信5〜15ms、48時間のブロックリプレイを備えたYellowstone互換のgRPC。他の選択肢と比べて約5倍お手頃

Solanaのデータを直接ストリーミングしている場合は、Yellowstone gRPCクライアントのバージョンを確認し、移行期間中はconfirmedのデータのみをコミットしていることを確かめる良い機会でもある。また、confirmedとfinalizedが同じ時点で確定するようになるため、入金反映のようにこれまでfinalizedを待っていたフローは、おそらくより速く進められる。

無料のSolana RPCエンドポイントを始める →

Alpenglowのすべて

VotorとRotorがTower BFTとTurbineを置き換える仕組み

Alpenglowは2つの新しいプロトコルで動く。投票とファイナライゼーションを担うVotorと、ブロック伝播を担うRotorだ。この研究はETHチューリッヒのWattenhofer教授の分散システム研究室から生まれた。実装はAnzaが主導し、Jump CryptoのFiredancerチームがマルチクライアント互換性に取り組んでいる。

ファイナリティが85倍速くなる仕組み

Tower BFTは32回の段階的な確認を必要とし、各確認がロックアウト期間を追加する。Votorはこれを1〜2ラウンドの投票にまとめる。

• ファストパス(約100ms): 最初のラウンドでバリデーターの80%以上が承認すれば完了。
• スローパス(約150ms): 1ラウンド目で60〜80%が承認した場合、2ラウンド目が60%以上のしきい値で確定させる。

両方のパスは同時に走り、先に完了した方が採用される。シミュレーションでは、ステークの65%が生のネットワークレイテンシから50ms以内にファイナライズされる。

バリデーターは、投票をネットワーク上のトランザクションとしてではなく、小さなメッセージとして互いに直接送信する。その後Votorは、BLS集約と呼ばれる署名結合技術を使って、何千もの投票を約1,000バイトの1つの証明に圧縮する。記録されるのはこの小さな証明だけであり、現在ブロックごとに記録されている約500KBの投票データに取って代わる。

その状態を直接インデックス化したりクエリしたりしている場合、getProgramAccountsのような重いコールは、Alpenglowのタイミング改善とは無関係に、AlchemyのSolana APIですでに最大10倍高速に実行される。

Alpenglowがブロックスペースの75%を解放する仕組み

現在、Solanaの全トランザクションの約75%はバリデーターの投票だ。Alpenglowは投票を完全にオフチェーンへ移すため、その領域が実際のユーザーに戻る。ちょっとした調整ではない。ネットワーク容量の4分の3が実際の利用に返され、手数料は下がり、混雑時の渋滞も減る。

AlpenglowがProof of Historyを廃止する仕組み

Alpenglowは、Solana本来の暗号学的時計も廃止する。連続的なハッシュチェーンの代わりに、バリデーターはブロックにかかるべき時間に結びついたシンプルなタイマーを使う。ブロックが時間内に届けば承認し、何も届かないままタイマーが切れればスキップする。時計のずれは比例的に処理され、5%のずれには5%長いタイムアウトがあれば足りる。

各ブロックを生成するのにかかる時間はファイナリティとは別の数値であり、これも変わった。4段階の短縮により400msから200msになり、Alpenglowの有効化に先立つこの10月に完了した。

ファイナリティが3段階から1段階になる仕組み

開発者が最も実感する変化かもしれない。Solanaは現在、トランザクションが通ったかを確認する方法を3つ提供している。processed(最速だが確実性は最も低い)、confirmed(約500ms、小さなロールバックの可能性が残る)、finalized(約12.8秒、永続性が保証される)だ。取引所の入金、ブリッジの確認、清算など、わずかなロールバックの可能性さえ許容できないものは、finalizedを待たなければならない。それ以外はconfirmedで妥協し、その小さなリスクを受け入れている。

Alpenglowはconfirmedとfinalizedを1つに集約する。100〜150msで、すべてのトランザクションは確認された瞬間に永続的になる。processedは最も早く最も確実性の低い観測段階のままなので、確定とみなしてはならない。確実性のために速度を犠牲にする必要はもうない。

これにより、これまで成立しなかったパターンが実現する。マーケットメイカーがクォートは150msで確定すると分かっているため、スプレッドの狭いオーダーブック。パーペチュアル取引所でのより安価なJITオークション。Solana側のファイナリティのボトルネックがないクロスチェーンブリッジ。13秒待ちから即時へと変わる取引所の入金。そして銀行やフィンテックにとっては、ステーブルコインの決済や国境を越えた送金で従来の決済レールと競えるほど速く決済されるトランザクションだ。

高速で決定的なファイナリティは、ガスレストランザクションをSolana上でより洗練された体験として構築することにもつながる。スポンサーもエンドユーザーも、確認ウィンドウを待つ代わりに、1ステップで最終的な答えを得られるからだ。

Alpenglowがバリデーターの経済性を変える仕組み

バリデーター1つあたり約1 SOL/日の投票手数料はなくなる。代わりに、約0.8 SOL/日のValidator Admission Ticketが導入され、全額がバーンされる。ネットワークの上限は2,000バリデーターで、ステーク上位から選ばれる。最低限利益が出るステーク量は約4,850 SOLから約450 SOLに下がり、バリデーターを運用するハードルは約90%低くなる。運用コスト全体も20〜50%下がる。また、アイデンティティキーは常時投票に署名する必要がなくなるため、ハードウェアセキュリティモジュールに移すこともできる。

Alpenglowがセキュリティと引き換えに速度を得る仕組み

Alpenglowは「20+20」のセキュリティモデルを採用している。単体では、明確に悪意のあるバリデーターへの耐性は以前より低く、ネットワークの33%ではなく20%だ。しかし、オフラインや応答しないバリデーターと組み合わせると、何らかの形で障害を起こすネットワークの最大40%まで耐えられる。従来の33%の限界より高い。現実の障害は、悪意のあるバリデーターと単にオフラインのバリデーターが混在することが多いため、この合算値のほうがより現実的な指標だ。

2つの承認しきい値(80%と60%)の合計がネットワークの100%を超えるため、相反する2つの履歴が両方承認されることはないという数学的保証は維持される。

Alpenglowのロールアウトがここに至るまで

Alpenglowは2025年5月のSolana Accelerateで発表され、その年の9月にガバナンスを通過した(SIMD-0326)。プライベートクラスターでのテストとAgave 4.1のリリースを経て、2026年9月にdevnetに到達し、今年の10月21日にepoch 1064でメインネット上で有効化される予定だ。元のホワイトペーパーの一部、スマートサンプリング、非同期実行、Rotorのさらなる改良は、今後の提案に回されている。

最終的な成果は、稼働中のネットワークにおけるコンセンサスの全面的な入れ替え、200ms未満で永続化されるトランザクション、ブロックスペースの75%の解放、そしてバリデーター運用の90%低いハードルだ。

FAQ

Alpenglowはいつ、Solanaメインネットで有効化されますか

epoch 1064、2026年10月21日の13:20 UTC頃です。Votorはスロット459,653,000、epoch開始から約18分後に引き継ぎます。

Alpenglowによってダウンタイムは発生しますか

ダウンタイムは想定されていません。RPC、WebSocket、gRPCのトラフィックは、その間も通常どおり動作するはずです。切り替えの瞬間には、新しいユーザートランザクションが約400ms一時停止する見込みですが、そのときに送信されたものが失われることはなく、切り替えの完了後に反映されます。

Alpenglow後も、confirmedは独立したコミットメントレベルのままですか

いいえ。confirmedとfinalizedは、どちらも約150msの同じ時点で確定するようになり、従来の3段階モデルに取って代わります。

ネットワークがAlpenglowに切り替わったかどうかは、どうすれば確認できますか

getAgGenesisCert(Agave v4.3以降)を呼び出してください。ネットワークがまだTower BFTの場合は何も返さず、Alpenglowで動作している場合は結果を返します。

Alpenglowに向けて、AlchemyのSolana連携を変更する必要はありますか

いいえ。RPC、WebSocket、Yellowstone gRPCのエンドポイントに変更は必要ありません。AlchemyのSolanaノードは、すでにAlpenglow対応のクライアントを実行しています。