もう一度、Duskのモジュラー・アーキテクチャを見ていたんだけど、図を「3つの別々のチェーン」として見ようとやめると、ずっと分かりやすくなった。

実際には、スタック全体で役割が3つに分かれているだけなんだ。

1. DuskDS — 基盤レイヤー

これは土台だ。

DuskDSは、以下の基盤となるネットワーク機能を担う：

* コンセンサス
* データ可用性
* 決済

つまり、あらゆる実行責任を基盤レイヤーに詰め込むのではなく、DuskDSは基盤システムを調整し、決済までを適切に行えるようにすることに集中している。

2. DuskEVM — 互換レイヤー

ここでEVMの実行が登場する。

面白いのは単に「DuskはEVMに対応している」ということじゃない。

EVMの実行が、モジュラー・アーキテクチャの中で独自のレイヤーとして用意されている点なんだ。これにより、基盤のDuskDSレイヤーとは分離しつつ、開発者にはより馴染みのある環境を提供できる。

その分離によって、アプリケーションを作る際に必要となる統合作業の量を減らせる可能性がある。

3. DuskVM — プライバシー実行レイヤー

そしてDuskVMがある。

その役割はまた別で、プライバシーに重点を置いた実行だ。

つまり、アーキテクチャがパブリック型のEVM実行と、プライバシー志向の実行をまったく同じ環境に押し込むわけではない。

それらは、それぞれ独自の実行パスに分けられている。

そして、その全体の設計をつなぐ要素が2つある。

4. スタック全体にわたる1つのDUSK

アーキテクチャは、レイヤー間を通して単一のDUSKトークンを維持する。

これは重要だ。モジュラーな実行が必ずしも経済が分断されることを意味しないからだ。

実行環境は分離できても、トークン経済は統一されたまま保てる。

5. DuskDSとDuskEVMの間のネイティブブリッジ

さらに、レイヤーが孤立した島のように振る舞うことも想定されていない。

アーキテクチャでは、DuskDSとDuskEVMの間にネイティブ・ブリッジの概念があると説明されており、これにより実行レイヤーが基盤となるDuskシステムへ戻る道筋を持てるようになる。

図そのものよりも、僕がこの点をより面白いと感じた。

アーキテクチャは基本的にこう言っている：

DuskDSが土台を扱う。

DuskEVMがEVMの実行を扱う。

DuskVMがプライバシー志向の実行を扱う。
$DUSK #dusk @Dusk