#dusk $DUSK

この数日また@Dusk のアーキテクチャドキュメントを読み返していて、前に自分が抱いていた疑問を少し軽く見積もっていた点がありました。

DuskEVMは最終的にDuskDSの決済（settlement）へ戻るはずなのに、なぜDuskVMを別途残しているのでしょう？

最初は、開発言語の違いにすぎないのだと思っていました。Solidityと、Rust/WASMのように。

でも読み進めると、違いは実行経路（execution path）にあります。

DuskVMはL1上で直接動作します。

DuskEVMはそうではありません。取引はまずsequencerへ送られ、EVM層で実行され、その後にbatchやstate commitmentがあり、最後にDuskDSへ接続されます。

つまり、最終的に同じsettlement layerに着地するとしても、その間に通るものはまったく別物です。

この違いはかなり重要だと感じます。

すでにSolidityの製品群があり、コード改修をなるべく少なくして移行したいなら、DuskEVMは理にかなっています。ツールや開発の習慣もほぼ馴染みがあるはずです。

ただ、アプリ自体がそもそもL1に直接触れる必要がある場合、あるいはDuskネイティブの実行能力やプロトコルレベルのロジックを使いたい場合は、無理にEVMという層を経由する必要はないかもしれません。

なので私は今、DuskEVMとDuskVMのどちらが「より上位」なのかにあまり悩まなくなりました。

むしろ2つの道だと思います。

1つは、既存のEVM開発者が入りやすい道。

もう1つは、もともとDusk-nativeの能力を直接使いたい人たちのための道です。

最終的にはどちらもDuskDSへ接続できますが、execution pathは別物です。

そしてこれこそが、Duskのこのアーキテクチャが「もう一つのEVM互換なL1」よりも、研究する価値があると私が感じる理由でもあります。