不快な事実は、快適な事実よりも役に立つ。そこで、Dusk Networkについての不快な事実をひとつ挙げる。2026年初頭に行われた内部監査では、その本番コードベース内に39件の問題が見つかり、そのうち7件は重大だった。メインネットがすでに実際の価値を処理し始めてから1年以上経過している。

これらの重大な指摘の背後にある4つの根本原因は、わかりやすく名指ししておく価値がある。取り繕って済ませるべきではない。2件は、仮想マシンサンドボックスであるPiecrustにおける不健全なメモリ所有（ownership）に起因しており、誠実な2つのノードが同一のコードを実行しても、静かに異なる結果を計算してしまえる可能性があった。この欠陥カテゴリはクラッシュよりも深刻だ。なぜなら、見えないまま残り得るからだ。もう1件は、ホスト側のデシリアライズ経路が、最初に検証せずにコントラクトが制御するバイト列を信頼してしまうことに起因していた。これにより、コントラクトレベルのバグがノードの完全性（integrity）問題へと転化した。さらにもう1件は、秘匿トランザクションモデルであるPhoenixが手数料と払い戻し（refund）のロジックを結びつける方法にあったギャップであり、それ単独でも、供給のインフレ、チェーンの停止、そして払い戻しの付け替え（リダイレクト）への道を同時に開いてしまう性質のものだった。最後は、コンセンサス認証そのものの下にあるBLS署名方式における暗号構成上の弱点だった。過去の悪用を調べるには、トランザクション履歴のうち1つのバグパターンを確認するだけでは足りず、スタック全体にわたってログとホストレベルの証拠を突き合わせる必要があった。

Duskは、自社の調査で、2026年3月のハードフォークとして修正が出荷される前に、7件のいずれも悪用されていなかった証拠は見つからなかったとしている。私はこの主張を独立に確認する手段がなく、ここを読んでいる誰にも同様の手段はない。それでも、NPEXだけでこのコードベースに3億ユーロ超を移す計画があることを考えると、正しくやり切ることの重要性が小さかったはずはない。私が受け取るのは、純粋な安心以上に、より複雑な評価だ。この問題を悪用前に見つけることは、確かに良い仕事だ。しかし同時に、そのように重大な影響を持つコードが、誰も見つけられなかった欠陥を抱えたまま、1年以上本番環境で動いていたということも意味する。単発の監査はマイルストーンだ。継続的な保証とは同じではない。

@Dusk $DUSK #dusk