今夜把ノードのログを一通り吐き出してスキャンしていたら、ふと先週、監査をやっている友人と揉めた件を思い出した。

大穴の話（※ムード的な下落）は少しあったけど、BTCの上昇トレンドは変わらない！

彼が言ったんだ。「あなたたちはDuskを回してるけど、本当に検証ロジックをWASMの外に投げて安心なの？」そのときは受け止めきれなかった。強がって『ホワイトペーパーに監査が書いてある』って言ったけど、内心は正直かなり怪しく思っていた。

それで今夜、彼らのGitHubでPiecrustのhost function一式のテストケースを見たら、ようやく少し筋が見えてきた。

つまりね、従来の「全部をロックしたサンドボックス」方式って、たとえばコンビニでタバコを買うのに、まずは検問ゲートを通って、身分証を確認して、かばんの中まで調べて、最後にやっと会計してもらえる――そんな感じだ。安全は安全だけど、後ろに並ぶ人は文句を言いたくなる。

Duskは別の道を賭けている。高頻度の動きは専用の通路を通し、低頻度の動きだけがゲートを通る。

さらに、彼らが引いているサードパーティのデータは原文をわざわざ調べた。あの論文が測っていたのは、命令セットの違いによって、WASMがネイティブに比べてどれだけ性能損失が出るか。最も極端な暗号化シナリオでは、オーバーヘッドが255%まで跳ね上がる。

想像してみて。Duskは毎日どれくらいの取引がBLSの署名検証を通り、どれくらいがZKの証明を通るのか。もし毎回WASMに解釈させるなら、1キロ走るたびに油代を2.5キロ分余計に払っているのと同じ。誰がそんな負担を抱えられる？

だから彼らは、これらをシステムコールのレベルに落として、ネイティブ実装を直接呼び出すようにした。

その代償は何か？　信頼の半径が「WASMサンドボックスという鉄の箱」から、「ホスト関数の数行のCコードがちゃんと動いているか」にまで縮まることだ。これらのリスクは同じ次元ではない。前者は物理的な隔離、後者はコード品質の問題。

彼らの2024年Q3の監査レポートも調べた（公式サイトのどこかに深く埋まっている）。少なくとも当時測っていた境界テストケースでは破綻は出ていなかった。けれど正直に言うと、この種の攻撃面は「測って出てくる」ものではなく、「使って初めて効いてくる」ものだ。いつか誰かが細工した証明データを投入して、host functionの中で誰も気づいていなかった整数オーバーフローを踏んだとしたら……想像したくない。

ただ、逆に言えば、「絶対安全」を本気で追い求めるならパブリックチェーンはやめて、家に帰ってシングル端末のプログラムを書いた方が一番堅い。Duskの人たちが賭けているのはこういうことだ。性能のボトルネックが先にあなたを止め、そのあとの安全問題はまだ補える。

@Dusk $DUSK #dusk