「Removed」という言葉を取引監視に入れると「失敗」と誤読されやすいですが、私は@Dusk のRUESイベントを見たときは一度止まります。取引がローカルmempoolから離れたことは、それがチェーン上で拒否されたことを意味しないからです。これは言葉遊びではありません。Duskの公式説明ではtransactions/removedは、単にそれがあるノードのローカルmempoolから離れたことを示すだけで、理由としては、ブロックに取り込まれたこと、高いgasPriceの競合取引に置き換えられたこと、期限切れになったこと、容量の都合で追い出されたこと、あるいは競合取引が単に離れただけである可能性があります。個別のこのイベントだけでは、最終結果はあなたに伝えてくれません。

これにより、$DUSK の開発者体験を改めて考え直しました。監視ツールがremovedを失敗にマッピングすると、バックエンドは早すぎる注意を出してしまいます。一方でそれを成功として扱うと、実際に淘汰された取引を見落とす可能性もあります。実際のステータスの1つのフィールドは、あるノードの「目の前で起きていること」と「台帳が最後に記録していること」を2層に分けています。プレッシャーの強い状況は実はよくあることで、ユーザーが送金した後、ウォレットはremovedを受け取り「リトライしてください」と提示します。ユーザーがその後もう一度送ると、最初の取引がすでにブロックに入っていたと分かり、結果として余計に1回ガスを支払うことになります。さらにカスタマーサポートも、どの取引が有効だったのか説明する必要が出てきます。エラーメッセージを台帳を見ずにイベントだけで判断すると、ローカル表示が事実として拡大されてしまうのです。

なので私は、RUESのremovedを失敗のシグナルだとはみなしません。@Dusk のドキュメントには、より確実な方向性が示されています。取引とブロックの状態を照会してから、リトライするかどうかを決めます。次は、ウォレットがユーザーに「ローカルで移出された」ことと「最終結果」を分けて表示しているかを確認します。これこそがDuskがユーザーに踏ませないための細部です。#dusk