#dusk $DUSK の権限はすでに出したが、両替は成立せず、担保（ステーキング）も停止した。この時点で資金は計画どおりには進まないのに、市場（マーケット）はまだ動いている。次は、権限の撤回、再発行、ヘッジ……どのステップもそのたびに追加でお金を払うことになる。----このような取引フロー設計に遭遇したとき、あなたはどう思う？

私は「Approve→Swap→Stake」というよくある流れを前提に、Duskの現状の取引構造と照らし合わせた。Dusk公式のRuskリポジトリでのオープンな議論では、現在のMoonlightまたはPhoenixの1取引は、トップレベルのアクションが1つだけで、取引フォーマットにもネイティブのBatchはまだないとされている。専用のルーティング用コントラクトがないため、3ステップがそれぞれ分けて送信される。最初のステップを一度確定してしまうと、2つ目が失敗しても、前のステップは一緒に撤回されない。

フロー設計で3ステップすべてがGasを別々に請求されるのを見たときは、正直$DUSK のために少し嬉しかった。でも、失敗後のポジションと、復旧にかかるコストを図にすると、その興奮は一瞬で消えた。きちんと最後まで通って発生するのは事業費（ビジネスフィー）だが、権限の撤回・リトライ・逆操作で発生するのは事故費（アクシデントフィー）だ。どちらの費用もDUSKを消費するが、長期的に見ると中身の価値（含金量）にはかなり差がある。

Duskはまず、ルーティングコントラクトに3ステップを代行させることは可能かもしれない。しかし、対象となるコントラクトの中には「目の前で手続きをしている人」を認識するものがある。彼らが見るのはルーティングコントラクトであり、実際のユーザーの権限まで認めない可能性がある。プロトコル層のネイティブBatchであればユーザーのアイデンティティを保持できるが、その代わりに取引フォーマット、ノード、ウォレットのすべてを一緒にアップグレードする必要がある。私はふと、「この問題は解きにくいかもしれない」と感じた。

ただ、PhoenixにはDusk専用のカードがある。プライバシー証明は、呼び出し内容の「指紋」だけを記録し、内部の各ステップを理解する必要がない。将来的にBatchが追加されるとしても、理論上はプライバシー回路や一式の証明パラメータを作り直さずに済む可能性がある。だからDuskは、複雑なフローを「全て成功 or 全て取り消し」にまとめるチャンスがあり、改造コストもより低く抑えられるかもしれない。

$DUSK については、単一フローのGasコストを、完全成功率、復旧（補救）取引の比率、ユーザーの再利用率と同じ表に並べて考えるべきだと思う。ボタンを押すたびに課金するだけでは不十分だ。ひとまとめの取引で高い費用対効果を保ちながら完遂でき、ユーザーが次の資金も継続してチェーン上に置く気になる。

お金も節約できて、体験もスムーズ。どの取引がそれに抗えよう？これは私が$DUSK の長期的なバリュエーション（評価）を考える際の、指標の一つでもある。
@Dusk

$BTC