多くの人が「#dusk EVMは“後戻りだ”」と文句を言っていますが、私はむしろこれはチームがようやく一つのことを理解した証だと思います——互換性は妥協ではなく、コスト管理です。

新しく実行環境を一から自作するとなれば、技術的にはイーサリアムに負けないとしても、代償として周辺のあらゆる設備を最初から作り直さなければなりません。監査会社は新しい言語を学んでレポートを書かなければならず、ウォレットチームは署名ロジックを書き直し、インデックスサービスも再適応が必要です。これらのコストは結局、チェーンに載せようとする機関側に転嫁されます。機関が技術選定をするとき、往々にして「自分の既存チームがそのまま手をつけられるか」を先に見て、「この言語の設計がどれほど優美か」ではありません。

@Dusk EVMが賢いのは、実行層と基盤能力を分解している点です。開発者は従来どおり馴染みのあるツールでコントラクトをデプロイできますが、やろうと思えば、基盤のネイティブな機密決済やコンプライアンス検証を呼び出せます。これは開発者に選択肢を与えるもので、一本道を強制するものではありません。すでにイーサリアム上でトークン化を手がけたチームなら、理論上は多くのコードを書き換えずに済み、もともと規制されたシナリオ向けに設計されたチェーンにそのまま決済ロジックを接続できるはずです。

ただし、この設計だからといって私はそれを一段上に見積もりません。互換層が一つ増えるということは、信頼仮定が一つ増えるということです。層をまたぐ通信や状態同期といったところでは、歴史的に起きた事故が、コントラクトの脆弱性に劣らず存在してきました。より現実的なリスクは、もし大半の開発者が古いプロジェクトをそのまま持ってきて、EVMエコシステムの利便性を狙うだけなら、機密決済という本当の差別化能力が片隅に置かれてしまい、$DUSK EVMは単なる一般的なEVM系サイドチェーンと大差なくなることです。

だから、にぎやかなコントラクト・デプロイ数の数字はあまり重視していません。私はむしろ、これらのコントラクトのうち、ネイティブのプライバシーとコンプライアンスのモジュールが本当にどれだけ使われているのかを知りたいのです——この割合が上がらない限り、DuskEVMが語る差別化の物語は単なる“選択肢”のままで、事実になりません。