Duskのプライバシーモデルは理解できたと思っていましたが、実際にトランザクションがウォレットから出た後に何を信頼する必要があるのかを追跡し始めると、その内容が暗号そのもの以上にずっと面白いアーキテクチャであることがわかりました。

トランザクションの流れをマッピングするほど、注目は暗号化から離れて、協調（コーディネーション）へと移っていきました。Phoenixの送金は、単に有効な証明を作るだけの話ではありません。これは、最近のMerkleルートから構築される証人（witness）、二重支払いを防ぐnullifier、そして確定される前にネットワークが一貫した状態に合意することに依存しています。各層は異なる前提を守っており、そのため信頼モデルは細部まで検討する価値があります。

ドキュメントでは、ビューキーと分離された認可のおかげで、支出鍵を公開せずに、証明生成やブロックチェーン走査を委任できると説明されています。その設計は鍵の露出を減らしますが、同時に実務上の疑問も生みます。委託されたプロービング（証明生成）サービスはどのように検証されるのでしょうか。委託されたスキャナが利用不能になったり、遅延したり、ある情報だけを選択的に差し控えたりしたらどうなるのでしょうか。暗号そのものが与える保証と、それでもなお必要とされるのが、周辺インフラが誠実に動作することに依存する部分はどこでしょうか。

この区別は重要です。最も強固なプライバシーシステムは、単に「何を隠すか」だけで定義されないからです。周囲のエコシステムの一部が予測できない振る舞いをしたとき、どれだけ回復力（レジリエンス）を保てるかによって定義されます。Duskにおいては、最終的にはゼロ知識証明そのものを理解するよりも、その境界を理解することのほうが、より重要になるかもしれません。

@Dusk_Foundation $DUSK #dusk