プルーフ・オブ・ワークという喩えは間違っています。ハッシュ衝突の探索は、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のような真の理解側でもです。