‎私のいとこは家の裏で別々の2つのワークショップを運営しています。木工用と溶接用です。私は「どうして全部まとめて、1つの物置（小屋）を作って、それを両方に使わないの？」と聞いたことがあります。彼は「両方をうまくこなそうとして1つの空間にまとめると、結局どちらも中途半端になる」と言いました。
‎
‎私は、Duskの実行レイヤーは私がこれまで見てきた他のチェーンと同じように動くのだと思っていました。つまり、EVMを選んで導入すれば終わり、という前提です。しかしDuskVMが実際に何なのかを追って調べると、その前提は崩れました。
‎
‎DuskVMはWasmtime上で動き、Rust/WASMのコントラクトをDuskのL1上で直接実行します。これはDuskEVMに後付けされた“レイヤー”ではなく、完全に別個の環境です。DuskVMは、Duskのネイティブなトランザクションモデルへの直接アクセス、プライバシー、そしてゼロ知識の機能を必要とするコントラクトのために存在しています。これは、EVMの実行モデルがそもそもネイティブに公開するよう作られていなかったまさにその要件です。
‎
‎その土台となるPiecrustは、DuskのもともとのRuskVMを置き換えました。RuskVMは、規制資産トークン化をスケールさせる前にDuskが解決しなければならなかった、状態成長とパフォーマンスの限界にぶつかったためです。Dusk自身のエンジニアリングノートでは、PiecrustはRuskVMを10倍以上上回ると記されています。しかも見積もりではなく、PLONK、Groth16、BLSのホスト・ファンクションがランタイムに直接組み込まれているという、公開された直接比較です。
‎
‎DuskEVMはもう一方の仕事をまるごと担当します。つまり、完全なEVMの同等性、標準的なSolidityのツールチェーン、そしてプライバシー・ネイティブのプリミティブを必要とせずに馴染みのワークフローで使いたい開発者向けのDuskDSによる決済です。
‎
‎本当の試金石は、DUSKがこの2つの環境を実際に“本当に別々に”保つことで効果が出るのかどうかです。つまり、プライバシー・ネイティブのコントラクトを、別のもののために作られた実行モデルに無理やり押し込むのではなく、採用が両側で広がっていく中で、その分の価値がきちんと回収できるのかが問われます。
‎
‎2つの専用環境で運用するほうが、1つの妥協版より優れているのか。それとも、結局は“分かりやすさの半分”のために“メンテナンスが2倍”になるだけなのでしょうか？

#dusk $DUSK @Dusk