Я думаю, что мы обычно задаём неправильный вопрос, когда Dusk-транзакция «не проходит».
Статус 202 Accepted означает только то, что узел принял запрос для маршрутизации. Это не значит, что транзакция уже находится в mempool или в блоке. Один из примеров, который мне показался интересным, — это будущий nonce. Если транзакция Moonlight приходит с будущим nonce, пока более ранний nonce всё ещё отсутствует, Dusk может держать её вне реального mempool и ждать, пока заполнятся разрывы по nonce, вместо того чтобы сразу отклонить её. На это время у неё появляется отложенное состояние.
Это лишь часть истории. Как только транзакция проходит допуск, она попадает в локальный mempool этого узла. Другие узлы сохраняют свои собственные mempool и выполняют собственные проверки допуска. Позже транзакцию могут выбрать для блока, выполнить и в итоге финализировать. Она также может выйти из локального mempool без того, чтобы это автоматически означало провал. Истечение, замена, ограничения по ёмкости и конфликты — всё это может привести к удалению.
И вот здесь, как мне кажется, разница важна для кошельков и бирж. В руководстве по интеграции Dusk сказано: хранить точную подписанную транзакцию, считать 202 Accepted лишь успешной маршрутизацией и повторно транслировать те же самые подписанные байты после таймаута транспорта, а не создавать новую транзакцию вслепую. Списание (withdrawal) следует помечать как завершённое только после того, как проверено выполнение и блок финализирован.
Чем больше я в это вникал, тем меньше фраза «transaction submitted» (транзакция отправлена) звучала как полезный статус сама по себе. Транзакция может ждать nonce, находиться в mempool одного узла, быть выполненной с ошибкой или находиться в блоке, который ещё не финализирован. Это совершенно разные ситуации, даже если снаружи они все могут выглядеть как «всё ещё ожидает».
Для меня полезный вывод из процесса транзакций Dusk такой: submitted — это только начало. Важно то состояние, до которого вы реально можете доказать, что транзакция дошла.
$DUSK @Dusk #dusk
Статус 202 Accepted означает только то, что узел принял запрос для маршрутизации. Это не значит, что транзакция уже находится в mempool или в блоке. Один из примеров, который мне показался интересным, — это будущий nonce. Если транзакция Moonlight приходит с будущим nonce, пока более ранний nonce всё ещё отсутствует, Dusk может держать её вне реального mempool и ждать, пока заполнятся разрывы по nonce, вместо того чтобы сразу отклонить её. На это время у неё появляется отложенное состояние.
Это лишь часть истории. Как только транзакция проходит допуск, она попадает в локальный mempool этого узла. Другие узлы сохраняют свои собственные mempool и выполняют собственные проверки допуска. Позже транзакцию могут выбрать для блока, выполнить и в итоге финализировать. Она также может выйти из локального mempool без того, чтобы это автоматически означало провал. Истечение, замена, ограничения по ёмкости и конфликты — всё это может привести к удалению.
И вот здесь, как мне кажется, разница важна для кошельков и бирж. В руководстве по интеграции Dusk сказано: хранить точную подписанную транзакцию, считать 202 Accepted лишь успешной маршрутизацией и повторно транслировать те же самые подписанные байты после таймаута транспорта, а не создавать новую транзакцию вслепую. Списание (withdrawal) следует помечать как завершённое только после того, как проверено выполнение и блок финализирован.
Чем больше я в это вникал, тем меньше фраза «transaction submitted» (транзакция отправлена) звучала как полезный статус сама по себе. Транзакция может ждать nonce, находиться в mempool одного узла, быть выполненной с ошибкой или находиться в блоке, который ещё не финализирован. Это совершенно разные ситуации, даже если снаружи они все могут выглядеть как «всё ещё ожидает».
Для меня полезный вывод из процесса транзакций Dusk такой: submitted — это только начало. Важно то состояние, до которого вы реально можете доказать, что транзакция дошла.
$DUSK @Dusk #dusk
