Solana Alpenglow：高速な確定の前に必要な合意の引き継ぎ
AnzaはAlpenglowのメインネットベータ移行を10月21日と案内した。注目点は引き継ぎだ。検証者は確定のルールを変える前に、共通の履歴をどう保つのか。
AI生成の概念イラスト。二人の信号担当者が同じ記録ブロックを別の制御系へ引き継ぐ。共通の履歴を受け渡す比喩であり、実在の担当者や手作業の移行手順を描いたものではない。
要点
- 2026年10月20日に確認したAnza公式ページは、メインネットベータの日程を10月21日と案内している。本稿は発表済みの計画を説明するもので、移行完了の報告ではない。
- 移行設計は機能の有効化と後の投票専用境界を分け、ステークの82%以上によるジェネシス証明書で引き継ぎ地点を定める。
- Votorは投票と確定を変更する。Rotorは後続段階であり、当初の150msという中央値はシミュレーションに基づく。全取引への保証ではない。
出来事のタイムライン
AnzaがVotorとRotorを紹介し、確定時間の推定に用いたシミュレーション条件を説明した。
Anza公式ページでテストネットとデブネットの完了表示、10月21日のメインネットベータ予定を確認した。
10月20日時点でAnzaが示した日付。予定日そのものは移行完了の証明にならない。
新しいエンジンが動く前に
AnzaのAlpenglowページに、Solanaのメインネットベータ移行日が示された。10月21日だ。CoinYQが2026年10月20日に確認したページでは、テストネットとデブネットが完了とされている。メインネットの完了は別に確認すべき事実である。期待される速度の前にある問題は、検証者が同じ履歴を引き継ぎながら、合意のルールをどう変えるかだ。[1]
移行提案SIMD-0384は、この問題を扱う。目的はTowerBFTで確認済みのユーザー取引を巻き戻さずに引き継ぐことだ。今回参照したリポジトリのスナップショットでは、移行提案とAlpenglow提案の状態は依然として「Review」と記載されている。提案文書は設計を、現在のAnzaページは予告日程を示す。いずれも、それだけでメインネットの有効化を証明するものではない。[2][3][1]
ユーザー取引を一時的に受け入れない境界
説明されている手順では、機能が有効になっても合意方式は直ちに切り替わらない。有効化スロットから5,000スロット後を移行境界とする。その境界以降、ブロックに入れられるのは単純な投票トランザクションだけになる。RPCのコミットメント更新とTowerBFTのルート設定も停止する。破棄される可能性のあるブロックに通常のユーザー取引を追加せず、引き継ぎ地点を決めるための区間だ。[2]
次に検証者は、境界以降のブロックのうち、その直後のスロットの子ブロックにステークの82%以上の投票が含まれるものを探す。そのブロックの祖先で、境界より前の最新ブロックをAlpenglowのジェネシス候補とする。さらに、その候補へのBLSジェネシス投票がステークの82%以上に達すると、ジェネシス証明書が成立する。新しい合意が出発する共通の履歴を、この証明書で特定する。[2]
履歴を受け継ぎ、同意の方法を変える
証明書を検証した検証者は、ジェネシスブロックに状態を戻し、Votorを開始してユーザー取引の受け入れを再開する。初期のAlpenglowブロックには証明書が含まれ、再実行によってオンチェーンのアカウントにも移行の証拠が記録される。カウントダウンより具体的な確認材料が残るわけだ。Anzaは引き継ぎに数百ミリ秒を見込むが、これは実際のメインネットで測定された所要時間ではない。[2][1]
Votorの通常の投票基準は、移行時の82%とは異なる。ステークの80%が参加すれば1ラウンド、60%なら2ラウンドで確定する経路を並行して動かす。合意の投票ごとにオンチェーン取引を作る代わりに、検証者間で直接投票を送り、署名を証明書に集約できる。変わるのは検証者が合意を成立させる方法であり、ウォレットのチェック表示が速く出るという話だけではない。[3][4]
150msだけでは分からないこと
2025年5月の最初の紹介記事は、確定時間の中央値を約150ミリ秒と予測した。その数値は当時のメインネットのステーク分布によるシミュレーションに基づき、計算処理の負荷を含まないと明記されている。中央値は最大値ではない。また、合意の遅延を模擬した値は、ウォレット、RPCサービス、アプリを通る全ユーザーの待ち時間を測ったものでもない。[4]
Alpenglowという名称の中にも、今回の適用範囲がある。SIMD-0326はVotorを対象とする一方、当初のデータ配信にはTurbineを残す。配信方式を置き換えるRotorは対象外で、後続の提案が必要になる。現在のAnzaページもRotorを今後の作業に挙げている。当初のプロトコル全体の性能説明を、すべての構成要素が今回同時に導入されるという約束として読むことはできない。[3][1][4]
計画を確認済みの事実にする記録
予定日を過ぎたら、確認すべき問いは具体的になる。ネットワークに移行証明書とAlpenglowで確定したブロックが現れたか。実際の負荷の下で、どのような測定結果が出たか。前者は合意方式の変更を、後者は性能を確かめる問いだ。移行設計は前者の証拠を説明し、当初の性能研究は後者の測定と照らし合わせる仮説を示している。[2][4]
現時点で確認できるニュースは、公式のメインネットベータ予告日と公開された引き継ぎ設計である。そこには、高速な合意も曖昧な過去からは始められないという考え方がある。Alpenglowへの移行では、検証者はまず共通の過去を定め、その後の判断をVotorに委ねる。実際の日程と性能が期待に応えるかどうかは、これから生まれる記録で確かめる必要がある。[1][2][3]
続けて読みたいストーリー
同じテーマを、別の事例や背景から考えてみましょう。
出典・参考文献
- [1]出典 1: Anza — Alpenglow launch and migration overviewAnza確認 2026-10-20
- [2]出典 2: SIMD-0384 — Alpenglow migration, repository snapshotSolana Improvement Documents確認 2026-10-20
- [3]出典 3: SIMD-0326 — Alpenglow scope and votingSolana Improvement Documents確認 2026-10-20
- [4]出典 4: Alpenglow: A New Consensus for SolanaAnza · 2025-05-19確認 2026-10-20