@Dusk_Foundation #dusk
私は以前、Duskのプライバシーは主にトランザクション設計の問題だと思っていました。ネットワークを見れば見るほど、証明レイヤーの存在感が増してきます。

Phoenixにはゼロ知識証明が必要ですが、それらの証明の裏で行われる重い計算は、やはり誰かが担わなければなりません。Duskは、ネットワークのあらゆる部分に同じ計算負荷を背負わせるのではなく、専用のProver基盤を通じてその作業を分離しています。 🔐

私の目を引いたのは、ZK証明の生成が計算集約的で、しかも主にシングルスレッドであるため、DuskのドキュメントではProversに強力なシングルコア性能が重要だと強調している点です。基本的なProver構成は、だいたい4コア、8GBのRAM、20Mbpsから始まり、追加のワーカーは並列で動かせます。

それにより、興味深いアーキテクチャ上のトレードオフが生まれます。

コンセンサスは応答性を維持する必要がある一方で、プライバシー用の証明には、効率よく完了できるだけの計算能力が求められます。

つまり、ここでのプライバシーは単に「トランザクションを隠す」だけではありません。

計算がどこで行われるのか、誰がそれを実行するのか、そしてその作業負荷がボトルネックにならずにスケールできるかどうか、という問いにもなります。

私は、プライバシーというラベルそのものよりも、その点のほうがより興味深いと感じています。

Duskの利用が増えていくにつれて、ZK証明の処理能力が現実の性能制約の1つになり得ると思いますか？
$DUSK $PORTAL $DOLO
利用が増えていくと、Duskのより大きなボトルネックになり得るのは何でしょうか？