私は、モデル化された 8 ビット XOR が 31 ゲートから単一の PlonKup ルックアップに落ちたことで、DUSK のゲート数という説明に疑問を持ち始めました。圧縮率は 96.8% で、非常に印象的です。ですが、それは回路の算術を反映しているだけで、実際の証明（プローヴ）速度を示すものではありません。

ルックアップでもテーブルの扱い、コミットメントのソート、メモリ負荷が発生します。つまり「31 分の 1 のゲート数」が「31 倍速い証明」につながるわけではないのです。コストは単に RAM 側へ移っている可能性があります。

これは重要です。DUSK のオペレーター向けガイダンスでは、証明ワーカー 1 人あたり約 1 GB、最低限のサーバーで 8 GB を見積もっています。これらはサイズの目安であり、測定されたピークメモリではありません。欠けている指標は、P50 と P99 の負荷（特に同時ワーカー）における、GB あたりの証明数です。

さらにアクセシビリティです。発熱やバックグラウンドアプリ、繰り返しの証明の後、ミドルレンジのスマホではどうなるでしょうか？ P50 が許容できても、P99 で停止してしまうなら、それは暗号技術の勝利というより、ユーザーの摩擦になります。

また、壊れた（不正な）証明も監視しています。不正な入力は、拒否されるまでにどれだけ CPU を消費し得るのか、そして早期フィルタリングでどれだけ節約できるのか。ある程度のオーバーヘッドは正常です。際限のない増幅は正常ではありません。

ルックアップによる圧縮が、高メモリのハードウェアに証明処理を集中させることなく、実際のスループットを改善するなら、DUSK は成功できます。とはいえ、DUSK が証明時間のピーク RAM エネルギー使用量、無効な証明の拒否ベンチマークを公表するまでは、より高速に動くことの裏付けは不完全なままです。

#dusk $DUSK @Dusk