LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH-- Cardano & Midnight 総合情報ポータル
SIPO
速報 CardanoがEBlockchain Con 2025に出展、CEO基調講演と金融機関向けパネル 7時間前 速報一覧 →
HOMESignal › Hydra 2.4.1 は、通常のアップグレードではありませんでした——署名の検証を飛ばす最適化が、資金の持ち出しに使えました
Signal

Hydra 2.4.1 は、通常のアップグレードではありませんでした——署名の検証を飛ばす最適化が、資金の持ち出しに使えました

2026-09-11SIPO

Cardano のレイヤー 2「Hydra」のノード実装に重大な脆弱性が見つかり、修正版の 2.4.1 が日本時間 9 月 3 日未明に公開されました。ヘッドに参加している 1 人が、署名の通らない取引を確定済みのスナップショットへ紛れ込ませ、ほかの参加者の資金を持ち出せるという内容で、開発チームはこれを重大 (critical) と分類しています。

IOG の週次開発レポートは 9 月 11 日、この 2.4.1 を「以前の版を使っている人はアップグレードを」という一行で伝えました。SIPO がここを掘り下げるのは、レイヤー 2 が本番の資金を預かる面であり、そこで起きた不具合の質——何を検証していなかったのか、なぜ気づかれなかったのか——が、これから同じ層に載る仕組みすべてに効いてくるからです。週次レポートの一行と、リリースノートおよび脆弱性の告知に書かれていることの間には、はっきりした温度差があります。

以下では、飛ばされていた検証が何だったのか、運用者が自分のノードを上げることにどういう意味があるのか、どの版から上げると手順が増えるのか、そして同じ週に出たほかの成果物を順に見ていきます。

■ 飛ばされていたのは、署名とスクリプトの検証です

Hydra のヘッドでは、参加者が取引をやり取りし、その時点の状態をスナップショットとして全員で署名して確定させます。今回問題になったのは、このスナップショットを確定する処理の内側です。リリースノートは、取り除いた最適化をこう説明しています。

Transactions are now always fully validated, including signature and script checks, when processing a snapshot request.

裏返せば、2.4.0 までは、スナップショットの要求を処理するときに取引を再適用する経路で、署名の検証と Plutus スクリプトの評価が省かれていた、ということです。脆弱性の告知 (GHSA-cg83-6w6r-6hx3) は、その結果として何ができたかを明記しています。悪意のある参加者が、他人の資金を動かす取引を偽の署名つきで作り、スナップショットの要求と一緒に流すと、正直なノードがそれを含んだスナップショットに署名してしまう、というものです。

告知が興味深いのは、原因を 1 点ではなく、3 つの連鎖として書いていることです。検証を通っていない取引が無条件にプールへ入ること。それが検証を飛ばす最適化経路で再適用されること。そして、テストがこの隙間を露出させなかったこと——再適用を完全な検証と同じものとして扱うか、正当な取引だけを使って試すかのどちらかだったため、というのが 3 つ目です。

最適化そのものは、おそらく妥当な判断でした。一度検証した取引をもう一度検証するのは無駄に見えます。前提が崩れたのは、「一度検証した」が実際には成り立っていなかったところです。そしてその前提のずれは、テストの設計が同じ前提の上に立っていたために、テストからは見えませんでした。

■ 自分のノードを上げることが、自分の資金を守ります

運用者にとって実務的に効くのは、リリースノートの次の一文です。

Upgrading your own node to 2.4.1 protects your funds, as confirming a snapshot requires every participant’s signature.

スナップショットの確定には参加者全員の署名が要ります。したがって、自分のノードが 2.4.1 になっていれば、偽の署名を含む取引が混ざったスナップショットには自分のノードが署名しません。ヘッド全体が上がるのを待たなくても、自分の分だけは先に閉じられるということです。

逆に言えば、同じヘッドにいる誰か 1 人が古い版のままでも、その人が損をする構図にはなりません。全員の署名が要る以上、上げていない側が単独で被害を受けるというより、上げた側から順に安全になる形です。上げる判断を他人の都合に合わせる理由がない、という点が、この脆弱性の実務上いちばん大きな含意だと考えます。

■ 2.4.0 からは差し替えるだけ、2.3.0 からは手順が増えます

2.4.1 は、2.4.0 からの差し替えという位置づけです。Hydra のスクリプト、スナップショットの署名、保存される hydra.db の形式のいずれも変わっていないと明記されています。つまり 2.4.0 を動かしているなら、バイナリを入れ替えるだけで済みます。

手順が増えるのは 2.3.0 からの場合です。2.4.0 の時点で互換性のない変更が入っており、開いているヘッドを閉じてからでないと上げられません。データベースは CBOR 形式へ移行し、戻す経路はありません。設定側でも --deposit-period の扱いが変わり、--deposit-activation が追加されています。2.3.0 で運用しているなら、今回のアップグレードは「差し替え」ではなく、ヘッドを一度閉じる計画のある作業になります。

あわせて動作確認されている版は、cardano-node 11.0.1、cardano-cli 11.0.0、mithril 2630.0 です。

なお 2.4.1 自体は 9 月 2 日にはすでに公開されていました。今回の週次レポートは、それを改めて周知した形になります。Hydra まわりでは 9 月の初めに仕様の Agda による形式化も進んでおり(仕様書が、型検査を通るようになりました)、仕様を機械で検査する取り組みと、実装側で検証が飛んでいた今回の件は、同じ月に並んで出てきたことになります。仕様が正しいことと、実装がその仕様どおりに検証していることは、別々に確かめる必要がある——という当たり前を、わかりやすい形で示した並びです。

■ 同じ週に出たもの——Plu-stan の 1.0.0 と、cardano-init のオープンベータ

週次レポートには、ほかにも開発者向けの成果が並んでいます。

  • Plu-stan v1.0.0:Plutus / Plinth 向けの静的解析器の、初の安定版です。9 月 7 日公開。監査の知見にもとづく 7 つの検査 (PLU-STAN-21〜27) が追加され、ハードコードされた資格情報、出力先のアドレス制約の欠落、unstableMakeIsData のコンストラクタ番号の不安定さ、長さを比べない zip といった、実際に事故になってきた型の問題を拾います。上流の研究ルール 23 件と検査の対応表も同梱されました。
  • cardano-init:一つのコマンドで開発環境を用意する CLI の、最初のオープンベータです。IOG の開発者体験イニシアチブの DX.02 という区切りにあたります。
  • Leios プロトタイプ:ダウンロードの判断ロジックの書き直し、取引のキャッシュ、意図しない切断の防止に加えて、メモリプールが台帳の状態をディスクから読む時間に上限が設けられ、ブロック生産の遅延を防ぐようになりました。
  • ouroboros-consensus 4.2.0.0 / 4.2.1.0GetGenesisConfig の問い合わせが静かに失敗する不具合が修正されています。

Plu-stan の安定版と Hydra の件は、別々の話に見えて向きは同じです。どちらも「人間のレビューでは見落とされる種類の誤り」を、機械に拾わせる方向の作業にあたります。片方はスマートコントラクトの書き手に向けて、もう片方はノード実装の側で、検証を省く経路を塞ぐ形で。

■ ここから見ておくもの

2 つあります。1 つ目は、Hydra を本番で使っている面が 2.4.1 へどれだけ早く揃うかです。全員の署名が要る以上、上げること自体は個別に進められますが、ヘッドの参加者がそろって古い版に留まる状況が長く残るなら、それは運用の体制側の話になります。

2 つ目は、今回テストが露出させられなかった型の問題に、開発側がどう手を入れるかです。告知は原因の 3 つ目としてテスト設計を挙げました。再適用の経路を完全な検証と同一視しないテストが入るかどうかは、次のリリースノートで確かめられます。

■ ことば

  • Hydra ヘッド:少数の参加者がメインチェーンの外で取引をやり取りし、結果だけをチェーンに戻す仕組みです。処理を速く安くできる代わりに、参加者どうしの署名が安全性の土台になるため、今回のように署名の検証が飛ぶと被害が直接資金へ届きます。
  • スナップショット:ヘッドの中の「いまの残高」を全員で署名して確定させた記録です。ヘッドを閉じるときはこの記録が根拠になるので、確定の手前でどこまで検証しているかが、そのままヘッドの安全性になります。
  • 静的解析器:プログラムを実行せずに、コードを読んで危険な書き方を指摘する道具です。Plutus のスマートコントラクトは一度デプロイすると直しにくいため、書いている段階で拾えるかどうかが事故の量を左右します。

一次ソース / 関連リンク