@Dusk のSolidityアプリケーションの中で、プライバシーが実際にどこから始まるのかを追跡してみました。
DuskEVM上にデプロイされたコントラクトなら、データと決済が最終的にDuskDSを通るため、何らかの形でDuskのプライバシーを継承するだろうと想定しました。
しかし、実際のスタックの仕組みはそれほど単純ではありません。
DuskEVMは、開発者に馴染みのあるEVM実行環境を提供します。Solidity、Hardhat、Foundry、そして既存のウォレットを使えます。DuskDSは、その下で決済とデータ可用性の基盤として機能します。
とはいえ、通常のSolidityコントラクトでも、他のEVMアプリと同様に状態を公開することはできます。
機密性は、Hedgerを通じてアプリケーション側で設計する必要があります。あるいは、DuskVMとPhoenixを介してDuskネイティブのプライバシーパスに近いところで扱う必要があります。
「Duskのエコシステム内で動いている」というだけでは、自動的に追加されません。
この境界の理解に至って、私は立ち止まりました。
トークン化された債券市場を想像してください。
市場価格は公開のままでいる必要があるかもしれません。
投資家の適格性（資格）は、証明するだけで足ります。
保有者の残高は、おそらく非公開のままにしておくべきでしょう。
発行体または規制当局は、特定の記録への管理されたアクセスを求める場合があります。
これら4つの要素は、同じパブリックなSolidityの状態に単に並べるだけでは成立しません。
Hedgerは、値を暗号化したまま維持しつつ、ゼロ知識証明によって取引がそのルールに従ったことが検証されることで、その一部を解決するためのものです。
ただし、開発者はそれでも、どのデータを暗号化されたフローに入れるのか、何を公開のままにするのか、そして誰に開示権を与えるのかを決めなければなりません。
設計を1つ誤るだけで、暗号が保護する機会が来る前に、機微な金融データが露出してしまう可能性があります。
だから私は、Duskがどれだけ多くの暗号プリミティブをサポートしているかにあまり焦点を当てていません。
むしろ、Duskのツールが「公開／非公開の境界」を一般的なSolidityチームが正しく使えるほど明確にしているかを見ています。
Duskはプライバシーのルートを提供できます。
しかし、そのアーキテクチャ上の判断を、すべてのアプリケーションについてDuskが代わりに行うことはできません。
#dusk $DUSK