@Duskdoesnt について見落とされがちな「1つのこと」にいつも戻ってしまいます。それは、すべての取引を単一のモデルに押し込むようなことを強制しない点です。
Moonlight はアカウントベースの構造を使っていて、Phoenix は UTXO のアプローチを取っています。最初はその判断に疑問を持ちました。なぜ、1つのモデルでアーキテクチャを理解しやすくできるのに、取引を表す方法を2通りも用意する必要があるのでしょうか？
でも深く見るほど、より戦略的なものに思えてきます。
アカウントベースの状態は残高やアプリケーションのロジックを扱いやすくし、一方で Phoenix の UTXO 設計は、プライバシー志向の取引フローにより多くの余地を作ります。
それにより、Dusk は本当に重要なところで柔軟性を得られます。
それでも、そのトレードオフを無視してはいけないと思います。
追加のモデルが増えるほど、開発者・ユーザー・ツール・インフラが理解すべき別のレイヤーも増えます。できることが増えるほど、複雑さも増える可能性があります。
私にとって本当の問いは、Dusk が両方をサポートできるかどうかではありません。
この2つのモデルが、追加される認知的・エンジニアリング上の負担に見合うだけの実用的な価値を生むかどうかです。
もし生むのなら、それは不要な複雑さではありません。
それはアーキテクチャ上のオプショナリティです。
そして、それが Dusk の最大級の強みの1つになり得ます。
#dusk $DUSK @Dusk