Перейти к содержанию
Financial Context Wiki

Как устранить разрыв nonce в кошельке

Найдите первый пропущенный nonce EVM-аккаунта, решите, заменить или отменить транзакцию, и предотвратите очередь между кошельками или устройствами.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

В EVM-совместимой сети транзакции одного внешнего аккаунта (EOA) исполняются по порядку nonce. Если следующий исполнимый nonce отсутствует или завис, транзакции с большими nonce могут оставаться в очереди даже при высокой комиссии. Сначала устраните наименьший нерешённый nonce: проверьте сеть и отправителя, сопоставьте подтверждённые и ожидающие данные nonce, затем замените нужную транзакцию или противопоставьте ей отменяющую транзакцию с тем же nonce.

Отмена не является откатом на уровне протокола. Обычно это перевод 0 ETH с аккаунта самому себе, конкурирующий за тот же nonce. Побеждает валидная транзакция, первой попавшая в блок; подтверждённую транзакцию так отменить нельзя.

Процедура относится к обычным EOA-транзакциям EVM. Смарт-аккаунты и операции абстракции аккаунта могут использовать заданные контрактом схемы nonce, а UTXO-сети используют другую модель.

Почему разрыв nonce блокирует очередь

Nonce EOA — последовательный счётчик. Для одного nonce может исполниться только одна транзакция, и аккаунт не может исполнить nonce 26 раньше nonce 25. Поэтому узлы отделяют сразу исполнимые транзакции от транзакций с большими nonce, ожидающих будущего исполнения.

Очередь не является единым глобальным достоверным mempool. Каждый RPC-узел видит и хранит свой набор ожидающих транзакций. Транзакция может отображаться в кошельке, но не в обозревателе, либо быть видимой через один RPC и отсутствовать через другой. Возможно, её не транслировали, узел удалил её из пула или она ещё не дошла до опрашиваемого сервиса.

eth_getTransactionCount с latest возвращает счётчик в состоянии последнего блока; для EOA это следующий nonce после подтверждённых транзакций. С pending вызов запрашивает ожидающее состояние одного узла. Разница означает, что этот узел знает об ожидающих транзакциях, но не доказывает, что их знают все публичные узлы.

Диагностика до подписания

  1. Прекратите отправку с затронутого адреса на всех устройствах и во всех приложениях. Запишите сеть, chain ID, адрес отправителя, хеши, nonce, получателей, суммы, calldata, gas limits и поля комиссии.
  2. Убедитесь, что кошелёк, обозреватель и RPC относятся к одной сети и отправителю. Nonce принадлежит аккаунту в конкретной сети, а не установке кошелька.
  3. Запросите eth_getTransactionCount с latest и pending, желательно у двух независимых RPC-провайдеров. Расхождения показывают разные представления mempool, а не противоречие состояния on-chain.
  4. Проверьте транзакции отправителя по nonce. Если доступен API пула узла, он различает исполнимые записи pending и будущие queued. Публичные RPC часто отключают этот нестандартный API.
  5. Начиная со значения latest, найдите первый nonce без подтверждённой транзакции. Определите, видна ли известная транзакция, была ли удалена или создана только локально.

Не действуйте только по метке кошелька. Решающее доказательство — подтверждённый nonce, квитанция и включение в блок правильной сети.

Замена или отмена первого нерешённого nonce

Чтобы сохранить исходное действие: используйте ускорение кошелька или повторно транслируйте транзакцию с теми же отправителем, nonce, получателем, суммой и calldata, но конкурентной комиссией. Проверьте все поля перед подписью: изменение payload создаёт другое действие.

Чтобы отказаться от исходного действия: пока оно не подтверждено, отправьте 0 ETH с адреса самому себе с тем же nonce и конкурентной комиссией. Это лишь попытка обеспечить победу перевода самому себе. Исходная транзакция всё ещё может подтвердиться первой; не считайте отмену успешной, пока у замены не появится квитанция, а исходная транзакция не останется неподтверждённой.

Приём замены определяется политикой узла, а не универсальным процентом. Для транзакции EIP-1559 может потребоваться повысить maxPriorityFeePerGas и maxFeePerGas, причём maxFeePerGas должна оставаться достаточной при текущей base fee. Оценки кошельков и правила клиентов различаются; replacement transaction underpriced означает, что принимающий узел отклонил замену по текущей политике.

После подтверждения наименьшего nonce снова проверьте квитанцию, latest, балансы и все большие nonce. Транзакции в очереди могут сразу стать исполнимыми; удалённые всеми соответствующими узлами, возможно, придётся осознанно транслировать заново. Не отправляйте вслепую: сначала убедитесь, что прежняя копия не вошла в блок.

Пример

У адреса подтверждены транзакции до nonce 24, поэтому latest равен 25. Один RPC сообщает pending 25, а кошелёк показывает nonce 26 и nonce 27 в очереди. Ни один провайдер не находит транслированную транзакцию с nonce 25.

Владелец сначала проверяет сеть, отправителя и записанные payloads. Если для nonce 25 было нужное действие, он восстанавливает и транслирует его с nonce 25 и актуальной комиссией. Если нужного действия не было, можно отправить 0 ETH самому себе с nonce 25. Повышение только комиссии nonce 27 разрыв не закроет.

После включения nonce 25 владелец проверяет квитанцию, прежде чем трогать nonce 26 или nonce 27. Каждая транзакция проверяется отдельно: она могла быть удалена или быстро исполниться после закрытия разрыва.

Риски и условия остановки

  • Замена может конкурировать с оригиналом. До получения доказательства on-chain исходите из того, что прежний получатель, сумма и вызов контракта всё ещё могут исполниться.
  • Проверьте полный адрес отправителя, chain ID, nonce и calldata на доверенном экране. Вредоносное ПО или сомнительный сайт «восстановления» может подменить перевод или разрешение.
  • Оставьте достаточно нативной валюты для комиссии замены. За включённую транзакцию взимается gas, даже если вызов контракта затем делает revert.
  • Не раскрывайте seed-фразу или приватный ключ ради устранения разрыва. Они не нужны легитимному RPC, обозревателю или службе поддержки.
  • Если адрес скомпрометирован, повторные публичные замены могут превратиться в гонку комиссий с атакующим. Не используйте заражённое устройство и следуйте плану реагирования.
  • Если RPC расходятся, исходный получатель неизвестен, payload нельзя восстановить или на кону крупное взаимодействие с контрактом, остановитесь и обратитесь к специалисту до подписи.

При работе с нескольких устройств или автоматических подписантов предотвращайте повторение: один распределитель nonce на аккаунт и сеть, последовательное подписание, долговечная запись зарезервированных nonce и хешей, сверка с подтверждённым состоянием и pending-пулом транслирующего узла. Сброс локальной истории кошелька не меняет состояние on-chain или mempool других узлов.

Распространённые заблуждения

  • «Большая комиссия nonce 27 позволяет пропустить nonce 25». Она может повысить приоритет лишь после исполнимости ранних nonce; разрыв она не устраняет.
  • «Не найдена — значит отменена». Один узел мог удалить транзакцию, пока другой узел, builder или контрагент её хранит. Подписанную транзакцию можно транслировать повторно.
  • «Перевод 0 ETH самому себе отменяет оригинал». Он только конкурирует за тот же nonce и не действует после подтверждения оригинала.
  • «pending — окончательный ответ сети». Это представление ожидающего состояния опрошенного узла, которое различается у провайдеров.

Похожие темы

Источники

Навигация

Поиск по вики...