Когда я переводил документацию по жизненному циклу транзакции Dusk @Dusk , я лишь тогда исправил одну ложную интерпретацию: ответ интерфейса 202 Accepted означает только, что узел принял запрос. После отправки подписи в Dusk L1 узел сначала выполняет admission; только после успешной проверки транзакция попадает в real mempool и рассылается peers, а создатель блока сортирует выполнение по gasPrice.

Я воспринимаю это как конвейер расчётов. 202 — это приём на входе, included — попадание в зону ожидания, а executed ещё требует проверить, что err равно null. Даже после того как блок принят, он всё ещё может быть reverted, и лишь когда blocks/statechange сообщают finalized, книга учёта действительно закрывается. Moonlight выявляет конфликты по аккаунту и nonce, Phoenix смотрит на nullifier; для замены транзакции нужно повысить gasPrice.

Эта цепочка событий применима только к Dusk L1, а у DuskEVM есть отдельные модели sequencer и finality. Когда я пишу слушатель, я сохраняю tx hash и координаты блока, а затем проверяю через onlyFinalized:true. Если смотреть только на included, при замене узла, истечении срока или вытеснении из-за переполнения легко принять локальное состояние за фактическое зачисление. Квитанция — лишь запись о приёме; подтверждение средств нужно ждать до окончательного состояния.

#dusk $DUSK