私は、オンチェーンで3つのこと（承認、スワップ、そしてステーク）を行いたいなら、チェーンはそれを1つの出来事として扱うか、あるいはまったく起きないものとして扱うのだと思っていました。しかし、Dusk自身のRuskリポジトリにある未解決の課題は、それは今日の仕組みではないと言っています。

Duskのトランザクションは現在、単一の任意の操作を持ちます。つまり、1つのコントラクト呼び出し、1つのデプロイ、または1つのメモで、値、受取人、nonce、署名はそれぞれ1つです。したがって、承認、スワップ、ステークは3つの別々のトランザクションになり、それぞれが独立して含まれるか、あるいは破棄されます。Duskの課題ははっきり述べています。これらの間に原子的（atomic）な保証は存在しない、と。承認とスワップは行ってステークだけ行われず、フローの途中で残されても、プロトコルレベルでのロールバックはありません。

問題は、マルチステップのフローが途中で止まることだけではありません。それを修正すると、互換性コストを誰が負担するのかが変わります。

バッチャーのコントラクトなら、失敗したサブコールが外側のトランザクションをロールバックするため、シーケンス全体を原子的にできます。しかし、直接呼び出している相手をチェックするターゲット・コントラクトの側から見ると、呼び手はあなたではなくバッチャーになります（そのコントラクトが、直近の呼び出し元を超えて見に行くように既に書かれていない限り）。一方、プロトコルレベルのバッチトランザクションは、各ステップであなたを呼び手として維持しますが、新しいトランザクション形式、コンセンサスの変更、ハードフォーク、そしてすべてのウォレットSDKの追随なしには出てきません。

バッチを追加してもトレードオフは消えません。互換性の負担を、アプリケーションの認可側に置くのか、プロトコルスタック側に置くのかを決めるだけです。

"原子的（atomic）な保証を直してもトレードオフは消えません。互換性の負担と信頼境界がどこに移動するかを決めるだけです。"

私が本当に注目して見たいのは、Duskがアプリケーションレベルのバッチャーを採用するのか、プロトコルレベルのトランザクションを採用するのか、そしてその選択が、既存の認可に関する前提として開発者にどんな変更を強いるのか、という点です。

#dusk $DUSK @Dusk