Cabinet
テクノロジーインサイト一覧へ戻る
2026.09.22

【続報】Solana Alpenglow がテストネットとデブネットで稼働、「9月28日」はメインネット有効化日ではなかった：commitment の統合と投票トランザクションの消滅に備える

【続報】Solana Alpenglow がテストネットとデブネットで稼働、「9月28日」はメインネット有効化日ではなかった：commitment の統合と投票トランザクションの消滅に備える

何が起きたか

Anza は9月22日、Alpenglow の有効化をテストネットで開始すると告知した。Triton One は前日に公開したデータ利用者向けガイドで、機能ゲートを SIMD-0326、有効化エポックを1042と特定している。移行は5,000スロット（約17分）のカウントダウン方式で行われた。Anza の報告では、9月24日 18:12 UTC、ステークの82%が最後の TowerBFT ブロックを確認したうえで、スロット444625255で Alpenglow の起点ブロックが生成された。デブネットでは25日にエポック1167で機能ゲートが有効になり、20:01 UTC にスロット504148999での移行完了が確認された。テストネットからデブネットまでの間隔は約26時間である。

Anza は「Devnet is next. Mainnet-beta after our observation period」と述べるにとどめ、メインネットの日付を示していない。一方、8月12日公開の Agave v4.3 リリーススケジュールでは、メインネットの「Resume feature activation」が9月28日とされていた。当シリーズの9月4日付記事も含め、この日付は Alpenglow のメインネット有効化日と受け取られてきた。しかし実際には、キューに積まれた機能ゲートの処理を再開する日付であり、Alpenglow を名指ししたものではなかったと考えられる。9月22日に公開された Agave v4.4 のスケジュールも、メインネットの機能有効化再開を11月9日としているが、Alpenglow には触れていない。

クライアント面では、テストネットの移行に参加できたのは Agave 4.3 だけだった。Anza は Firedancer と Frankendancer が Alpenglow への移行に対応していないことを明言し、テストネットでそれらを動かすノードに Agave v4.3.0 への切り替えを求めた。

何が変わるのか：投票がブロックから消える

Alpenglow の第1段階は、TowerBFT を Votor に置き換える。TowerBFT では、バリデータの投票がトランザクションとしてブロックに書き込まれ、32スロット分の投票が積み上がって確定に至っていた。Votor では、バリデータが投票を直接交換して証明書にまとめ、1〜2回のラウンドで確定する。Solana Foundation の移行ガイドは、確定までの時間を TowerBFT の約12.8秒から約150ミリ秒へ縮めることを目標としている。

なぜこの設計でなければならなかったのか。理由は確定時間だけではない。Solana Compass の解説によれば、Votor はステークの80%による1ラウンドの高速経路と、60%による2ラウンドの経路を併用する。共同創業者の Anatoly Yakovenko 氏は、ステークの40%が落ちても耐えられると述べている。現在の TowerBFT は、ステークの3分の1超が停止すると確定が止まる。8月12日には、ホスティング事業者 Teraswitch の経路障害でステークの28.83%がオフラインになり、その閾値まで4.5ポイントに迫った。インフラの集中による停止リスクに対して耐性を広げることも、Alpenglow の設計目的の一つと読める。

この設計変更は実行層にはほぼ影響しない。移行ガイドは「Alpenglow changes consensus, not execution」とし、SVM、トランザクション形式、手数料の仕組みは変わらないと明記している。影響を受けるのは、その周辺でチェーンを読むシステムである。

第一に、commitment が統合される。ガイドは「confirmed and finalized become the same thing」と述べ、新しいコードは finalized を指定するよう求めている。confirmed は将来のリリースで非推奨化・削除される予定である。

第二に、投票がブロックから消える。Solana Compass の集計では、9月18日から24日のメインネットで、投票は日次トランザクションの54〜59%を占めていた。24日は投票2億1,710万件、非投票1億6,880万件で、比率は約56%である。メインネットで移行が起きれば、利用が変わらなくても、投票込みで数えた TPS やトランザクション数は半分程度に落ちる。

第三に、1つのスロットに複数の候補ブロックが載りうる。ガイドはストリーミングや Geyser の利用者に、バッファのキーをスロット単体ではなく (slot, bank_id) にするよう求めている。PoH のティックはシュレッドストリームから消え、Clock のタイムスタンプは投票のステーク加重中央値ではなく、リーダーが一定範囲内で直接設定する方式に変わる。どちらの方式が動いているかは、getAgGenesisCert RPC（TowerBFT 下では null を返す）で判別できる。Triton One によれば、投票アカウントには BLS 公開鍵が加わり、getAccountInfo の jsonParsed で読み取れる。

想定される落とし穴

最大の落とし穴は、ダッシュボードと監視の閾値である。投票込みの TPS やトランザクション数を基準にしたアラートは、メインネット移行の瞬間に「半減」を検知して誤報を出す。事業指標として取引件数を報告している組織では、この減少が利用減と誤読されるおそれがある。デブネットはすでに新しい数え方で動いているため、集計定義の修正はそこで先に検証できる。

次に、confirmed を前提にした待機ロジックである。confirmed で入金を反映し、finalized で出金を許可するといった二段階の設計は、移行後は二つの状態が同一になり意味を失う。移行前後では同じコードの挙動が変わるため、両方の状態でテストしておく必要がある。

三つ目は、Firedancer 系クライアントを使う運用者の計画である。テストネットでは Agave への切り替えが必須だった。Votor に対応した Firedancer のビルドが開発中かどうかは公表されていない。メインネットでも同じ制約が課されれば、クライアント多様性の観点で一時的な後退となる。ただし、メインネットの条件はまだ示されていない。

四つ目は、切り替えのタイミングを日付で判定するコードである。メインネットの日付が未定である以上、「ある日時以降は新方式」と書いたコードは確実に誤る。移行はエポック境界の機能ゲートと、5,000スロットのカウントダウンで起きる。移行ガイドが示すとおり、getAgGenesisCert の戻り値（TowerBFT 下では null）で稼働中の方式を判定し、それに応じて処理を切り替える実装にしておけば、日程の変動に左右されない。

【技術インサイトとアクション】

  1. 公開されたリリーススケジュールの日付は、どの機能の、どの段階の日付なのかを原文で確認しない限り、計画の根拠にならない。今回は「機能有効化の再開日」が、業界全体で「Alpenglow のメインネット日」と読み替えられていた。 ［プロダクト側・ノード運用者］ 今週中に、社内の移行計画にある Solana 関連の日付を Anza の一次告知と突き合わせ、Alpenglow のメインネット日は「未定・観測期間後」として計画を更新する。
  2. コンセンサスの設計変更は実行層を変えなくても、観測データの定義を変える。投票トランザクションを含む指標は、コンセンサス方式の実装詳細に依存していた。 ［インテグレーター・データ基盤担当］ メインネット移行前に、TPS・トランザクション数・アラート閾値を非投票トランザクション基準に定義し直し、デブネットで新旧の数値を並べて検証する。
  3. 「1スロット＝1ブロック」という暗黙の前提が崩れる。スロット番号をキーにした重複排除やバッファは、候補ブロックが複数あると取り違えを起こす。 ［インテグレーター］ 観測期間中に、Geyser・gRPC の利用コードでキーを (slot, bank_id) に改め、commitment 指定を finalized に統一したうえで、デブネットで回帰テストを行う。

【引用：出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。

前の記事Meter で「ブロック検証の欠陥」から担保なしの MTR／MTRG が発行され、Passport ブリッジ経由で BNB Chain に流出：ブリッジの安全性は送金元チェーンの検証を超えられない次の記事 Avalanche Helicon がメインネットで有効化：C-Chain の「受理」と「実行」が分離し、latest はもはやファイナリティを意味しない