#dusk $DUSK @Dusk 今日はなぜ夕暮れ（dusk）がわざわざ別々の2つの実行環境をわざわざ分けて動かしているのか、その理由を探しに行ったんだ。正直なところ、1つに絞って選べばいいのに。😂 答えは「技術的にすごいから」みたいな話というより、かなり現実的なトレードオフだった。

つまり、duskvm は wasmtime をベースにした wasm 環境で、dusk l1 自体で直接実行される。duskevm が duskds を経由して（＝決済ホップが必要になる形で）動くのとは違う。これについては前に書いた。duskvm は、dusk のトランザクションモデルやプロトコルレベルのアセット、そしてプライバシーや zk（ゼロ知識）機能とのより密な統合を求める rust コントラクト向けだ。一方 duskevm は純粋に solidity と標準的な EVM ツール、foundry、hardhat、既存ウォレット、など――すでに多くの人が知っている「イーサリアムのエコシステム」ありきで存在している。

dusk 側の説明では、この分断がなぜ重要かを示す実数が出ていて、どうやらカスタムの専用 l1 統合は、同等の evm 配備と比べると 6〜12 か月かかり、費用はおよそ 50 倍程度になるらしい。さらに「ネイティブな dusk への対応」は取引所が数か月かけて適応しているのに対し、「evm 統合」は数週間で済む、と具体的に挙げている。

で、そういう数字を読んでからずっと気になっているのが、「このコスト差が、気づかないうちにほとんどの人をデフォルトで duskevm に寄せてしまっているのでは？」という点だ。技術的には duskvm のほうが、より密なネイティブ・プライバシー統合という意味で恩恵が大きいプロジェクトでさえも。いちばん抵抗が少ない道があまりに安くて早いなら、本当に難しいけど用途に合わせた（目的特化の）選択肢は、フィットしていても結局あまり使われないのではないか。そうした緊張関係に真正面から答えるものはまだ見かけていない。

それでも、全員に同じ妥協モデルを押し付けるのではなく、ビルダーに2つの本物の選択肢を用意するのは、単に複雑さを増やしたいだけではなく、本当に異なるニーズに応えるための正当な対応だと思う。

正直、そのコスト差が本気度の高いプロジェクトの多くを duskevm へ導くのか、それとも duskvm が本当に必要とされるユースケースではちゃんと自分の役割を果たしているのか……どっちなんだろう？
🤔

#dusk @Dusk $DUSK