Dusk Network：DuskDSとDuskEVMについて読んでいると、何かが引っかかります。DuskDSとDuskEVMは別々の2つの要素として説明されているのに、単独で成立しているわけではありません。
まずはアーキテクチャから始めます。Duskの資料では、DuskDSを「レイヤー（layer）」、つまり settlement と data availability を担う層と呼んでいます。そこではコンセンサス、ファイナリティ、そしてDuskネイティブのトランザクションモデルを扱います。一方のDuskEVMは、EVMと互換性のある実行環境で、Solidityのスマートコントラクトは、馴染みのあるツールチェーンで動かせます。さらに重要なのは、DuskEVMが settlement と data availability にDuskDSを使う点です。
これが単なる呼び方の話なのか、それとも責務の分離が本当に存在するのかを確かめたいと思いました。深く読むと、DuskDSはコンセンサス、ファイナリティ、data availability、そしてMoonlightやPhoenixのようなトランザクションモデルを処理していることが分かります。DuskEVMは実行に集中し、HardhatやFoundryに加えてEVMエコシステム全体を活用できるようにしています。片方が settlement の基盤を提供し、もう片方が実行を担う——そういう役割分担です。
ただし、これだけでは「2つの層が互いを“補完”する」ことが、性能やセキュリティの観点で具体的な利点になると言い切るには足りません。私が資料から確認できた範囲で一番はっきりしているのは、実行（execution）が settlement から切り離されている、という関係性です。興味深いのは、Duskが modularity を使って settlement を別枠として保ちつつ、EVMによって開発者には門戸を開いていることです。
では、アプリケーションの採用が増えたとき、この execution と settlement の境界は、本当に優位性を生むのでしょうか。それとも、単にアーキテクチャ上の整理の仕方にすぎないのでしょうか？
#dusk $DUSK @Dusk $BTC
まずはアーキテクチャから始めます。Duskの資料では、DuskDSを「レイヤー（layer）」、つまり settlement と data availability を担う層と呼んでいます。そこではコンセンサス、ファイナリティ、そしてDuskネイティブのトランザクションモデルを扱います。一方のDuskEVMは、EVMと互換性のある実行環境で、Solidityのスマートコントラクトは、馴染みのあるツールチェーンで動かせます。さらに重要なのは、DuskEVMが settlement と data availability にDuskDSを使う点です。
これが単なる呼び方の話なのか、それとも責務の分離が本当に存在するのかを確かめたいと思いました。深く読むと、DuskDSはコンセンサス、ファイナリティ、data availability、そしてMoonlightやPhoenixのようなトランザクションモデルを処理していることが分かります。DuskEVMは実行に集中し、HardhatやFoundryに加えてEVMエコシステム全体を活用できるようにしています。片方が settlement の基盤を提供し、もう片方が実行を担う——そういう役割分担です。
ただし、これだけでは「2つの層が互いを“補完”する」ことが、性能やセキュリティの観点で具体的な利点になると言い切るには足りません。私が資料から確認できた範囲で一番はっきりしているのは、実行（execution）が settlement から切り離されている、という関係性です。興味深いのは、Duskが modularity を使って settlement を別枠として保ちつつ、EVMによって開発者には門戸を開いていることです。
では、アプリケーションの採用が増えたとき、この execution と settlement の境界は、本当に優位性を生むのでしょうか。それとも、単にアーキテクチャ上の整理の仕方にすぎないのでしょうか？
#dusk $DUSK @Dusk $BTC
