今朝、DuskのHedgerドキュメントを見ていて引っかかったのが、アーキテクチャの分割でした。すべてを1つのプライバシー技術に任せるのではなく、Hedgerは役割を分けています。機密性の高い金融価値は計算中に秘匿するために準同型暗号を用い、さらに計算が正しく行われたことを別のゼロ知識証明で検証します。

これは、HedgerがDuskEVM上に載っている一方で、ZedgerがネイティブXSCコントラクト向けのプライバシーを扱っているため重要です。同じ機密性のある有価証券という目的に向けた2つの別経路であり、異なるレイヤー上で動作しています。

私は、彼らが同時に満たしている要求が3つあると数えました。保有（Holdings）、金額（amounts）、残高（balances）はDusk自身のドキュメントにある通り、エンドツーエンドで完全に暗号化されたままで、さらにシステムは規制に対応した監査可能性のために設計されており、コンプライアンスが必要な場合は、設計上完全に監査可能です。

これは、純粋な匿名性ではなく、金融アプリケーションのために機密スマートコントラクトを実用的に保つという明確な選択を示しています。そして、私がまだ確認しようとしているのは、XSC固有のコンプライアンスロジック、強制移転、キャップテーブルが、ZedgerネイティブではなくDuskEVM上のHedger経由で同様のワークフローが動く場合に、どれくらい引き継がれるのかです。

次に注目するのは、その具体的な引き継ぎ（ハンドオフ）です。

@Dusk #dusk $DUSK