Dusk L1 にトランザクションを送信するアプリを構築しているとき、ノードからの成功した応答は、ユーザーに対して「アクションがうまくいった」と伝えるための分かりやすいタイミングに見えます。

しかし、Dusk のトランザクションのライフサイクルをもう少し注意深く追うまで、私はそのように読んでしまっていました。伝播（プロパゲーション）エンドポイントからの `202 Accepted` は、ノードがルーティングのためにそのトランザクションを受け付けたことを意味するだけです。トランザクションがブロックに到達したこと、正常に実行されたこと、あるいは最終状態（ファイナリティ）になったことを意味しません。

このため、「単純にトランザクションを送る」ためのインテグレーションに見えていたものが、状態の追跡に近いものになります。トランザクションが実行されると、Dusk は `err` フィールドを公開します。ここで `null` は実行が成功したことを意味します。それでも、受け入れられたブロックが後に取り消される（リバートされる）可能性はあります。ファイナリティは、ブロックが `finalized` 状態に到達したときに到来します。

これは、ビルダーの仕事を有用な形に分類し直すものだと思います。

単にボタンをエンドポイントにつないで、HTTP の成功を待つだけではありません。あなたは、アプリが「完了」としてユーザーに提示することに実際に同意しているネットワークの状態を決めているのです。

「Submitted」はある状態です。

「Executed successfully（正常に実行された）」は別の状態です。

「Final（ファイナル）」が、ループを締める状態です。

@Dusk $DUSK #dusk