DuskEVMだと思っていたのは、Duskチームがゼロから手作業で作ったEVM互換のレイヤーだと思っていましたが、調べてみると基盤は直接OP Stack――つまりOptimismが提供するオープンソースのロールアップ・フレームワークを使っていることがわかりました。この発見によって、DuskEVMの位置づけについて新しい理解が得られました。

OP Stackは、イーサリアム・エコシステム内で検証されており、Optimism自身やBaseなど複数のLayer2チェーンで広く採用されているモジュール化フレームワークです。EVM互換の実行レイヤーを素早く構築するためのものです。Duskは新しく車輪を発明し直すのではなく、すでに大規模な実戦検証を経たこのフレームワークの上に立って、自分たちの実行環境を構築し、最終状態を基盤レイヤーであるDuskDSに決済させる、という形を取りました。

この選択はかなり実務的だと思います――ゼロから新しいEVM互換の仮想マシン一式を作るとなると、リスクも時間コストも決して小さくありません。特にDuskの中核チームの力は、本来、暗号学やコンプライアンスといった真の差別化領域にもっと注ぐべきでしょう。イーサリアム・エコシステムで広く検証済みの成熟したOP Stackを借りることで、重複した“車輪の再発明”にかかる膨大なエンジニアリング工数を節約できます。同時に、イーサリアム・エコシステムのロールアップ・ツールチェーンが継続的に進化していく恩恵を受けることもできます――OP Stack自体も絶えず進化しています。Duskがこの上流エコシステムの更新ペースに追随できれば、理論上はこの技術的な利得を継続的に享受でき、自分で仮想マシン技術スタック一式を個別に保守する必要はありません。

しかしその一方で、DuskEVMの安全性と性能が、ある程度はOP Stackという上流フレームワークの堅牢性に深く結びつくことも意味します。もし上流側で脆弱性が見つかったりアーキテクチャが変更されたりすれば、Dusk側も大概率その対応・修補を迫られます。完全に自主的で、完全に自律的に制御できる独立した技術スタックではありません。これは「巨人の肩の上に立つ」ことで必然的に受け入れるべき依存関係です。良い点は多くの労力を節約できることですが、代償として自律性が少し削られることになります。$DUSK

技術選定のような「成熟したフレームワークを借りるか、それとも自分で再発明するか」というトレードオフには、絶対の正解・不正解はありません。ただし、あるチェーンの基盤が自社開発なのか、第三者のアーキテクチャを借用しているのかを把握できれば、少なくともその技術リスクをどの“過去の実績”を参照すべきか、より正確に判断する助けになります。@Dusk #dusk