それでは、Duskのこの全体的なプライバシー・アーキテクチャを順に説明します。これは、特定の暗号プリミティブのスタックの上に構築されています。そして重要なのは、各要素がそれぞれ役割を担っており、他の要素には本質的にできない仕事をしているということです。

まずBLS12-381です。これは@Dusk が署名を実現するために使っているもので、ZK関連の暗号処理の多くを支えています。次に、Phoenixのプライバシー層については、JubJubというものに依存しています。これはSNARKに適した楕円曲線です。正直に言うと、これがないと、Duskにおけるシールド（秘匿）証明は実運用で実行するには速すぎない、というレベルになってしまいます。

ネットワーク全体での認証については、$DUSK はSchnorr署名に固執しています。これはクリーンで、よくテストされた選択肢であり、実験的なものではありません。さて、DuskのZK回路の内部では、ハッシングはPoseidonで扱われます。これは、古いハッシュ関数を回路に放り込むと急速に高コストになってしまう状況で、とにかく安く済むように作られたものです。

状態およびメンバーシップ（所属）証明に関しては、#dusk は疎（スパース）Merkleツリーを使います。そして、証明・検証レイヤー全体はPLONK上で動作します。さらに、DuskはBLS集約と呼ばれる仕組みも適用します。これは、委員会（コンサート）の署名を1つのパッケージに圧縮することで、ネットワークがそれぞれを個別に検証する必要をなくします。

では、全体のラインナップを分かりやすく並べます：

BLS12-381 — 署名およびZK関連の暗号処理
JubJub — Phoenix型プライバシーを支えるSNARK向け曲線
Schnorr — 署名および認証
Poseidon — ZK向けハッシング
疎Merkleツリー — メンバーシップおよび状態の証明
PLONK — ZKの証明および検証
BLS集約 — 委員会の署名を1つに圧縮

そしてここからが大事ですが、これらのプリミティブは紙の上に並べただけでは本質的にあまり意味がありません。Duskの暗号は数学的に完全に健全であっても、実運用では、たとえば悪いシリアライズ、サブグループの確認漏れ、弱いトランスクリプト結合、あるいはドメイン分離のスキップといったことで、簡単に土台を崩され得ます。だからこそ、Duskの暗号基盤を公正に評価しようとしているなら…