#dusk $DUSK 今日、私は@DuskのDuskEVMテストネットのドキュメントを読んでいました。最初は「これでDuskがついにSolidityに対応した」ということなのだと思っていました——標準的なEVM互換レイヤーで、開発者がイーサリアムのコントラクトを移植して動かすだけで済む、という理解です。しかし、アーキテクチャ図でDuskEVMとDuskDSの関係を見た瞬間、「そう単純ではない」と気づきました。
DuskEVMはOP Stackをベースに構築され、標準のイーサリアムJSON-RPCインターフェースを使います。チェーンIDは745で、ガストークンは$DUSK のままです。開発者はFoundryやHardhatでコントラクトをデプロイでき、テストネットのブラウザもBlockscoutです。表面的には、他のOP Stack系チェーンと大差ありません。
ただし重要なのは、DuskEVMが決済やDA（データ可用性）を自分で管理しないことです。実行はEVMレイヤーで行い、決済とデータ可用性はDuskDS——つまりDusk L1のコンセンサスおよび最終性レイヤー——に委ねます。つまり、EVMコントラクトは互換環境上で動きますが、最終状態はDuskDSのSuccinct Attestationコンセンサスによってロックされます。確率的な確認ではなく、決定的な最終性が得られるのです。
たとえるなら、まったく同じ仕様の商業施設を都心にもう一つ開くのではなく、既存の商業施設の店舗が、みんなに馴染みのあるレジシステム（EVM）を使っているだけ、という感じです。しかし、1台ずつのレジで計上された売上は結局、最後は本部の金庫（DuskDS）で精算されます。お客さんには違いが見えませんが、監査やコンプライアンスでは「本部の台帳」が見られており、レジのキャッシュは見られていないのです。
ここで見落とされがちな制約があります。DuskEVMとDusk L1はbridgeで接続されており、DUSKは両側の口座体系では同一資産ですが、レイヤーを跨ぐ送金にはbridge操作が必要です。bridgeの流動性が足りない、または遅延が高い場合、EVMレイヤーでのDeFi体験は目減りします。現時点のテストネット段階では、bridgeの実効スループットや遅延データはまだ多くありません。@Dusk
したがって、#dusk のEVMという「入口」を見るにあたり、私はテストネット上での実際のコントラクトデプロイ件数、bridge遅延の分布、そしてDuskEVMとDusk L1の間での資産移転に伴う摩擦コストに注目します。$DUSK EVMの入口があるだけでは、開発者が来るとは限りません。来た後に定着できるか——それが本質です。