「Dusk のトランザクションが“失敗する”」とき、私たちは通常、間違った質問をしていると思います。

202 Accepted になったとしても、それはノードがルーティングのためのリクエストを受け付けたことを意味するだけです。トランザクションがすでにメンプールに入っている、またはブロックに入っていることを意味しません。興味深い例として、未来の nonce があります。より古い nonce がまだ欠けている状況で、Moonlight のトランザクションが将来の nonce とともに到着した場合、Dusk はそれを実メンプールの外に保持し、nonce のギャップが埋まるのを待つことができます。つまり、即座に拒否するのではなく、その間、延期された状態になります。

ただし、それは話の一部にすぎません。トランザクションがアドミッション（入場）を通過すると、そのノードのローカルメンプールに入ります。ほかのノードもそれぞれ独自のメンプールを持ち、独自のアドミッションチェックを行います。のちに、トランザクションがブロックとして選択され、実行され、最終的に確定（ファイナライズ）されることもあります。また、ローカルメンプールから離れることもあり、そのことが自動的に「失敗した」ことを意味するわけではありません。期限切れ、置換、キャパシティ制限、競合などが削除につながり得ます。

ここが、ウォレットや取引所にとって違いが重要だと思うところです。Dusk の統合ガイダンスでは、正確な署名済みトランザクションを保持し、202 Accepted は成功したルーティングとして扱い、トランスポートのタイムアウト後は新しいトランザクションを闇雲に作らず、同じ署名バイト列を再送するように求めています。出金は、実行が確認され、ブロックがファイナライズされた後にのみ完了としてマークすべきです。

調べれば調べるほど、「transaction submitted（トランザクション送信済み）」という表現は、それ自体ではあまり有用なステータスには聞こえなくなりました。トランザクションは、nonce を待っていたり、あるノードのメンプールに滞留していたり、エラー付きで実行されたり、まだ最終でないブロックに入っていたりします。これらは、外から見るとすべて「まだ保留中」に見えることがあっても、状況としてはまったく異なります。

私にとって、Dusk のトランザクションフローから得られる有用な教訓はこうです。submitted は始まりにすぎません。重要なのは、そのトランザクションが実際に到達したと“証明できる”状態です。

$DUSK @Dusk #dusk