#dusk $DUSK @Dusk
かつて私は、重い計算を基盤レイヤーから切り離すことは、ただのパフォーマンス上の勝ちだと思っていました。ところが実際にその上で何が起きるのかを調べ始めると、見方が変わりました。
DUSKのアーキテクチャは、意図的に清算(セトルメント)と実行(エクゼキューション)を分離しています。公式ドキュメントではDuskDSを清算およびデータ可用性レイヤーとして説明している一方で、DuskVMとDuskEVMがアプリケーションの実行を担います。さらに、以前のアーキテクチャ資料では、DuskDSは有効な証明を保存し、重い実行状態はアプリケーションレイヤーに存在するとされています。
これは美しい設計ですが、複雑さが消えるわけではありません。
複雑さを抱える相手が変わるだけです。
規制された金融を行うアプリケーションであっても、それぞれに独自の実装ロジック、アイデンティティのフロー、資産ルール、そして運用インフラが必要になります。たとえばDusk Tradeは、ベースプロトコルの上に位置し、オンボーディング、ウォレット接続、トレーディング、清算の調整などのワークフローを扱います。
そして別のコストもあります。自分を証明することは計算的に負荷が高いのです。Duskのドキュメントでは、専用のプローヴァ(証明生成)インフラがZK証明の生成における重い作業を担うと記されています。
つまり、興味深い問いは「DUSKがベースレイヤーの複雑さを減らすのかどうか」ではありません。
減らします。
難しい問いは、規制された各ユースケースが上へ押し上げるその複雑さを、アプリケーション開発者が吸収できるのか、それを自分たち自身のエンジニアリングおよび運用上の負担に変えずに済むのか、という点です。
ここで、アーキテクチャの効率性が経済的な現実と交わります。
#Dusk #GrowWithSAC $ZRO $BMT
かつて私は、重い計算を基盤レイヤーから切り離すことは、ただのパフォーマンス上の勝ちだと思っていました。ところが実際にその上で何が起きるのかを調べ始めると、見方が変わりました。
DUSKのアーキテクチャは、意図的に清算(セトルメント)と実行(エクゼキューション)を分離しています。公式ドキュメントではDuskDSを清算およびデータ可用性レイヤーとして説明している一方で、DuskVMとDuskEVMがアプリケーションの実行を担います。さらに、以前のアーキテクチャ資料では、DuskDSは有効な証明を保存し、重い実行状態はアプリケーションレイヤーに存在するとされています。
これは美しい設計ですが、複雑さが消えるわけではありません。
複雑さを抱える相手が変わるだけです。
規制された金融を行うアプリケーションであっても、それぞれに独自の実装ロジック、アイデンティティのフロー、資産ルール、そして運用インフラが必要になります。たとえばDusk Tradeは、ベースプロトコルの上に位置し、オンボーディング、ウォレット接続、トレーディング、清算の調整などのワークフローを扱います。
そして別のコストもあります。自分を証明することは計算的に負荷が高いのです。Duskのドキュメントでは、専用のプローヴァ(証明生成)インフラがZK証明の生成における重い作業を担うと記されています。
つまり、興味深い問いは「DUSKがベースレイヤーの複雑さを減らすのかどうか」ではありません。
減らします。
難しい問いは、規制された各ユースケースが上へ押し上げるその複雑さを、アプリケーション開発者が吸収できるのか、それを自分たち自身のエンジニアリングおよび運用上の負担に変えずに済むのか、という点です。
ここで、アーキテクチャの効率性が経済的な現実と交わります。
#Dusk #GrowWithSAC $ZRO $BMT
Who absorbs the burden?
Apps or base layer?
Does complexity vanish?
5 残り日数

