#dusk $DUSK @Dusk 私は、Duskの最近の開発でずっと思い返していた一点があります。それは暗号技術そのものではありません。
同じ暗号をより“働かせる”ための努力です。
PLONKの性能改善は、基礎となる数学やトランスクリプト、プローフォーマットを置き換えたわけではありません。代わりにDuskは、それらの周りで無駄になっていた作業に取り組みました。決定的なデータのキャッシュ、反転（inversions）やMSM操作のバッチ化、独立したFFTタスクの並列化、そして繰り返し計算の回避です。
その結果が私の目を引きました。証明時間は58%減、概ね2.4倍の証明スループット、検証は44%高速化、コンパイルは25%高速化。
でも正直なところ、数字はほとんど二の次です。
私が関心を持つのは、これが次の問題について何を示しているかです。
プライバシーは数学的に強固であり得ますが、証明・検証・実行の速度が追いつかなければ実用にはなりません。
私はDuskEVM×DuskDSのテストにも同じ問いを見ています。異なる実行モデルや状態モデルを、別々に評価するのではなく、混在したワークロードの中で突き合わせています。
それは、より現実的な難題に近い気がします。各部品が動くかどうかではなく、システムが忙しくなったときに、それらが一緒に動き続けられるかです。
そこで私は、Duskの最も難しいエンジニアリング課題が、もはや「プライバシーが機能すること」ではないのではないかと考え始めています。
プライバシー、実行、そして協調（コーディネーション）が、ユーザーにとってほとんど見えないレベルにまで感じられるようにすること。
それが、たぶんもっと面白い試験です。

#dusk