Solana「Alpenglow」、10月21日に導入予定 最終確定150ミリ秒を目指すVotorへ

(GuerrillaBuzz/Unsplash)[写真拡大]
ブロックチェーンプラットフォーム「ソラナ(Solana)」は2026年10月21日、合意形成を刷新する「Alpenglow」へのメインネット移行を予定している。第1段階では投票・最終確定プロトコル「Votor」を導入し、トランザクションの最終確定を約150ミリ秒へ短縮することを目指す。
バリデーター運用者には、対応クライアントへの更新と投票アカウントの準備が求められる。取引所やデータ配信事業者にとっても、確定状態の扱いや投票を含むトランザクション集計を見直す節目となる。
■10月21日のエポック1064で移行へ
Solana Foundationの2026年10月時点の案内では、移行の機能ゲートはエポック1064の開始時に有効化される。開始予想は10月21日13時20分ごろ(UTC、日本時間22時20分ごろ)で、スロットの進行によって変動する。
機能ゲートの有効化後も、最初の5000スロットはTowerBFTが動作する。約18分後のスロット459,653,000が移行境界となり、その後、必要な投票と証明書の形成を経てVotorへ切り替わる。
Anzaが当初示した性能見通しでは、TowerBFTの約12.8秒に対し、Alpenglowの最終確定時間の中央値は約150ミリ秒だった。時間にして約85分の1に相当し、条件が整えば約100ミリ秒での最終確定も想定する。この見通しは、当時のメインネットのステーク分布を使い、計算処理の負荷を含めずに行ったシミュレーションに基づく。
■Anzaの研究チームが設計、2025年に公表
Alpenglowは、Agaveバリデータークライアントを開発するAnzaが進める合意形成の再設計だ。投票と最終確定を担うVotorと、ブロックデータの伝搬を担うRotorを主要な構成要素とし、今回の導入対象はVotorである。
研究チームには、チューリヒ工科大学のRoger Wattenhofer教授と、同教授の下で博士号を取得したKobi Sliwinski、Quentin Kniepが参加する。Wattenhofer教授は、分散近似アルゴリズムへの貢献により、2012年のPrize for Innovation in Distributed Computingを受賞している。
Anzaの紹介によると、Sliwinskiはブロックチェーンの合意形成を研究し、DfinityではBFTブロードキャストプロトコルに取り組んだ。KniepはSui、Ethereum、Algorandに関わり、Mysten Labsでは分散実行の理論と実装に携わった。
Alpenglowは2025年5月のSolana Accelerateで公表された。Solana Statusが同年9月2日に公表したガバナンス投票の結果は、賛成98.27%、反対1.05%、棄権0.69%で、全ステークの52%が投票に参加した。
Anzaは今回の移行を約18カ月の開発の成果としている。2026年9月24日にtestnet、翌25日にdevnetで切り替えを実施し、メインネットへの展開準備を進めてきた。
■BLS集約署名で投票をオフチェーンへ
TowerBFTでは、バリデーターが投票を通常のオンチェーントランザクションとして送信する。Votorでは、署名付きの投票メッセージをバリデーター間で直接交換し、一定割合のステークによる投票が集まったことを証明書で示す。
この仕組みを支えるのが、Boneh–Lynn–Shacham(BLS)集約署名だ。複数の署名を一つの短い署名にまとめられ、投票を個別のトランザクションとして処理する負荷を減らせる。高速化には、この集約技術に加え、直接通信と投票ラウンドの削減が組み合わされている。
BLS署名は、Dan Boneh、Ben Lynn、Hovav Shachamが2001年の論文「Short Signatures from the Weil Pairing」で発表した方式に由来し、Ethereumのプルーフ・オブ・ステークでも採用されている。Heliusの技術解説によると、VotorはUDPで投票を送信し、必要な投票を受け取ったノードが証明書を生成・共有できる。
Alchemyが2026年4月に公表した概算では、従来の投票はブロックスペースの約75%を消費し、投票データはスロット当たり約500KBだった。同社は、集約後のオンチェーンデータを約1000バイトと見積もっており、両者の比較では約500分の1となる。
集約署名本体を短く保てることと、証明書全体の構成は区別される。証明書には投票内容や署名者を示す情報も必要となり、ブロックには最終確定に関する証明書などのメタデータを収めるフッターが付く。
■1回と2回の投票経路を並行実行
Votorの高速経路では、全ステークの80%以上に相当する投票が第1ラウンドで集まると、ブロックを最終確定できる。もう一つの経路では、第1ラウンドの60%以上の投票を受けて最終確定用の投票を行い、その第2ラウンドでも60%以上が集まると最終確定する。
二つの経路は並行して進み、先に条件を満たした経路で確定する。60%の投票が集まった段階で第2ラウンドを進められるため、通信の遅いノードから80%分の投票が届くのを待つより、2回の投票を先に終えられる場合がある。
コミュニティーテストクラスターについて、参加者のCryptoVikが2026年8月に紹介したダッシュボードでは、ブロックの96%が高速経路で最終確定し、平均スロット時間は214ミリ秒だった。スロット時間はブロック生成の時間枠を表し、最終確定に要する時間とは別の指標だ。
Anzaの仕様では、移行後の「confirmed」と「finalized」は、どちらも台帳への最終的な確定を示す。同じ状態を指すようになることで、ブリッジ、取引所、カストディ事業者などは、従来の確認から最終確定までの待ち時間を前提にした処理を見直せる。既存RPCは移行時にも両方の指定を受け付ける。
応答速度を考える参考として、決済事業者Payrexxはカード決済の利用承認に通常1~3秒かかると説明している。最終確定の短縮は、リアルタイム取引、ゲームの状態更新、消費者向け決済、AIエージェント間の取引など、確定を待って次の処理へ進む用途の応答性を高める可能性がある。
■5000スロット後に移行境界、82%で証明書を形成
移行手順を定めるSIMD-0384では、機能ゲートの有効化から5000スロット後に移行境界を置く。それまでは通常のTowerBFTによる処理が続き、境界以降のブロックには投票トランザクションだけを収録する。
境界以降のブロックについて、次のスロットに82%以上のステークによる投票が収録されると、そのブロックの祖先のうち境界前の最後のブロックをAlpenglowの起点に選ぶ。バリデーターは、この起点となるブロックにBLS署名付きのジェネシス投票を送る。
82%以上のステークによるジェネシス投票が集まると、ジェネシス証明書が成立する。バリデーターは起点より後の投票専用ブロックを巻き戻し、Votorへ合意形成を引き渡して、ユーザートランザクションの収録を再開する。
投票専用ブロックを使うことで、切り替えに伴う巻き戻しの対象からユーザー取引を外す設計だ。証明書が成立するまでTowerBFTによる投票専用ブロックの生成とジェネシス投票の送信を続けるため、実際の切り替え完了は必要なステークの参加状況に左右される。
開発者はRPCの「getAgGenesisCert」で移行を検出できる。AlchemyのAPI資料によると、Agave 4.3以降で利用でき、TowerBFT動作中はnull、移行後はジェネシス証明書を返す。旧版のノードでは、メソッドが見つからないことを示すエラーとなる。
■運用者は対応クライアントと投票アカウントを準備
Solana Foundationは、エポック1064の開始前にAgave系クライアントの4.3.2系へ更新するよう案内している。対象にはAgave、Jito-Solana、Harmonic Salsaが含まれ、FiredancerとFrankendancerの運用者には、移行に向けたクライアントの切り替えを求めている。
クライアントの構成は、移行に必要なステークの確保にも関わる。Solana Compassが10月13日15時24分(UTC)に取得した上位500バリデーターのデータでは、全有効ステークに対する割合はFiredancerが約6.8%、HarmonicFiredancerが約7.1%、FireBAMが約1.6%、Frankendancerが約0.3%で、合計約15.8%だった。
Solana Compassは、これらがすべてジェネシス投票に参加しなければ、残るステークは約84%になると試算した。この集計はクライアントの表示名に基づく10月13日時点のもので、運用者による切り替えが進めば構成も変わる。
バリデーターには、投票アカウントへのBLS公開鍵の登録も必要だ。Anzaによると、BLS公開鍵登録と参加資格を管理するVATの機能ゲートは2026年7月にメインネットで有効化済みで、登録済みの鍵などを基に参加対象を選別する。
■投票手数料からエポック単位のVATへ
投票がオフチェーンへ移ると、個々の投票トランザクションにかかる手数料はなくなる。代わって、合意形成への参加費用としてValidator Admission Ticket(VAT)を徴収する。
Anzaの現行運用資料では、VATは1エポック当たり0.8 SOLで、投票アカウントから差し引かれて全額が焼却される。運用者は、アカウントのrent免除に必要な最低残高に加え、VATを支払えるSOLを確保する必要がある。
最初の徴収はエポック1064の開始時で、エポック1065への参加に充てられる。以後も各エポックの開始時に次のエポック分を支払い、残高が足りなければ、その次のエポックでは投票とブロック生成の対象から外れる。従来の投票手数料を支払っていたidentityアカウントと、VATを支払う投票アカウントの違いにも注意が必要だ。
参加対象は、条件を満たすバリデーターのうちステーク量の多い最大2000に制限される。VATは投票手数料の廃止後も参加に経済的な費用を持たせる仕組みで、全額焼却によってSOLの新規発行を相殺する方向に働く。
Alchemyは2026年4月の解説で、総運用費が20~50%減り、採算に必要なステークが約4850 SOLから約450 SOLへ約90%下がるとの推計を示した。実際の採算は、ハードウェアや通信費、報酬率、手数料収入などの条件に左右される。
■TPS集計とデータ配信の扱いも変わる
Alpenglowが変更する中心は合意形成で、Solana Virtual Machine、トランザクション形式、一般の取引に対する手数料の仕組みは維持される。既存のプログラムや通常の送金を利用する大半のユーザーは、そのままサービスを使い続けられる。
一方、バリデーター投票がブロックからなくなるため、投票を含めて計算したTPSや総トランザクション数は減る。データプロバイダーや取引所は、ユーザー取引と投票をどう数えていたかを確認し、ダッシュボードや監視の基準を調整する必要がある。
Geyserなど、バリデーターからのデータ配信を利用する基盤では「bank_id」への対応も重要になる。これは、同じスロットに属する異なるブロック候補の実行状態を区別する識別子で、gRPCなどを通じてデータを受け取る側も、配信サービスの仕様を確認する必要がある。
PoHによるtickエントリーもなくなるため、tick数からスロット内の経過を推定していた処理や、最後のtickをブロック完了の目印にしていた処理には変更が生じる。Anzaの資料では、ブロックフッターを受け取るGeyser通知も用意されている。
■「20+20」の耐障害性と通信遅延の論点
Alpenglowの安全性モデルは、敵対的な動作をするステークと、停止して応答しないステークを分けて扱う。Anzaは、敵対的ステークが20%未満という条件の下で安全性を確保し、追加のネットワーク条件の下では、さらに20%のステークが応答しない状況でも処理を進める「20+20」の設計を示している。
古典的なBFTでは、敵対的な参加者を全体の3分の1未満に抑える設計が広く用いられる。Lamport、Shostak、Peaseによる1982年の研究や、Martin、Alvisiによる「Fast Byzantine Consensus」の研究は、障害への耐性と通信ステップ数の関係を扱ってきた。Alpenglowも、1回の投票による高速確定と、障害時の進行を両立させる設計上の選択をしている。
Sei Labsの研究部門は2025年6月の分析で、地理的に遠いバリデーターが高速経路に参加しにくくなる可能性を指摘した。接続性の高い拠点への集中を促すおそれがあるとの見方で、通信遅延と参加分布は性能を評価する上での重要な論点となる。
Heliusも2025年5月の設計分析で、取引の順序付けなどから生じる最大抽出可能価値(MEV)の変化、複数リーダーによる同時処理、相反する投票への罰則の具体化を検討課題に挙げた。これらは当時の設計に対する分析として示されたものだ。
■PoHからローカルタイムアウトへ、Rotorは後続
Proof of History(PoH)は、Anatoly Yakovenkoが2017年に公表した構想の中核をなす、出来事の順序と時間経過を示す仕組みだった。Alpenglowでは、各ノードが測るローカルタイムアウトと投票証明書を使ってブロック生成やスロットの進行を管理する。
ブロック生成の時間枠を短くする変更も別途進んでいる。Solanaの公式アップグレード情報では、2026年10月時点のメインネットのスロット時間は、従来の400ミリ秒から200ミリ秒へ短縮されている。
後続のRotorは、Turbineによるブロック伝搬を単一の中継層へ再設計する構想だ。データの一部が欠けても復元できる消失訂正符号を使い、通信の中継回数を減らして伝搬遅延を抑える。SIMD-0326では別の提案として扱う予定で、メインネット導入日は未定である。
今回の移行では、Votorによる最終確定時間と、対応クライアントを使うバリデーターの参加状況が焦点となる。投票をブロックから切り離す設計が、本番環境の応答速度や運用負荷にどのように表れるかが注目される。
元記事: Solana Alpenglow Goes Live Oct 21: Votor Protocol Cuts Finality From 12.8 Seconds to 150ms
※この記事はTech Timesから提供を受けた記事を日本向けに翻訳・編集したものです。
スポンサードリンク
関連キーワード
