#dusk $DUSK @Dusk
Duskの全スタックはモジュール式に構築されています。DuskDSは決済およびデータ可用性レイヤーであり、Succinct Attestationコンセンサスを実行し、ステーキングを扱い、基礎となるDUSK資産を保持します。DuskEVMは独立したSolidity互換の実行レイヤーで、OP Stack（op-gethを動かすシーケンサーと、トランザクションデータをブロブとしてDuskDSに投稿するバッチャー）上に構築されており、独自のインディペンデントなセキュリティに依存するのではなく、DuskDSへ決済を戻します。DuskVMはさらに、Rust/WASMコントラクト向けのネイティブ実行環境で、ネイティブなプライバシーやプロトコルレベルの統合を必要とするアプリケーションを対象に、まだ新しく立ち上がりつつあります。PiecrustはWasmランタイム（Wasmerに基づく）で、もともとはDuskDSに組み込まれていましたが、現在はDuskVMへ抽出されています。ネットワーキングはKadcast上で動作します。これは、ランダムなゴシップではなく、構造化されたKademliaスタイルのブロードキャストプロトコルです。

このアーキテクチャの背景にある考え方は、「すべてのための1つの実行環境」では、DeFi型の合成可能性と規制対象の資産発行を同時に提供しようとするチェーンではうまく機能しない、というものです。Solidity開発者をネイティブのRust/WASM環境に無理に寄せるのではなく、あるいはネイティブなプライバシーアプリケーションをEVMの制約に無理に押し込むのでもなく、決済とコンセンサスは共通のベースレイヤーに置き、実行環境はその上で専門化します。Kadcastも同様のロジックに合致しています。構造化されたブロードキャストは、最終性を確率的に扱うチェーンよりも、「決定的な最終性」を主張するチェーンにとって重要となる、より予測可能な帯域幅とレイテンシをもたらすからです。

実行と決済を分離することは、さらに、DuskEVMの保証の強さが、それをDuskDSへ接続するブリッジとバッチング機構にしか依存しないことも意味します。DuskVMがDuskEVMと並行して成熟していくにつれ、ネットワークは1つの決済レイヤーに対して3つの実行サーフェスを走らせることになります。この分割は本当に、開発者の統合の摩擦を減らすのでしょうか。それとも、「どのVMを使うべきか」という複雑さを、「私の保証を実際に保持しているのはどのレイヤーか」という複雑さへ移しただけなのでしょうか？