#dusk $DUSK 翻 DUSK の XSC（拡張可能なセキュア・コントラクト）の発想について、最初に私を止めたのは、それがどんな種類の証券を発行できるかではなく、それを規制（コンプライアンス）のロジックをコントラクト自体に書き込み、チェーン外の法的書類に置かないことだった。$SNDKB
従来の証券のトークン化は、どのようなコンプライアンス規格を通るにせよ、本質は「オンチェーンでの台帳記録、オフチェーンでの執行」だ。振替ルール、ホワイトリスト、ロック条項はオフチェーンのプロトコルや法務文書によって拘束され、オンチェーンのトークンはただの記帳の証憑にすぎない。紛争が起きれば、責任追及の道筋は従来の法体系へ戻り、オンチェーンのデータはせいぜい証拠チェーンの一部になる。XSC がやろうとしているのは、ルールを執行層に内蔵し、振替そのものに条件検証を組み込むことだ。誰が保有できるか、譲渡できるか、どんな条件が満たされると凍結されるかを、すべてオンチェーンで完結させる。理論上は、オフチェーン執行の遅延性を減らせる。$SPCXB
ただ、見落とされやすい問題がひとつある。コンプライアンス・ルールをコントラクトに書き込んだ瞬間、ルールの可変性が中核のリスクになることだ。規制当局の解釈が変わり、KYC の名簿が更新され、越境のコンプライアンス要件が管轄によって変わる可能性がある。ルールのアップグレードに再デプロイや資産移行が必要なら、操作コストも法的リスクも決して小さくない。逆にアップグレード可能なインターフェースを残せば、別の形の中央集権的な裏口になってしまう。つまり、誰がルールを変更できるのか、ルール変更が既存の保有資産にどう影響するのか——これはプライバシー・台帳でいう「規制の鍵」の論争と同じ構造的矛盾だ。
さらに考えると、XSC が Phoenix/Moonlight の二つの台帳と連携する場合、コンプライアンス検証がどの層で行われるかが極めて重要になる。検証が透明層で完了するなら、プライバシー層での振替の実際は参加者の身元を露出させ、プライバシーは紙の記述にとどまってしまう。検証をプライバシー層で完全にゼロ知識証明で行うなら、効率と遅延もまた犠牲になる。この取捨選択について、現時点では明確な技術説明が見当たらない。
私は、XSC が今いちばん欠いているのはアプリのユースケースの宣伝ではなく、実際のルールアップグレードの事例だと思う。規制当局の解釈が変わったときに、既存の資産をどう扱うのか——それこそが、この標準が実資産を支えられるかどうかを判断する鍵になる。
#dusk @Dusk