#dusk $DUSK @Dusk ......Duskのトランザクションモデルは、より小さな実装上の詳細に留まると思っていました。ですが、より深い問題は気づきにくいものでした。つまり、1つのユーザーの意図が、なお複数の独立したトランザクションを必要とし得るという点です....
ブロックチェーンのトランザクションを、封をした指示（命令）のようなものだと思ってください。あなたの行動に5つの命令が必要なら、それらをまとめて署名したとしても、ネットワークがそれらを自動的に1つの行動として扱うとは限りません。あるものは実行され、別のものは失敗することがあるのです。
それが、Issue #4058 でDuskが調べている問題です.....
今日では、MoonlightまたはPhoenixのトランザクションには、単一のオプションであるTransactionData操作しか含められません。そのため、approve → swap → stake のようなフローは複数のトランザクションに分割する必要があり、それぞれに署名、nonce、そしてインクルージョン（取り込み）のリスクが伴います。
さらに深く....
Duskは、ユーザーのアイデンティティのもとで複数のコントラクト呼び出しを原子的に実行できる、プロトコルレベルのバッチトランザクションを検討しています。そうすれば、各操作がそれぞれ独自の値やデポジットを持つことも可能になり、さらに移転回路や信頼できるセットアップを変えずに、Phoenixをカバーできる可能性もあります...
ですが、別のルートもあります。
バッチャーのコントラクトが、プロトコルを変えずに複数の呼び出しを実行できます。トレードオフは認可（オーソリティ）です。caller() を使うコントラクトは、元のユーザーではなくバッチャーを見ることになり得ます。一方で public_sender() は、元の Moonlight アカウントを保持できます。
この違いに私は注目しました....
バッチ処理の難しさは、いくつかの呼び出しを1つのコンテナに詰め込むことではありません。問題は、それらの呼び出しが1つの状態遷移になったときに、「アイデンティティ、ガス、値、失敗」が何を意味するのかを定義することです。
そして #4058 はまだ未解決であり、実際の実装とプロトコル仕様は、フォローアップ作業として明示的に残されたままです.....
金融ワークフローを対象とするチェーンにおいて、原子的なマルチステップ実行をプロトコルのプリミティブにすべきでしょうか、それともコントラクト同士が組み合わせて実現するもののままであるべきでしょうか？
$ADA $TUT