「取引のための“夕暮れ（Dusk）”の受付」は、取引が行われる前の交換（exchange）側が“完了した”ものとして扱う形にできるとは限りません。
私は @Dusk の取引 API を読んでいて、いつもの最終性（finality）に関する議論以上に気になるステータスコードがありました：
202 Accepted。
Dusk のノードが、取引が伝播（propagated）された後に 202 を返す場合、それはその取引がルーティングのために受け付けられたことを意味します。
しかし、それはまだ、実際の mempool に入ったこと、ピアに到達したこと、正常に実行されたこと、あるいは最終化されたことを証明するものではありません。
それは小さな API の仕様のように聞こえます。
でも、出金（withdrawals）を処理する交換（exchange）にとってはそうではありません。
私は出金処理を、頭の中では次のようなものとして扱っていました：
取引を送信 → ネットワークが受け付ける → 最終性を待つ → 出金をクローズ。
しかし、その途中に“厄介な状態”があり、交換側は何かを送ったものの、経済的なアクション（economic action）を安全に完了として呼ぶのに十分な情報をまだ持っていないのです。
それが問題を変えます。
取引の提出（submission）と取引の完了（completion）は同じではありません。
そして、失敗した API リクエストをリトライすることが、必ずしも「元の出金は存在しなかった」と判断するのと同じではありません。
Dusk のドキュメントでも、署名サービスは nonce の割り当てをシリアライズし、送信済みの取引を保持し、nonce を再利用する前に保留（pending）およびコミット済み（committed）のアカウント状態を確認する必要があると警告しています。
ここが私にとって興味深い部分です。
決定的な最終性（deterministic finality）は、取引の終わりを非常に明確にすることができます。
しかし、それによって最終化に至るまでの“すべての状態”が、交換が同じくらい簡単に扱えるようになるわけではありません。
だから、もし私が真面目に Dusk を統合（integration）を評価するなら、決済速度（settlement speed）だけを測りたいとは思いません。
ノード障害、タイムアウト、曖昧な提出（ambiguous submissions）のときに何が起きるのかを知りたいです：
重複した指示（duplicate instructions）を作ったり、誰かに「何が起きたのか」を手動で判断させたりすることなく、自動的に回復できる出金はどれくらいあるのか？
おそらく最も良い取引インフラとは、失敗パスが“退屈”になるものではないでしょうか。
それは、ハッピーパスを速くするよりはるかに難しそうです。
#dusk $DUSK @Dusk
$GPS $TUT
私は @Dusk の取引 API を読んでいて、いつもの最終性（finality）に関する議論以上に気になるステータスコードがありました：
202 Accepted。
Dusk のノードが、取引が伝播（propagated）された後に 202 を返す場合、それはその取引がルーティングのために受け付けられたことを意味します。
しかし、それはまだ、実際の mempool に入ったこと、ピアに到達したこと、正常に実行されたこと、あるいは最終化されたことを証明するものではありません。
それは小さな API の仕様のように聞こえます。
でも、出金（withdrawals）を処理する交換（exchange）にとってはそうではありません。
私は出金処理を、頭の中では次のようなものとして扱っていました：
取引を送信 → ネットワークが受け付ける → 最終性を待つ → 出金をクローズ。
しかし、その途中に“厄介な状態”があり、交換側は何かを送ったものの、経済的なアクション（economic action）を安全に完了として呼ぶのに十分な情報をまだ持っていないのです。
それが問題を変えます。
取引の提出（submission）と取引の完了（completion）は同じではありません。
そして、失敗した API リクエストをリトライすることが、必ずしも「元の出金は存在しなかった」と判断するのと同じではありません。
Dusk のドキュメントでも、署名サービスは nonce の割り当てをシリアライズし、送信済みの取引を保持し、nonce を再利用する前に保留（pending）およびコミット済み（committed）のアカウント状態を確認する必要があると警告しています。
ここが私にとって興味深い部分です。
決定的な最終性（deterministic finality）は、取引の終わりを非常に明確にすることができます。
しかし、それによって最終化に至るまでの“すべての状態”が、交換が同じくらい簡単に扱えるようになるわけではありません。
だから、もし私が真面目に Dusk を統合（integration）を評価するなら、決済速度（settlement speed）だけを測りたいとは思いません。
ノード障害、タイムアウト、曖昧な提出（ambiguous submissions）のときに何が起きるのかを知りたいです：
重複した指示（duplicate instructions）を作ったり、誰かに「何が起きたのか」を手動で判断させたりすることなく、自動的に回復できる出金はどれくらいあるのか？
おそらく最も良い取引インフラとは、失敗パスが“退屈”になるものではないでしょうか。
それは、ハッピーパスを速くするよりはるかに難しそうです。
#dusk $DUSK @Dusk
$GPS $TUT