LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH-- Cardano & Midnight 総合情報ポータル
SIPO
速報 バルセロナがCardano基盤の「Barça Fan Lab」をローンチ 24時間前 速報一覧 →
HOME › Signal › Midnight ノード 1.0.300、全検証者の更新後にランタイム切替
Signal

Midnight ノード 1.0.300、全検証者の更新後にランタイム切替

2026-09-26SIPO #Midnight

Midnight のノードソフト midnight-node は 9 月 22 日、保守系列の新版 node-1.0.300 を GitHub で公開しました。稼働中のバリデータから鍵素材を含むメモリを覗けた経路を塞ぐ安全対策の版で、オンチェーンのランタイムも入れ替わるため、「全バリデータが新しいバイナリに上がってから切り替える」という順序がリリースノートに明記されています。

9 月 26 日には Sebastien Guillemot 氏が「Midnight Node 1.0.3 just release」と投稿し、これが「最後の主要な技術リリース」だったこと、しばらく様子を見て問題がなければ配備(deployments)を有効にすることを書きました。9 月 19 日の記事で取り上げた「メインネットでスマートコントラクトの配備が近く有効になる」という予告の続きにあたります。何が直り、なぜ切替の順序が決められているのかを、一次のリリースノートから整理します。

1.0.300 で塞がれた 2 つの穴

リリースノートはこの版を「セキュリティパッチ」と位置づけ、Preview・Preprod・メインネット、そして開発用の devnet まで、すべての環境が対象だとしています。

1 つ目は、ノードやツールキットなどのコンテナイメージからデバッガの gdb を取り除いたことです。リリースノートによれば、イメージに gdb が入っていたことで、コンテナへ exec できる人なら誰でも、稼働中のバリデータのメモリを ptrace という仕組みで調べられる状態でした。そのメモリには鍵素材も含まれる、と書かれています。gdb 以外の strace や jq といった日常の調査用ツールは残されました。

2 つ目は、ツールキットのイメージに同梱されていた npm の更新です。npm を 11.11.0 から 11.18.0 に上げることで、その中の tar ライブラリにあった深刻度 critical の脆弱性 GHSA-23hp-3jrh-7fpw が解消されました(tar 7.5.9 が該当・7.5.19 で修正)。こちらはノード本体ではなく、チェーンの履歴を再生したり操作したりするためのツールキット側の話です。

なお、リリースノートはどちらについても、実際に悪用されたかどうかには触れていません。

切替の順序:先に全員が更新、そのあと set_code

この版は「patch」と分類されていますが、リリースノート自身が、中身はパッチの形をしていないと断っています。ノードのバイナリに加えて、チェーン上で動くランタイム(WASM)も入れ替わるからです。ランタイムの spec_version は 1000000 から 1000300 に上がり、切替は set_code というガバナンス操作で、ネットワークごとに 1 回ずつ実行されます。

順序が決められている理由は、新しいランタイムが呼び出す関数にあります。新ランタイムは、古いバイナリには存在しないホスト関数(ノード側が用意する関数)を読み込みます。そのため、古いバイナリのまま残ったバリデータは、set_code が実行されたブロックから先のブロックを取り込めなくなり、チェーンから脱落します。

リリースノートが示す手順は 5 段階です。

  • 配布されたランタイムの WASM を、同じリリースのハッシュ値と照合する(再現可能なビルドなので、作り直せば同じ値になる)
  • 全バリデータを 1.0.300 のバイナリへ順番に再起動しながら入れ替える
  • 古いバイナリのまま残っているバリデータが 1 台もないことを確かめる
  • set_code で新しいランタイムを有効にする
  • ノードが spec_version 1000300 を返すことを確かめる

新しいバイナリは古いランタイムのままでもブロックを取り込み続けられるので、2 番目と 4 番目の間を急ぐ必要はない、とも書かれています。逆に、全員の更新が終わる前に 4 番目を実行すると、残っていたバリデータがすべて取り残されます。「この順序は助言ではない」という強い書き方になっているのはそのためです。Preview・Preprod・メインネットは状態を消さずにそのまま更新でき、ジェネシスの作り直しとリセットが必要なのは devnet だけです。

過去ブロックの扱いを、ノードごとの設定から切り離す

地味ですが、合意の安全性にかかわる修正も入っています。

一部の過去ブロックでは、ブロックを作ったノードのキャッシュにあった取引が、あとから検証し直すと食い違う問題がありました。これを補うための補正(リリースノートでは tblock の補正)は、これまで補正の幅と打ち切りの日付をノードの設定ファイルから読んでいました。設定の違うバリデータは、同じ過去ブロックを仲間とは違う結果で検証しうる、ということです。補正がすべての過去取引にかかってしまい Preview がブロック #128536 で止まった不具合も、この版の修正一覧に挙がっています。

1.0.300 では、補正の幅を 12 秒に固定し、補正をかけるかどうかはチェーン上のランタイムが決める形に変わりました。どのノードも、同じ高さのブロックを同じように再生できます。運用者の側から見ると、1.0.2 から上げる際に足したり消したりする設定項目はない、とされています。

2.1.0 系列へ進むための足場

1.0.300 には、次の系列への入口という役割もあります。並行して進んでいる新しい系列 2.1.0 の候補版 rc.2(9 月 17 日公開)のリリースノートは、2.1.0 へ移る方法を「1.0.300 のチェーンからのハードフォーク」と定めています。それ以前の版は移行の起点として「1.0.3」という名前を挙げていましたが、rc.2 はそれを 1.0.300 に置き換え、両者がチェーンの外に見せる機能の一覧(メタデータ)は同一だと説明しています。

Guillemot 氏の投稿にある「1.0.3」と、GitHub のタグ node-1.0.300 が同じリリースを指すかどうかは、一次の資料には明記されていません。ただ、1.0.x 系列で 9 月 22 日以降に出た版は 1.0.300 だけで、投稿の「最後の主要な技術リリース」という位置づけも、2.1.0 への足場という説明と矛盾しません。GitHub 上の 1.0.300 には、執筆時点で pre-release の表示が付いたままです。

配備の有効化は、投稿の中でも「様子を見て、問題がなければ」という条件つきの予定として書かれています。9 月 19 日の予告から 1 週間で、その前提となるノードの版が出そろった、というのが今回の位置です。

次に見るもの

  • GitHub の node-1.0.300 リリースページ — Guillemot 氏の言う様子見の期間中に、pre-release の表示が外れるかどうか
  • Midnight 公式ドキュメントのリリースノート概要ページ — 最終更新は 9 月 23 日で、現時点では 1.0.300 の記載がありません。環境ごとの適用状況がここに載るかを見ます
  • Guillemot 氏と @midnightfdn の X 投稿 — 様子見の期間が終わり、メインネットでの配備が有効になった、という告知が出るかどうか

ことば

  • set_code — チェーン上で動くランタイム(WASM)を丸ごと差し替えるガバナンス操作です。ノードを止めずにルールを更新できる反面、新しいランタイムを動かせないノードはその時点で脱落するため、今回のように順序が問題になります。
  • spec_version — ランタイムの版を表す番号です。今回は 1000300 に上がり、ノードがこの値を返すことが、切替が完了したことの確認になります。2.1.0 系列はさらに別の番号を持ちます。
  • gdb と ptrace — gdb は動いているプログラムの中身を調べるデバッガ、ptrace はそれを可能にする OS の仕組みです。開発では便利ですが、本番のバリデータに入っていると、鍵を扱うメモリへの入口になります。

一次ソース / 関連リンク

タグ: #Midnight