研究Dusk的技術アーキテクチャを調べていると、見過ごされがちな矛盾点に気づきました。つまり、取引レイヤーのコンプライアンスにかなりの労力を費やしている一方で、EVM実行レイヤーの権限配分についてはほとんど言及されていないのです。
ドキュメントでは、EVMレイヤーは単一のソーターによってトランザクションがパッケージ化されるとされていますが、これはイーサリアムのレイヤー2ネットワークにおける集中型ソーターと同じロジックです。表面上は効率化やコスト削減につながるように見えますが、機関投資家がデューデリジェンスを行う際に最初に尋ねるのはこういう点です。ソーターは誰が運営しているのか？停止時は誰が責任を負うのか？顧客資産がキューに詰まっている間、誰が先に立て替えるのか？

PhoenixやZedgerがどれほど巧妙に設計されていても、取引内容の機密性や検証ロジックの正しさを保証できるにとどまります。しかし、実行レイヤーのスイッチが単一の主体の手に握られているなら、「分散型金融基盤」という位置づけは割り引いて考えざるを得ません。欧州証券監督当局（ESMA）のカストディ規則は、ちょうどこの種の問題を詰めて確認しようとしています。顧客資産は誰が管理するのか、システムが中断した場合に誰が責任を負うのか、と。

さらに矛盾しているのは、Duskメインネットのコンセンサス層は取引の最終性を確かに保証している一方で、実行層のソーティング権限は依然として集中していることです。まるで、防弾の保管庫を作ったのに、入退室用のカードが1枚しかなく、それがプロジェクト側のポケットにあるようなものです。

私は、ソーターが集中していること自体が絶対にダメだと言いたいわけではありません。問題は、この設計が「機関レベルのコンプライアンス」という語り口と、どこかで強い緊張関係にあることです。従来の金融機関が求めているのは、「責任を持って管理してくれると信じてください」ではなく、契約に書き込める運営上の保証です。もしDuskが本当に大規模な機関資産を受け入れたいのなら、この権限配分の透明性の問題は、遅かれ早かれ真正面から回答を迫られるでしょう。

ある日、ソーターのガバナンス機構、障害対応の事前計画、そして分散化へのロードマップが明確に開示されているのを見たら、このアーキテクチャが機関にどれほど魅力的かを改めて判断します。今のところ言えるのは、技術力はそこにあるが、運営アーキテクチャの成熟度は時間をかけて検証する必要がある、ということです。
#dusk $DUSK @Dusk