LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH-- Cardano & Midnight 総合情報ポータル
SIPO
速報 Midnight メインネットでパーミッションレス・スマートコントラクト展開が開始 7時間前 速報一覧 →
HOME › Deep Dive › 🔬 Deep Dive|Midnightの再リリースをハッシュから読む
Deep Dive

🔬 Deep Dive|Midnightの再リリースをハッシュから読む

Midnight node 1.0.300のリリースページに、9月30日の再発行を説明する注記が加わりました。Cargo.lockを調整し、チェーン上のランタイムと同じハッシュを再現するためだと開発側は説明しています。確認した配布物と検証記録は一致しましたが、ページ本文には旧値も残ります。更新判断では、配布物、ビルド、チェーン、接続先の証拠をそれぞれ読む必要があります。

同じ版番号でも配布の時点が違います

今回の対象は、midnight-nodeリポジトリのnode-1.0.300です。10月1日に公開情報を確認したところ、GitHubのリリース情報には公開日時として9月22日が残り、現在の配布ファイルには9月30日の作成日時が記録されていました。版番号や最初の公開日だけでは、どの配布物を見ているかを特定できません。

ページの冒頭は、Cargo.lockの更新を含む再発行で、ランタイムのハッシュをチェーン上と一致させるためだと説明しています。リンク先の修正コミットは、9月30日UTCの01fa20aです。現在のタグが指すコミットはc3895bdでした。本文中の説明、タグ、配布ファイルは、それぞれ確認する対象になります。

ノードの実行ファイルとランタイムも別です。ノードは通信や同期などを行い、ランタイムはチェーンが状態を変える規則を担います。同じリリースに含まれていても、ノードを入れ替えることと、チェーン上のランタイムを変更することは同じ操作ではありません。

そのため、再発行を見ただけで、侵害、チェーンの事故、既存の残高への影響を断定する根拠にはできません。同時に「同じ1.0.300だから同じファイル」と扱うこともできません。配布物の名前、取得日時、サイズ、ハッシュを組み合わせると、後で照合する足場ができます。

依存関係の差がWASMの差になったという説明

修正コミットに追加された変更記録によると、ledger 8.1.2への更新で広い範囲のcargo updateが行われ、ランタイムの依存関係にあるrandとlibcも更新されました。開発側は、ランタイムのソース自体が変わらなくても、クレートの版が変わることでシンボルのハッシュが変わり、チェーン上に導入済みのWASMとは異なる生成物になったと説明しています。

Cargo.lockの差分では、randを0.10.2から0.10.0へ、libcを0.2.189から0.2.184へ戻し、atomic-write-fileも0.3.0へ固定しています。これは、同じソースから同じ生成物を得るために、依存関係の解決結果もそろえる必要があることを示す具体例です。

ここで確認できたのは、公開された差分と開発側の説明です。本稿では、その環境を用意してビルドを再現していません。説明された原因が、独立したビルドで同じ結果になることまで実証したわけではありません。

変更には、randのセキュリティ勧告RUSTSEC-2026-0097をdeny.tomlで例外扱いする記載もあります。開発側は、該当するlog機能をワークスペース内で有効にしていないため到達しないと説明しています。この記載は、例外の理由を調べる入口です。ハッシュが一致したことから、依存関係に関する評価や、あらゆる脆弱性の不在まで証明されるわけではありません。

再現性のために何を固定し、その固定についてどんな評価を残すか。更新の説明を読む際には、両方が必要になります。

配布物と本文のハッシュを分けて照合しました

10月1日11時48分UTC、公開された圧縮ランタイムWASMをデータとして取得し、実行せずにSHA-256とBLAKE2b-256を計算しました。対象はmidnight_node_runtime-1.0.300.compact.compressed.wasmで、サイズは538,425バイトでした。

現在の配布物のSHA-256は次の値です。

2fab542c4b6b944191929a573e07528b5c593739591dd186d8781cd785c32e64

BLAKE2b-256は次の値です。

39568eeb0802fa59d74ac0bc5c7ab62fc05c23ea947937458a4b011558516138

SHA-256は、同時に配布されているSHA256SUMSの該当ファイル行、GitHubが公開するアセットのdigest、srtool-digest.jsonの圧縮WASMの値と一致しました。BLAKE2b-256もsrtoolの記録と一致しています。少なくとも、この取得時点で受け取ったファイルと、配布側が提示した現在の照合値は整合しています。

一方、リリース本文のランタイム情報には、サイズ538,767バイトと、SHA-256の先頭が21b3ea7eで始まる別の値が残っていました。本文に記載されたBLAKE2の先頭もc137030dで、現在の配布物とは異なります。再発行後のアセットと、本文中の古い生成記録を取り違えると、照合が失敗した理由を誤読します。

この不一致から言えるのは、現在の配布物と本文中の記録がそろっていないということです。それだけで悪意ある差し替えとは判定できません。逆に、現在の配布物が現在のマニフェストと一致することだけで、その配布経路から独立した真正性まで確定することもできません。同じ場所から届いたファイルと照合値は、同じ配布者の情報だからです。

本文に残る旧ランタイムや提案用のハッシュを、そのまま更新操作へ転用しないことが大切です。本稿のハッシュは取得した配布物を特定する記録であり、チェーンを書き換える指示ではありません。

ビルドの一致とチェーン上の一致は別の段階です

配布されたsrtool-digest.jsonには、Rustやsrtoolの版、ランタイムの版、生成物のハッシュなどが記載されています。圧縮WASMのspecVersionは1000300でした。ただし、ソースの取得方法はzipと記され、commit、tag、branchの欄は空です。ビルド情報が存在することと、検証者が固定コミットから同じ生成物を再現できたことは分けて読む必要があります。

独立した再現ビルドでは、対象コミット、依存関係、コンパイラー、ビルド環境を固定し、出力を配布物と比較します。その一致は、指定した条件で生成物を再現できた証拠になります。それでも、コードの安全性をすべて証明するものではありません。

さらにチェーン上との比較には、対象ネットワークと確定したブロックを特定し、その時点のランタイムコードを対応する方式で照合する段階があります。mainnet、preprod、previewを混同せず、圧縮WASMのファイルに対するハッシュと、照合対象のコードが同じ表現なのかも確認が必要です。

開発側の変更記録は、現在のBLAKE2値が3ネットワークの導入済みランタイムと一致すると説明しています。本稿では本番RPCへ接続していないため、この部分は開発側の公表に基づく記述です。配布物の計算結果との一致は独自に確認しましたが、チェーン上の状態を独立に確かめたとは表現しません。

証拠は、取得したバイト列、再現したビルド、特定ブロックの状態へと段階を増やせます。どこまで確かめたかを添えることで、同じ「一致した」という言葉の射程が明確になります。

接続先の移行を更新判断と混ぜない

もうひとつ、同じ9月30日前後に接続先の変更があります。Midnightの公式ネットワーク文書は、9月30日22時UTCにMidnight提供のmainnet RPCとindexerのエンドポイントを終了し、Blockfrostの提供先へ移行すると説明しています。日本時間では10月1日7時に当たります。

新しい提供先では、各リクエストにネットワークごとのプロジェクトトークンが必要です。接続できない場合、旧URLの終了、認証条件、対象ネットワークの違いなどを切り分ける余地があります。匿名の読み取りができないことだけから、チェーン自体が停止したと判断することはできません。

この提供先の移行と、ランタイムの再現性を整える再発行は、確認する対象が異なります。今回読んだ公表資料から、片方がもう片方の原因だという関係は確認できません。リリースの日付と接続障害の時刻が近いだけで、ひとつの事故として結び付けないことが必要です。

利用者の更新判断では、利用中のネットワーク、ノード・SDK・indexerの組み合わせ、現在の接続先、配布物の照合結果を順に整理できます。運営者の管理下で行う再現ビルドやチェーン上の確認が必要な場合も、その結果がそろう前に「安全性を確認済み」とは扱わない方が判断の範囲を保てます。

次に見る具体的な一点は、node-1.0.300の本文と現在の配布ハッシュがそろうか、修正コミットに対応した再現ビルド記録が公開されるかです。更新の必要性を一律に決めるより、同じ版番号の何を入れ替えるのか、何と照合したのかが説明できることが、今回の再発行を読む基準になります。

ことば

ランタイム:チェーンの状態を変える処理を担うコード。ノードの実行ファイルの更新とは区別します。

再現ビルド:固定したソースと環境から、同じ生成物を得られるかを確かめること。安全性全般の証明ではありません。

ハッシュ:バイト列から計算する照合値。方式と対象が同じであることを確認して比較します。

🔗 一次ソース