DuskのMoonlight取引の取り扱いにおける小さな変更が、私の注意を引きました。将来-nonceの取引は、もはやただちに拒否される必要がなくなったのです。DuskがEUライセンスを持つ機関とともにオンチェーンでの金融市場の実現を目指す中で、この種の取引状態の区別は、最初に思うよりも重要になってきます。つまり、Duskはこれらの将来-nonce取引を、先行して欠けている取引が到着するまでキューに積んでおけるのです。これにより、「accepted（受理済み）」が意味するものが変わります。
キューに入れられた取引はDuskによって受け取られていますが、ブロックに含める準備ができているとは限りません。
まだ分からないのは、Duskがその延期された状態を、実際の掲載（inclusion）の準備完了状態と明確に切り分けたままにしているのか、それとも受理が、取引がすでに前進できる証拠として読み取られすぎてしまうのかという点です。
注目すべき詳細は、欠けているnonce依存関係、延期（deferred）のライフサイクル状態、そして取引が掲載対象として適格になる地点です。
ノードがその取引を受け入れることは有益な情報です。ただし、それが前進を妨げている依存関係が実際に解消されたことを知るよりは、進展の証拠としては弱くなります。
私は、Duskが将来-nonceの取引をどれだけ速く受理するかよりも、その状態が、掲載が可能になるまでにまだ何が起きる必要があるのかを私にどれだけ教えてくれるかを重視します。
「received（受領）」「deferred（延期）」「ready for inclusion（掲載準備完了）」は、ユーザーがpending（保留）として読んでしまう可能性のある単なる別ラベルではなく、意味のある異なる状態として維持されるのかどうかが問題です。
私は、Duskがキューから本当に掲載準備が整った状態への移行をどのように公開しているかを見ています。

@Dusk $DUSK #dusk