今回 Dusk の開発ドキュメントを読んでいて、実際に立ち止まらせたのはプライバシー機能ではなく、「なぜもっと EVM だけにしなかったのか」という点でした。
いま Dusk は DuskVM と DuskEVM を両方維持しています。前者は Dusk L1 上でそのまま動作し、Rust/WASM のコントラクトを対象にしています。一方で後者は Solidity、Vyper、そしてお馴染みの EVM ツールチェーンを提供します。公式の回答は開発者にとって実にシンプルで、「2 つの道が解決するのは同じ問題ではない」ということです。
> これは重複投資に見えますが、実際は「開発のしやすさ」を「ネイティブ能力」と引き換えにしているだけです。
一般的な EVM 開発者の立場からすると、DuskEVM のほうが明らかに手間が少ないです。ウォレット、言語、ツールチェーンがより馴染み、移行コストも低く、チームがまったく未知の開発方式を一から学び直す必要もありません。
しかし、アプリが Dusk のネイティブ資産やプライバシー能力、ゼロ知識ロジックに直接触れる必要がある場合、あるいは L1 により近い実行環境が求められる場合には、DuskVM に存在価値があります。公式ドキュメントは、この2つの経路を明確に区別しており、無理にすべてのアプリに同じ道を選ばせようとしていません。
問題はまさにそこです。
2つの実行環境は、開発と保守の複雑さをより高め、エコシステムのツールも完全に統一されることは難しいでしょう。
ただし、EVM 互換性だけを求めるのであれば、Dusk は自分の最も特殊な能力を、汎用の実行フレームワークの中に閉じ込めてしまう可能性もあります。
最近ますます、Dusk が本当に賭けているのは「イーサリアムと互換であるかどうか」ではなく、
**開発者がまずは慣れたものを使って入り込めるのか、そして本当にネイティブ能力が必要になったときに、別の道へ進む気持ちになれるのか。**
もしあなたが開発者なら、より馴染みのある EVM で素早くローンチするでしょうか？それともプライバシーやネイティブ能力のために、新しい実行環境を学ぶコストを引き受けるでしょうか？@Dusk
#dusk $DUSK
いま Dusk は DuskVM と DuskEVM を両方維持しています。前者は Dusk L1 上でそのまま動作し、Rust/WASM のコントラクトを対象にしています。一方で後者は Solidity、Vyper、そしてお馴染みの EVM ツールチェーンを提供します。公式の回答は開発者にとって実にシンプルで、「2 つの道が解決するのは同じ問題ではない」ということです。
> これは重複投資に見えますが、実際は「開発のしやすさ」を「ネイティブ能力」と引き換えにしているだけです。
一般的な EVM 開発者の立場からすると、DuskEVM のほうが明らかに手間が少ないです。ウォレット、言語、ツールチェーンがより馴染み、移行コストも低く、チームがまったく未知の開発方式を一から学び直す必要もありません。
しかし、アプリが Dusk のネイティブ資産やプライバシー能力、ゼロ知識ロジックに直接触れる必要がある場合、あるいは L1 により近い実行環境が求められる場合には、DuskVM に存在価値があります。公式ドキュメントは、この2つの経路を明確に区別しており、無理にすべてのアプリに同じ道を選ばせようとしていません。
問題はまさにそこです。
2つの実行環境は、開発と保守の複雑さをより高め、エコシステムのツールも完全に統一されることは難しいでしょう。
ただし、EVM 互換性だけを求めるのであれば、Dusk は自分の最も特殊な能力を、汎用の実行フレームワークの中に閉じ込めてしまう可能性もあります。
最近ますます、Dusk が本当に賭けているのは「イーサリアムと互換であるかどうか」ではなく、
**開発者がまずは慣れたものを使って入り込めるのか、そして本当にネイティブ能力が必要になったときに、別の道へ進む気持ちになれるのか。**
もしあなたが開発者なら、より馴染みのある EVM で素早くローンチするでしょうか？それともプライバシーやネイティブ能力のために、新しい実行環境を学ぶコストを引き受けるでしょうか？@Dusk
#dusk $DUSK