@Dusk doesntがすべてのトランザクションを1つのモデルに強制していないことに、ずっと気づいていました。

Moonlightはアカウントベースの構造を使い、PhoenixはUTXOアプローチを採用しています。最初は、それが不必要な複雑さに思えました。取引を表す方法を2通りも維持する必要があるのでしょうか。1つに絞ってアーキテクチャをもっとシンプルにできないのでしょうか？

調べれば調べるほど、その分離には意味があると感じました。アカウントベースの状態は、残高やアプリケーションロジックに対して素直で分かりやすい。Phoenixは、Duskに対して別のトランザクション構造を提供し、よりプライバシー志向のフローを支えられます。

その柔軟性は役に立ちます。

しかし、あまり十分に議論されていないと思うトレードオフがあります。追加のトランザクションモデルが増えるたびに、開発者と利用者が理解すべきメンタルモデルがもう1つ増えるのです。アーキテクチャはより高機能になる一方で、システム全体を理解しにくくなる可能性があります。

では、Duskにとって別々のトランザクションモデルを持つことは、実際に有益な柔軟性をもたらしているのでしょうか。それとも、やがてその追加の複雑さがメリットを上回ってしまうのでしょうか？

#dusk @Dusk $DUSK