#dusk $DUSK @Dusk Dusk'sの機密性セットアップは、実際には2つの別々のトラックで動作します。DuskDSでは、Phoenixモデルはメルクルツリーにコミットされたノートとして価値を表現します。つまり、ノートを使っても「どのノートが消費されたか」を指し示しません。代わりに送信者はヌリファイアとゼロ知識証明を公開し、消費が有効であること、所有権が実在すること、そして無から価値が創出されていないことを示しつつ、基となるノートは明かしません。これに加えて、Moonlightは同じチェーン上で動く透過的なアカウントベースのモデルとして動作します。

一方、DuskEVMでは、プライバシーはまったく別のツールセットから得られます。Hedgerというモジュールで、ElGamalベースの同型暗号化とゼロ知識証明を組み合わせ、さらにハイブリッドなUTXO/アカウント構造を採用しています。ここではユーザーは標準のEVMアドレスを通じてコントラクトとやり取りしますが、暗号化された残高を扱う別個のHedgerアドレスが存在し、コンプライアンスは許可リストによって強制されます。

これは同じ発想の2つのバージョンではありません。Phoenixはノートベースの証明システムであり、Hedgerは暗号化された残高に対して直接計算し、ゼロ知識証明によって検証されます。分岐のもっともありそうな理由は、ノートベースのプライバシーがアカウントベースのEVM構造に自然には収まらないため、そこで別のアプローチが必要になったことです。

独立した2つの暗号学的なプライバシースタックを並行して走らせることは、攻撃面を広げ、監査負担を重くします。また、価値が2つのレイヤー間で移動するとき、プライバシー保証がどのように保たれるのかも明確ではありません。

2つの別々の機密性エンジンを維持すると、監査負担は比例して増えるのでしょうか。それとも、ゼロ知識証明への共有された依存によって、2つ目のエンジンの増分コストは見かけほど高くならないのでしょうか？