別の角度からDuskEVMを見つめることになった。開発者がそれで何を構築できるかではなく、デプロイ後に実際に何が起きるのか。
アーキテクチャがより納得できるものになったのは、スタックを通してトランザクションを追跡したときだった。
Duskは実行と決済を分離する。
DuskEVMは、EVMアプリケーションが動く場所だ。
その下にDuskDSがあって、コンセンサス、決済、そしてデータ可用性のレイヤーを担っている。
最初は、それが実装上の細部のように聞こえる。
でも規制対象の資産では、それが本当にそうなのかは分からない。
トークン化された証券は、スマートコントラクトのロジックを実行するだけでは足りない。いずれ市場は、どの状態が実際に最終確定されたのか、そしてそれがいつなのかを把握する必要がある。
それによって、私はその分割の見方を変えた。
実行は何が起きるべきかを決める。
決済は、実際に何が起きたのかを確定する。
そしてDuskは意図的に、それらの仕事を別々のレイヤーに割り当てている。
面白いのは、DuskEVMがそこに至るために開発者向け環境をゼロから作り直す必要がないことだ。
Solidityアプリケーションは標準のEVMツールを使える一方で、生成された状態はDuskDSを通じて決済される。
だから問いは「なぜ別のEVMを作るのか」というよりも

そもそも、アプリケーション環境を決済レイヤーから切り離すのはなぜなのか？
通常のDeFiアプリなら、その違いはユーザーにほとんど影響しないかもしれない。
しかし規制対象の証券では、決済はプロダクトの一部だ。
所有権、移転、支払い、そして最終確定は、最終的に市場が信頼できる形にしていかなければならない。
そこでDuskのアーキテクチャは、単なる「追加機能付きのEVMチェーン」というよりも、金融インフラが常に担ってきた2つの異なる仕事を分離しようとする試みに見えてくる。
そして私には、もう1つ疑問が残る。
実行が柔軟で、下層の決済は決定論的なままでいるなら、その分離によって、同じ金融ベースレイヤー上で異なる規制市場アプリケーションを作りやすくなるのだろうか？

なぜなら、もしかするとDuskEVMで「面白い」のは、それが見た目に馴染みがあることではないからだ。

馴染みの部分が終わったあと、その下で何が起きるのか—そこにあるのかもしれない。

#dusk $DUSK @Dusk