#dusk $DUSK @Dusk
4つの数だけで済んだ。Duskのシールドされたフェニックス経路――その全体的なプライバシー主張を担う部分――は、1回の呼び出しで検証用の証明を通し、その呼び出しは、検証キーのすぐそこにあるコミットメントに対して4つのセレクタ値を照合することは決してなかった。$DUSK #dusk @Dusk は、これが2月に見つかる前から3回の別々の監査をすでに通過していた。
私を惹きつけたのは、ミスの「形」だった。セレクタは標準のPLONKでは公開され、固定され、検証側のデータであるはずだ。ところがdusk-plonkのカスタムウィジェットによって、それらは代わりに「証明者が供給する数値」になってしまい、暗号学的な結び付け（バインディング）が何を必要とするかを決める頭のモデルが更新されないままだった。回路ロジック自体は端から端まで問題なかった――そのギャップは、1層下、検証の配線のところにあった。
私の中で変わったのは、「3回監査された」は「正しい脅威モデルに対して監査された」と同じではないと気づいたことだ。制約ロジックを確認するレビュアーなら、静かに成立しなくなった構造上の前提を、そのまま通り過ぎてしまえる。これは通常のコードバグより見つけにくく、Duskに固有の話ではない――同じパターンがEspressoのJellyfishでも独立に見つかっている。
次に確認するべきこと：Duskが推している標準化されたPLONK検証仕様が実際に提供されるのか、それとも議論スレッドのままなのか。