#dusk Duskの開発者向けアーキテクチャを初めて見たとき、正直なところ「なぜスマートコントラクト環境が2つ必要なのか」を疑問に思いました。最初に思いついたのはシンプルで、「1つで十分ではないのか?」ということです。
しかし、よく見ていくと、彼らは2つの異なる開発者の課題を解決しようとしているのだと分かりました。
DuskEVMはおなじみのルートです。SolidityとEVM互換のツールがあることで、すでにイーサリアムのエコシステムを理解している開発者にとって取り組みやすくなります。
一方で、DuskVMのほうは、私の中でアーキテクチャの意味がより明確になってきました。Rust/WASMのコントラクトはDusk L1上で直接実行され、Dusk固有の機能、つまりトランザクションモデル、プライバシー、ゼロ知識機能などを扱うための、よりネイティブな形で開発できるようになります。
だから私は、DuskEVMとDuskVMを競合する環境としては見ていません。
2つの異なる入口だと捉えています。
互換性や馴染みのあるツールが欲しいならEVMが理にかなっています。アプリケーションが、Dusk自身のL1が提供できるより深いアクセスを必要とする場合は、DuskVMのほうがより自然な選択に見えます。
それによって、アーキテクチャの見方が変わりました。
Duskは単に「EVMに対応します」と言っているわけではありません。実行レイヤーでは開発者に柔軟性を与えつつ、DuskDSがその下で、決済とデータ可用性のための土台として残るのです。
私にとって、デザインのより面白い部分はここです。同じ実行モデルにすべてのアプリケーションを無理に押し込むことなく、さまざまな方法で構築できるようにしている点です。$DUSK @Dusk
しかし、よく見ていくと、彼らは2つの異なる開発者の課題を解決しようとしているのだと分かりました。
DuskEVMはおなじみのルートです。SolidityとEVM互換のツールがあることで、すでにイーサリアムのエコシステムを理解している開発者にとって取り組みやすくなります。
一方で、DuskVMのほうは、私の中でアーキテクチャの意味がより明確になってきました。Rust/WASMのコントラクトはDusk L1上で直接実行され、Dusk固有の機能、つまりトランザクションモデル、プライバシー、ゼロ知識機能などを扱うための、よりネイティブな形で開発できるようになります。
だから私は、DuskEVMとDuskVMを競合する環境としては見ていません。
2つの異なる入口だと捉えています。
互換性や馴染みのあるツールが欲しいならEVMが理にかなっています。アプリケーションが、Dusk自身のL1が提供できるより深いアクセスを必要とする場合は、DuskVMのほうがより自然な選択に見えます。
それによって、アーキテクチャの見方が変わりました。
Duskは単に「EVMに対応します」と言っているわけではありません。実行レイヤーでは開発者に柔軟性を与えつつ、DuskDSがその下で、決済とデータ可用性のための土台として残るのです。
私にとって、デザインのより面白い部分はここです。同じ実行モデルにすべてのアプリケーションを無理に押し込むことなく、さまざまな方法で構築できるようにしている点です。$DUSK @Dusk
