#dusk $DUSK @Dusk 以前、私はオンチェーン決済をする際に、注文番号をついでにmemoにそのまま差し込むのが習慣でした。しかし、@Dusk のTransaction Lifecycleドキュメントを読んだあと、この習慣はそのまま移植できないと気づきました。というのも、Duskの取引データはmemo、コントラクト呼び出し、コントラクトのデプロイ、blobの間で単一選択（どれか一つ）になっており、memoは他のpayloadと一緒にデフォルトで同梱されるわけではありません。この違いは、決済システムのつなぎ方を直接変えてしまいます。加盟店が入金を受けるだけでなく、コントラクト呼び出しまで完了させる必要があるなら、注文番号を同一トランザクションのmemoにそのまま入れ続けよう、とは考えられません。クライアント側はまず、この取引の主目的（メインタスク）を決め、その上で注文との関連付け用に別の信頼できる記録を設計する必要があります。プレッシャーのかかる状況は実際かなり具体的で、ユーザーがコントラクト動作を含む支払いを送信するとフロントエンドは「送信済み」と表示する一方、バックエンドはmemoで注文を照合します。結果として金額は入ってくるのに、注文番号が期待どおりに表示されず、カスタマーサポートは取引を手作業で調べるしかありません。これはDuskがデータを失ったのではない可能性もあり、より可能性が高いのは、接続側が他チェーンの取引の慣習を無理やり流用してしまったことです。だからこそ、今私はDUSKの決済統合を見るとき、「送金が成功するかどうか」だけは聞かず、取引が実際に運ぶのがmemoなのか、あるいはコントラクト呼び出しかをまず確認し、その後で注文との関連付けが独立して再検証できるかも確認します。@Dusk はpayloadの境界を明確に書きましたが、開発者がこのような誤用を事前に避けられるよう、例がその目的に役立つかどうかが、Duskが実際の決済シーンに入った後により検証されるべき点だと思っています。