私はDuskの最近の開発を掘り下げていて、ある点が良い意味でずっと引っかかっています。@PLONK のパフォーマンス改善です。
証明時間が58%も減ったのは目を見張るのですが、私が引っかかったのは数字そのものではありません。
そこに至るまでのやり方です。
決定論的なプローヴァ／検証者データをキャッシュし、反転（inversion）とMSM項をバッチ化し、独立したFFT処理を並列化し、さらに繰り返しの割り当てを削減することで、証明スループットはおよそ2.4倍になりました。
検証も44%改善し、回路コンパイルは25%速くなりました。
しかし重要なのは、変えられずに残った部分です。
基礎となる数学、トランスクリプト、そして証明フォーマットは変わっていません。
だからこれは「より良い暗号」というより、すでに機能している暗号から無駄な手間を取り除く作業に見えます。
次に、DuskEM × DuskDSのテストを見たところ、同じようなテーマを感じました。混在した負荷のもとで、異なる実行モデルや状態モデルを検証しているのです。
これは重要です。各コンポーネントが単独で動いているだけでは、システムはなかなか難しくなりません。摩擦は通常、うまく連携させる必要が出たときに表れます。
そして、プライバシーネットワークで私が今一番気にし始めているのが、その部分かもしれません。
強い暗号はプライバシーを確立できます。
でも、証明が遅い、検証が高コスト、あるいは実行が予測不能になると、ユーザーは結局その複雑さを感じてしまいます。
間違っているかもしれませんが、たぶんDuskの本当の課題は「プライバシーが機能することを証明する」ことではない。
プライバシーの裏側にある仕組みを、誰もそれを意識しなくて済むほど十分に速くすることだと思うのです。

#dusk @Dusk $DUSK