この数日で @Dusk の AEGIS セキュリティ分析を読んだが、最初は「39件の修正、7件のcritical」だけを覚えていた。細部を見て初めて、数字が大きいこと自体は本質ではないと気づいた。最後に7つの重大な問題は、4つの根本原因へ収束した。VMサンドボックス内のエイリアス問題、ホスト側の不安全な逆シリアル化、Phoenixの手数料と払い戻しが完全に紐づいていないこと、そしてBLS署名の偽造パスだ。

なぜ根本原因を見るのか？「脆弱性の件数」だけではだめだから。たとえば同じ信頼境界がうまく設計されていないと、別々のモジュールで問題が繰り返し“芽を出す”。入力の検証が行われる前に逆シリアル化をしてしまうケースは、表面的には1回のパース（解釈）エラーに見えても、実際にはホストのメモリ安全性に触れている可能性がある。Phoenix側の一連の問題も「手数料の計算を少し間違えた」類ではなく、証明・署名・払い戻しの実行が同じ語義（セマンティクス）で語られていないことが問題で、最悪の場合、供給の完全性や資金の安全性に直結しうる。

公式には、現時点でこれらのcriticalが修正前に悪用された形跡は見つかっていないと言われている。私はそれを調査結果として受け止めるが、「絶対に起きていない」とはしない。$DUSK にとってのAEGISのポジティブなシグナルは、チームが内部で見つけたことを根本原因と修正ロジックまで含めて公開した点だ。ネガティブなシグナルも同様に明確で、メインネット投入後のコアスタックには、実行・コンセンサス認証・チェーンの利用可能性に影響し得る重大なギャップが実際に存在したことがある。

だから私は「監査が多い」というだけで #dusk に対して安全の“お墨付き”を直接出さない。より有用な観察は次のとおりだ。次のラウンドで継続して開示があるか、同種の境界について回帰テストが行われるか、外部監査がAEGIS後のコードまでカバーできるか。あなたたちは、プロジェクトがこれまで大問題を出してこなかった点をより重視するのか、それとも出した後に、根本原因・影響・修正までの連鎖をきちんと説明できるかを重視するのか？
$USELESS $BOME