#dusk $DUSK @Dusk
回路の性能をベンチマークするためにローカルで証明生成を実行していたところ、マーケティングページではなく暗号化チーム自身の技術文書を読み返したくなるような点に気づきました。
PLONKの実際の数値が、プライバシー面だけでなくコンプライアンスの主張（コンプライアンス事例）の成立を支えているのです。検証時間は回路サイズにかかわらずおおむね6〜9ミリ秒のままです。一方で証明時間は回路の複雑さに応じてスケールします（たとえば、控えめなハードウェアで2^16ゲートの回路なら約5.46秒）。しかし、検証側は速く、しかも一定です。この非対称性は、規制のかかった金融の文脈では、人々が思っている以上に重要です。監査人や取引相手が毎回、証明の確認に意味のある計算リソースを浪費することなくチェックできるからです。基盤となる取引ロジックがより複雑になっていっても、その点は変わりません。
私が想定していなかったのは、PLONKそれ自体に「実際に開示された脆弱性」があることでした。単なる理論上のリスクではなく、Duskの研究チームが、Fiat-Shamir変換の実装方法における重大な問題を見つけたのです。Fiat-Shamir変換とは、インタラクティブな証明を非インタラクティブにするために、ライブの検証者が送る代わりにチャレンジをハッシュで生成する仕組みです。元の実装では公開入力を十分に早い段階でハッシュ化していなかったため、健全性（soundness）の保証が弱まっていました。Trail of Bitsが開示を調整し、Duskはメインネット前に修正して、それを“放置せず”公開的に直しました。
私が今も引っかかっているのはこの点です。つまり、暗号による証明システムに基づく、コンプライアンス重視のチェーンが、実運用に近いコードに実際の健全性バグを抱えていたものの、問題になる前に発見され修正された、ということです。PLONKを使う他の実装でも、この情報が公開されるまで依然として脆弱だったものがどれだけあったのか、あるいは、開示から他のプロジェクトが自分たちのフォークを修正するまでにどれくらいの時間差があったのかは、私にはわかりません。