今日はDuskのアーキテクチャを眺めていて、深掘りしてみるとあることがより納得できました：
Duskはすべての開発者を同じ実行環境に押し込むことはしていません。
その代わり、決済（settlement）と実行（execution）を分離しています。
土台にはDuskDSがあり、コンセンサス、ファイナリティ、データ可用性を扱います。
その上には2つの異なる経路があります。
DuskVMは、Dusk L1上でRust/WASMコントラクトを直接実行します。
DuskEVMは、SolidityやVyper向けにEVM互換の環境を開発者に提供しつつ、決済は引き続きDuskDSで行います。
最初は、2つの環境があることは私には不必要な複雑さに見えました。
でも、その理由がよりはっきりしてきました。
Duskのネイティブなトランザクションモデルへの直接アクセス、プライバシー、またはゼロ知識（zero-knowledge）の機能が必要なアプリケーションはDuskVMを使えます。
すでにEthereumの開発者エコシステムの中で生活しているチームなら、開発ワークフローをゼロから作り直す代わりに、馴染みのあるツールとSolidityでDuskEVMを使えます。
それは興味深いトレードオフです。
Duskは、開発者に「ネイティブなインフラ」か「EVM互換」かを選ばせようとしているわけではありません。
その両方を維持しつつ、その下に決済を置こうとしているのです。
私が今も抱いている重要な問いはこれです：
実行経路を2つ用意することで、追加されたアーキテクチャの複雑さを正当化できるだけの、十分に異なるビルダーを実際に惹きつけられるのでしょうか？
私にとっては、「DuskはEVM互換だ」と言うだけよりも、そこを見守るほうがずっと興味深いです。
#dusk $DUSK @Dusk