Duskの市場インフラのドキュメントを読みながら、決済（payment）の箇所で引っかかり続けていました。資産移転そのものは、イメージするのは難しくありません。しかし厄介なのは、決済がそれに“噛み合う”必要があるときからです。
Duskは、Delivery-versus-Payment（DvP）を単なる別のトークン移転ではなく、ワークフロー上の問題として扱っています。資産側レグと決済側レグは、Duskの実行パスを通じて連携させることができ、DuskDSは、その下で決済（settlement）と決定論的なファイナリティ（deterministic finality）を提供します。つまり、面白いのは本当に“両方の資産を同じチェーンに載せること”ではありません。予測可能に決済するために、2つの状態変更をきちんと揃えることです。
この考え方は良いと思いますが、同時に、プロトコルがここで行っていることを過大に言いすぎるのも簡単だとも思います。
Duskは、この連携のための部品を提供します。実際のアプリケーション側では、資産・決済・適格性（eligibility）・決済条件がどう組み合わさるかを定義する必要があります。Dusk自身のドキュメントでも、異なるプロダクトがこのワークフローを別の方法で実装できることがかなり明確に書かれています。
これが重要なのは、DvPが外から見ると誤解されるほど単純に見えることがあるからです。セキュリティを移し、決済を移し、「決済完了（settled）」と言ってしまう。でも実際の規制されたワークフローでは、この2つのレグの周りに、さらに多くの条件が存在します。
なので、Duskがどこかで連携（coordination）の問題をなくしたとは言えません。連携を、決定論的なファイナリティを備えた共通の決済基盤へと移したのです。
実際のデプロイでまだ確認したい点は、かなり絞られています。つまり、片方のレグがアプリケーションレベルの条件を満たせない場合、もう一方のレグは正確にどんな状態のままになるのか、そしてワークフローはどれくらいの速さで安全に巻き戻せるのか、です。
#dusk $DUSK @Dusk $ACE
Duskは、Delivery-versus-Payment（DvP）を単なる別のトークン移転ではなく、ワークフロー上の問題として扱っています。資産側レグと決済側レグは、Duskの実行パスを通じて連携させることができ、DuskDSは、その下で決済（settlement）と決定論的なファイナリティ（deterministic finality）を提供します。つまり、面白いのは本当に“両方の資産を同じチェーンに載せること”ではありません。予測可能に決済するために、2つの状態変更をきちんと揃えることです。
この考え方は良いと思いますが、同時に、プロトコルがここで行っていることを過大に言いすぎるのも簡単だとも思います。
Duskは、この連携のための部品を提供します。実際のアプリケーション側では、資産・決済・適格性（eligibility）・決済条件がどう組み合わさるかを定義する必要があります。Dusk自身のドキュメントでも、異なるプロダクトがこのワークフローを別の方法で実装できることがかなり明確に書かれています。
これが重要なのは、DvPが外から見ると誤解されるほど単純に見えることがあるからです。セキュリティを移し、決済を移し、「決済完了（settled）」と言ってしまう。でも実際の規制されたワークフローでは、この2つのレグの周りに、さらに多くの条件が存在します。
なので、Duskがどこかで連携（coordination）の問題をなくしたとは言えません。連携を、決定論的なファイナリティを備えた共通の決済基盤へと移したのです。
実際のデプロイでまだ確認したい点は、かなり絞られています。つまり、片方のレグがアプリケーションレベルの条件を満たせない場合、もう一方のレグは正確にどんな状態のままになるのか、そしてワークフローはどれくらいの速さで安全に巻き戻せるのか、です。
#dusk $DUSK @Dusk $ACE