#dusk $DUSK @Dusk 深く掘り下げていくほど、胸の奥に引っかかるひとつの問題が見えてきます。規制を受ける金融業務においては、プライバシーだけでは到底不十分で、本当に重要なのは取引ルールが実際のところきちんと適用されるかどうかです。そこで私は、Dusk のコンプライアンス対応のやり方を徹底的に調べました。

Phoenix はゼロ知識証明で取引の詳細を覆い隠し、Moonlight は透明な口座フローを提供します。Citadel ではさらに選択的開示の層を加え、XSC のコントラクトでは資格制限、譲渡の制約、報告義務といったものを取引ロジックそのものに直接書き込めます。これは、コンプライアンスが必ずしもすべてをオンチェーンの外に置く必要はないことを示しています。

ただ、避けて通れない前提があります。金融商品が複雑になるほど、ルール自体も複雑になっていくという点です。たとえば、譲渡に制限がある資産、投票、コーポレートアクション、リカバリーフローなどが絡むだけでなく、さらに開示のレベルも分かれている必要があります。ある段階を超えると、問題はプライバシーが役に立つかどうかではなく、これらのルールが同時に重なったとき、システムが意図したとおりに完全に機能し続けられるかどうかになります。

たとえば、ある有価証券の譲渡が同時にロックアップ（譲渡制限）ルール、議決権の変更、そして管轄をまたいだ開示義務をトリガーするとします。オンチェーン・コントラクトは、同一の実行サイクルの中で、すべての制限条件を一通りチェックできなければなりません。どれか一つでも見落とせば、取引全体が無効になり得ますし、場合によってはコンプライアンス事故を引き起こす可能性もあります。このような複雑なルールの重なりは、実際の金融の現場では「まれ」ではなく、日常茶飯事です。

だいたい、私が Dusk を一番厳しく見ているのはそこです。アーキテクチャ図だけを見ると、すべて筋が通っているように語れます。けれど私が本当に知りたいのは、実際のワークフローが動き始めて混乱したり、さまざまな境界ケースが発生したりしたとき、それでも耐えられるのか、ということです。