今週少し時間を取って、Dusk（$DUSK ）がプライバシー主張の「reviewable（レビュー可能性）」側を実際にはどう扱っているのか掘り下げました。#dusk @Dusk
私を止めたのはこれです。apps.dusk.network/explorerでPhoenixのトランザクションを開いてみると、見えるのは基本的に…手数料とガス使用量だけ。証拠自体はそこにあり、「有効（valid）」としてマークされています。でも送信者、受信者、金額—それらは表示されません。ZKプルーフは、取引が正しいことをネットワークに伝える一方で、取引の中身が何かまではネットワークに教えません。これが実際の仕組みです。レビュー可能性は公開チェーン上には存在せず、「ビューキー（view key）」を持つ相手のところにあります。完全に別の表面です。
待って—これは、8月16日のブリッジ事故を妙な形で言い換えるものです。あのチームウォレットで疑わしい動きは、監視によって捕捉できるものでした。なぜなら、ブリッジの操作はPhoenixのシールドされたフローではなく、公に見えるアドレスを通して実行されるからです。表に出たんですね。同じ振る舞いを持つPhoenix経由の操作なら、ビューキーがなければオンチェーンでは見えなかったはずです。つまり「private（プライベート）」と「reviewable（レビュー可能）」がここで衝突しているわけではなく、設計として異なるレイヤーにスコープが分かれているだけです。証拠が妥当性を裏付けます。開示をコントロールするのは鍵です。
洞察が、証明生成のオーバーヘッドについての話だと思って入っていきました。ところが、もっと静かな何かに行き着きました。規制された文脈では「監査可能（auditable）」とは、オンチェーンの透明性ではなく、ビューキーへの制御されたアクセスを意味する、ということです。これはアーキテクチャ上は筋が通っています……ただし、誰が鍵の保管（カストディ）を管理するのか、そしてそのアクセス自体がどこかで記録（ログ）されるのかを問い始めると話は別です。