プルーフ・オブ・ワークという喩えは誤っている。ハッシュ衝突の探索は、Nが大きくなるほど指数関数的に難しくなるとはいえ、十分な計算量をかければ H(S) が N を満たすような S が必ず見つかる。だからこそ、投入されるリソースに非対称があれば、「ワーク能力」の高い側が最終的には勝つことになる。

しかし、バグは違う。

1. LLMの実行ごとに異なる分岐をたどるとしても、コードが取りうる状態に基づく分岐の可能性はいずれ飽和する。
2. あるコードについてモデルにバグ探しをM回サンプリングさせると想定してみる。Mが十分に大きくなれば、上限は「M」ではなくなる（コードの状態とLLMサンプラーの有意味なパスの双方が飽和するため）。上限となるのはモデル自体の知能レベルである「I」だ。

OpenBSDのSACKバグがそれを端的に示している。性能の劣るモデルを無限のトークンで走らせても、決して気づくことはない（*）。ウィンドウの開始位置の検証欠如と、整数オーバーフロー、そして本来ノードが決してNULLにならないはずの分岐にそれでも入ってしまうという事実——これらが組み合わさって初めてバグが生じるということにだ。

だから、明日のサイバーセキュリティは「より多くのGPUを積んだ方が勝つ」という意味でのプルーフ・オブ・ワークのようにはならない。勝つのは、より優れたモデルと、そのモデルへのより高速なアクセスを持つ側だ。

* 弱いモデルでもOpenBSDのSACKバグを見つけられると言う人を信じてはいけない。自分でも試してみた。実際に起きるのは、弱いモデルがハルシネーションを起こし（たまたま実際の問題に偶然当たることもある）、ウィンドウの開始位置の検証欠如（理論上は start < end の検証があるため本来は無害なはずのもの）や整数オーバーフローの問題があると指摘するものの、なぜそれらが組み合わさると問題になるのかを理解していないというケースだ。問題がありそうに見えるコードに対してバグの類型をパターンマッチしているだけで、問題を真に理解しエクスプロイトを書く能力はまったく欠けている。自分でも試してみてほしい。GPT 120B OSSは安価で入手可能だ。

ちなみに、だからこそこのバグでは、（それでも真のバグを発見するには不十分な）より強力なモデルを選べば選ぶほど、バグがあると主張する可能性は低くなる。強力なモデルほどハルシネーションが少ないため、スペクトルのどちらの側からも問題を見ることができないのだ。すなわち、小さなモデルのハルシネーション側からも、Mythosの真の理解側からも。