夕暮れ　現在のアーキテクチャには、非常に明確な特徴がある——それは意図的に「分解」していることだ。

ほとんどのパブリックチェーンが合意形成・実行・決済を一つのモノリシックなスタックに詰め込むのとは違い、Dusk はこの3つを切り離した。いちばん下にあるのが DuskDS で、合意形成・データ可用性・決済を担う。中間に DuskEVM がぶら下がり、Solidity を完全に互換するため、開発者はイーサリアムから移行してもコードをほとんど改修せずに済む。さらに最上部には DuskVM があり、ネイティブのプライバシーアプリだけを専門に実行する。3層それぞれが一式ずつ受け持ち、同じ DUSK トークンでつなぎ込む。

この選択の動機は難しくない。自前で完結するチェーンを作ると、最大の代償は開発者がツールチェーンを学び直さなければならないことだ。エコシステムの立ち上がりは非常に遅くなる。EVM 層を載せれば、Solidity、Hardhat、MetaMask といった既製のものをそのまま使えるため、開発者を呼び込む際の摩擦が一気に下がる。

しかし、この選択の代償もまた、非常にストレートに存在する——複雑性が増え、しかも増える場所が最も致命的なところにある。

層をまたぐ流動性は、新しい信頼の前提と攻撃面を生む。資産が DuskDS と DuskEVM の間を移動するにはネイティブのブリッジングが必要で、資産のラップやカストディアンは不要だとしても、層間そのものが追加の検証ステップを導入してしまう。過去数年、層間設計に起因する事故は、仮想マシンそのものに起因する事故よりもはるかに多かった。

もう一つ、見落とされやすい問題がある——ノードの分布だ。Dusk は SBA 合意を採用しており、ノードは継続的にオンラインであること、そして適切に設定されていることが求められる。これらのハードルはネットワークのセキュリティを保証する一方で、普通の参加者が長期にわたってノードを運用するためのハードウェアおよび運用コストが低くないことも意味している。ノードが徐々に少数の大口へ集中してしまえば、どれほど良いアーキテクチャでもその味が変わってしまう。

だから私は今、Dusk を見ていて、注目しているのは何層あるかとか、TPS がいくつかといった点ではない。見るべきことは2つある。1つ目は、層間にまたがる資産の状態とプライバシーの境界が、きちんと説明されているかどうか。2つ目は、EVM 層上に現れているアプリのタイプ——もしすべてが移植された汎用プロトコルなら、モジュール化はただ募集方法を変えただけのことになる。逆に、アプリが実際に基盤の秘匿機能を呼び出している（たとえば Hedger の暗号化注文帳や XSC 標準の秘匿証券を使うなど）なら、そのアーキテクチャの差別化が本当に活用されているといえる。

アーキテクチャが組み上がったら、次はその上に何が育っていくのかを見る番だ。#dusk $DUSK @Dusk