DuskEVMが存在したのなら、Dusk Networkはもっと単純な売り込みができたはずです。つまり、実行環境は1つ、誰もがSolidityで開発できて、終わり。ところがドキュメントでは、ネイティブのDusk開発――Rustで書いたコントラクトをWASMにコンパイルし、DuskVMで実行すること――が、アプリケーションがプロトコルレベルの制御や、カスタムのトランザクションモデル、あるいは基盤レイヤーに近い位置で動作するゼロ知識の機能を必要とする場合には、推奨ルートであると明確に示されています。私はこの判断が興味深いと思います。というのも、実行経路を2つ維持することは、1つに統一するよりも、構築コストも説明コストも高くつくからです。

その論理は、DuskEVMとDuskVMが同じ顧客を奪い合うというより、異なる顧客層に最適化されているということのようです。既存のEthereum DeFiプロトコルを移植するチームは、馴染みのあるツール、既存の監査、すでに動いているウォレットを求めます。それがDuskEVMの役割です。一方で、送金に上限を設ける設計や、配当の分配、あるいはコンプライアンス規則を契約に直接組み込んだ証券決済ロジックを作るチームは、最初からZedgerやネイティブのDuskVMコントラクトが想定していた領域により近い位置にあります。なぜなら、このハイブリッドなトランザクションモデルは、まさにこの種のセキュリティトークンの台帳管理のために目的をもって設計されており、一般用途のパターンから後付けで適用したものではないからです。

私は、このデュアルトラックのアプローチがDusk Network自身の開発者基盤やドキュメントの取り組みを、1つに集中させる代わりに2つの対象者に分断してしまうことを、完全には納得できていません。実行環境が2つなら、維持すべきツール群も2組、参加する新しい貢献者が理解すべきメンタルモデルも2つ、そして「新しいアプリは実際どこに作るべきか」という単純な問いへの答えも2つになります。この賭けが成立する理由も理解しています。つまり、ここが早い段階で1ルートに絞り込んでしまえば、切り捨てられた方のオーディエンスは静かに失われていたでしょう。今後数年でDusk Networkが両方の経路をきちんと支えられるほど十分に大きくあり続けられるかは、注視する価値があります。

#dusk $DUSK @Dusk