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

Solana、Alpenglow の feature activation を9月28日に設定——Firedancer は移行ウィンドウ非対応、運用者は一時的な Agave 切り替えが必要

Solana、Alpenglow の feature activation を9月28日に設定——Firedancer は移行ウィンドウ非対応、運用者は一時的な Agave 切り替えが必要

何が起きたか

Anza がバリデータクライアントのWikiで維持している Agave v4.3 のリリーススケジュールに、mainnet-beta の行として「Begin feature activation」と目標日 2026-09-28 が記載されている。この表は放置された文書ではなく、完了済みの行に実際の実施日が入っている。v4.3 のブランチ作成は2026年8月11日、testnet への推奨リリース化は8月17日、testnet の feature activation 完了は8月19日、devnet は8月24日である。目標日より早く着地している行があることが、この表が更新され続けている根拠になっている。

もう一点、Solana Foundation の Agave 4.2 リリース概要には、Alpenglow は 4.2 では活性化されず 4.3 で活性化予定であり、その 4.3 は「2026年10月を目標」と書かれている。2つの文書を突き合わせて初めて「v4.3 が Alpenglow を含み、その feature activation は9月28日に始まる」という文になる。片方だけを読むと、日付だけがあって主語がない状態か、主語だけがあって日付がない状態になる。ここは記事や集計サイトで取り違えが起きやすい箇所である。

なお feature activation は「その日にネットワークが切り替わる」ことを意味しない。Solana の feature gate は、対象バージョンを走らせるステークが規定割合に達したエポック境界で有効化される仕組みであり、9月28日は開始点であって完了点ではない。「9月28日にAlpenglowが動く」と書くのは誤りである。

移行手順のほうが仕様より効く

Alpenglow 本体の設計（投票を担う Votor と伝播を担う Rotor による Tower BFT / PoH の置換、目標ファイナリティ約150ミリ秒）は、SIMD-0384 の移行提案を含めて既に公開されている。実務で効くのは、稼働中のネットワークをどう切り替えるかという「Alpenswitch」の部分である。

バリデータのコミュニティ議論の要約（Chainflow によるまとめ、2026年8月21日〜28日）によれば、Firedancer は Alpenglow 自体には初日から対応する見込みである一方、稼働中の短い移行ウィンドウには対応しない方針が示されている。運用者はその期間だけ Agave へ切り替え、移行完了後に Firedancer へ戻すことが想定されている。期間は数千スロット程度とされ、400ミリ秒スロット換算で2,000スロットなら約13分、5,000スロットなら約33分にあたる。移行とAlpenglowの双方を支えるには追加の実装・監査・セキュリティ作業が必要で、Firedancer チームはその工数をフルクライアント側に振り向けたい、というのが理由として説明されている。あわせて、ハイブリッド版の Frankendancer は Alpenglow 活性化のタイミングで退役することが確定した。前週まで未確定だった論点である。

もう一つ、事前作業として BLS 公開鍵の登録がある。Votor は参加する各バリデータがオンチェーンの投票アカウントに BLS 公開鍵を登録していることを要求する。登録は SIMD-0387 として Agave 4.1 のリリースサイクル以降メインネットで有効になっており、Solana CLI v4.1.0 以降が必要とされる。未登録の投票アカウントは、移行完了後にコンセンサスへ参加できない。

この移行手順の重さは、Solana のクライアント構成の変化を反映している。かつては Agave 系の単一実装がほぼすべてを占めていたが、2025年12月に Firedancer がメインネットで本稼働し、2026年半ばの時点でステークのおよそ14%が Firedancer、26%がハイブリッド版の Frankendancer で動いていると報告されている。クライアントが増えるとネットワーク全体の耐障害性は上がるが、フォークや移行のたびに「どのクライアントがどの段階を実装しているか」を運用者が把握しなければならなくなる。今回の Firedancer の判断は、クライアント多様性が運用手順の多様性でもあることを示す最初の大きな例になると考えられる。

資源要件も動いている。Firedancer のメインネットにおけるメモリ割り当ては約280GBまで下がり、さらなる削減が予定されている。9月のテストネット向けリリースでは128GB未満（128GBのテストネット機で動かせる水準）を目標とし、メインネットは200GB近辺へ寄せる想定とされる。リリースの刻みは年月方式の月次サイクルが定着しており、26.08 がメインネットに到達し、次が 26.09 である。移行のリハーサルを組む際は、この月次リリースのどのバージョンで検証したかを記録に残しておかないと、当日の構成と食い違う。

スロット時間の短縮も並行して進む。400ミリ秒から350ミリ秒への初回短縮では、シュレッド伝播・リプレイ・実行・投票遅延のいずれにも目立った問題が出ておらず、次の300ミリ秒はエポック1024で有効になる予定とされている。エポックは432,000スロット固定なので、実時間の長さは400ミリ秒で48時間、350ミリ秒で42時間、300ミリ秒で36時間と縮む。ブロックハッシュの有効期間（150スロット）も60秒から52.5秒、45秒へと短くなる。

想定される落とし穴

第一に、日付が3つある。9月21日はメインネット向けリリースの目標日として議論に出ていた日、9月28日は feature activation の開始日、そして Foundation 文書の「10月」は活性化の想定時期である。社内共有の際にこれらを1つに丸めると、猶予の見積もりを誤る。

第二に、Firedancer 運用者にとっての作業は「アップグレード」ではなく「別クライアントへの一時退避と復帰」である。バイナリ更新の手順書しか用意していない現場は、当日ぶっつけで Agave の起動・スナップショット・鍵配置を行うことになる。事前のリハーサルが必要な種類の作業である。

第三に、BLS 鍵の登録漏れは、当日ではなく移行完了後に「コンセンサスに入れない」という形で表面化する。監視が投票の有無ではなくプロセスの死活だけを見ている構成では、検知が遅れる。

第四に、これらの移行手順に関する記述の主たる出典はバリデータ討議の第三者要約であり、Anza の正式なランブックではない。運用計画を確定させる前に、公式リリースノートと SIMD-0384 の最新版で裏を取るべきである。

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

  1. 大きなコンセンサス変更において、最も事故が起きるのは新方式そのものではなく、旧方式から新方式へ渡る短い窓である。マルチクライアント環境では「移行ウィンドウを実装するか」がクライアントごとの判断になり、クライアント選択がそのまま当日の作業手順の違いになる。 ［ノード運用者］ 9月28日の2週間前までに、Firedancer から Agave への一時切り替えと復帰をテストネットで通しでリハーサルし、所要時間と失敗時の戻し手順を記録する。
  2. 「有効化日」は多くのプロトコルで開始点であり、切り替え完了点ではない。ステーク比率に依存する feature gate では、いつ挙動が変わるかは自分たちだけでは決められない。 ［インテグレーター・プロダクト側］ 9月28日以降、活性化状況をエポック単位で監視し、ファイナリティ前提の処理（入出金の確定判定、ブリッジの確認回数）を切り替え前後で二重に検証できる状態にしておく。
  3. 前提条件の登録漏れは、障害としてではなく「静かな不参加」として現れる。死活監視だけでは捕捉できず、報酬や参加率の低下として後から気づくことになる。 ［ノード運用者］ 今週中に全投票アカウントの BLS 公開鍵登録状況を棚卸しし、未登録があれば Solana CLI v4.1.0 以降で登録したうえで、投票参加率をアラート対象に追加する。

【引用：出典】

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