Receipt показывает итог включенной EVM-транзакции, а trace помогает понять последовательность вызовов, которая к этому итогу привела. Трасса особенно полезна, когда кошелек вызвал маршрутизатор, тот обратился к нескольким контрактам, а в интерфейсе осталась короткая ошибка. Trace может показать вложенный вызов с revert, но его нужно читать в контексте сети, данных операции и состояния на момент исполнения.
Что такое trace и чем он отличается от receipt
Receipt содержит хэш, номер блока, статус исполнения, использованный газ и логи событий. Он отвечает на вопрос, завершилась ли транзакция успешно в блоке. Trace является результатом повторного исполнения или анализа транзакции узлом. Он может представить дерево вызовов, последовательность операций виртуальной машины или сокращенную сводку. Формат зависит от клиента и выбранного инструмента.
Trace не является обязательным полем, которое любой обозреватель всегда хранит рядом с транзакцией. Некоторые сайты показывают вкладку внутренней активности, другие дают только receipt. Публичный RPC может не разрешать debug-запросы. Отсутствие trace не означает, что операция подозрительная: провайдер мог не включить отладочные методы либо ограничить ресурсоемкие запросы.
Если транзакция не вошла в блок, диагностика будет отличаться. Ожидающий вызов не имеет итогового исполнения на цепочке, а причина может заключаться в комиссии, очереди nonce или распространении операции. Если вызов включен и имеет статус failure, начните с receipt и затем запросите trace. Поля результата разобраны в материале о receipt и состоянии сети.
Где получить трассу
Сначала проверьте, предоставляет ли обозреватель нужной сети подробности исполнения. Если нет, нужен RPC-провайдер или собственный клиент, который поддерживает методы трассировки. Клиент Geth документирует интерфейс отладочных запросов и встроенные tracer-инструменты, но доступность конкретного метода зависит от версии и конфигурации узла. Сверяйте точное имя метода с документацией используемого клиента.
Узлы часто закрывают debug namespace в публичном доступе. Трассировка может занимать ресурсы и возвращать большой объем данных, поэтому поставщик инфраструктуры ограничивает частоту или отключает метод. Не пытайтесь обходить такое ограничение случайными адресами RPC. Используйте доверенный сервис, учитывайте, что передача публичного хэша раскрывает провайдеру интерес к операции, и не вводите в сервис закрытые ключи.
Если запускаете клиент самостоятельно, запрос должен относиться к нужной сети и блоку. Историческое воспроизведение зависит от доступности состояния на момент транзакции. Разные клиенты могут предоставлять разные формы ответа. Начинающему пользователю обычно проще начать с дерева вызовов call tracer, а не с полного журнала каждой инструкции EVM.
Порядок чтения call trace
Начните с корневой записи: адрес отправителя, целевой контракт, переданная стоимость, тип вызова и результат. Затем двигайтесь по вложенным вызовам от родительского контракта к дочерним. Найдите ветку, помеченную как failed или reverted, и определите, какой вызов впервые завершился ошибкой. Внешний контракт может лишь вернуть ошибку из дочернего вызова, поэтому адрес верхнего уровня не обязательно является ее источником.
Обратите внимание на тип взаимодействия. CALL исполняет код другого контракта в его контексте, STATICCALL ограничивает изменение состояния, а DELEGATECALL использует чужой код в контексте вызывающего аккаунта. При делегированном вызове особенно важно понять, какое хранилище меняется и кто контролирует реализацию. Не делайте вывод только по адресу: изучите селектор, calldata, возвращаемые данные и цепочку родительских вызовов.
Некоторые инструменты декодируют revert reason в читаемый текст или показывают пользовательский код ошибки. Но контракт может вернуть пустые данные, нераспознанный селектор или произвольное сообщение. Тогда интерфейс покажет лишь общее «execution reverted». Если есть ABI и проверенный исходный код, сопоставьте селектор ошибки и параметры. Для изучения входного вызова пригодится разбор calldata транзакции.
Как определить вероятную причину
Частые причины включают недостаточный баланс или allowance, не выполненное условие min-out, истекший deadline, ограничение доступа, неверные аргументы либо состояние пула, отличающееся от ожидаемого. Маршрутизатор может обратиться к токену, оракулу, мосту или другому протоколу, где и произойдет отказ. Сопоставьте входные параметры с сообщением интерфейса и документацией вызываемого контракта.
Для внешнего вызова проверьте баланс, разрешения и адрес токена на момент операции. При свопе важны маршрут, проскальзывание, минимальный выход и срок действия. При кредитовании могут иметь значение обеспечение, лимит рынка и коэффициент здоровья. Нельзя автоматически считать, что revert означает ошибку кошелька или сети: контракт мог корректно остановить операцию из-за не выполненного условия.
Trace показывает состояние конкретного исторического блока, а не обещает, что вызов пройдет сейчас. К моменту проверки могли измениться резервы, цена, права, лимиты или состояние контракта. Симуляция предстоящей операции решает другой вопрос – что вероятно произойдет при исполнении в текущем состоянии. Сравнение можно посмотреть в инструкции по симуляции транзакции.
Практический чек-лист
Сохраните хэш, сеть и receipt. Убедитесь, что статус действительно указывает на неуспешное исполнение. Запросите trace поддерживаемым методом и определите первую неуспешную ветку. Сверьте адрес вызываемого контракта и входные данные с ожидаемым действием. Если несколько дочерних вызовов завершились ошибкой, проследите, какая причина поднялась до корневого уровня.
Затем сравните селектор функции и параметры с ABI, изучите события и фактическое состояние после транзакции. Revert обычно откатывает изменения состояния вызова, но потраченный газ может быть списан согласно правилам сети. Receipt помогает подтвердить размер комиссии и статус, а логи позволяют увидеть, какие события были записаны. Для понимания их роли откройте материал о логах событий и состоянии контракта.
Если сервис показывает только общее сообщение, зафиксируйте его и проверьте официальную документацию приложения. Не повторяйте вызов с теми же параметрами, пока не поняли причину: повтор может снова израсходовать комиссию. При запросе поддержки достаточно публичного хэша, сети и времени операции. Никогда не отправляйте seed-фразу или приватный ключ для разбора trace.
Trace – диагностическое представление исполнения, а не магическое объяснение любой ошибки. Его полезность зависит от доступности узла, формата вывода, качества ABI и понимания логики контракта. Рабочий подход состоит в том, чтобы соединить результат receipt, дерево вызовов, calldata, документацию и состояние на момент блока. Если источник отказа остается неясным, лучше получить техническую помощь, чем подписывать повторные транзакции наугад.
