OUT_OF_ENERGY против OUT_OF_BANDWIDTH (Как отличить) — TRON Wiki

OUT_OF_ENERGY против OUT_OF_BANDWIDTH (Как отличить)

10 мин чтения · ⌘K поиск

Приложения USDT/TRON выходят из строя по предсказуемым причинам: несоответствие сети, неправильный контракт токена, неправильное форматирование адреса и ошибки ресурсов (энергия/пропускная способность). В этом руководстве объясняется, как безопасно выполнить задачу, как проверить ее в сети и как исправить ситуацию, если что-то не соответствует вашим ожиданиям.

Обзор

В TRON большинство «комиссий» отображаются как использование ресурсов (энергии и пропускной способности), а подтверждения становятся видимыми в TronScan после индексации. Для отладки транзакций с использованием статуса цепочки TronScan следует относиться к процессу как к контрольному списку: подготовить, отправить, проверить, а затем только переходить к следующему действию.

Чему вы научитесь

  • Что подготовить перед подписанием (адреса, контракт, сеть и покрытие ресурсов)
  • Как выполнить действие шаг за шагом с помощью кошелька или dApp
  • Какие подтверждения проверять TronScan
  • Распространенные ошибки, которые приводят к неверным или отсутствующим результатам.

Шаг за шагом

  1. Подготовьте точные входные данные: адреса получателя/контракта (34 символа, Base58, начинающиеся с T для адресов TRON), адрес контракта токена (TRC-20) и предполагаемую сеть (основная сеть или тестовая сеть).
  2. Войдите в безопасный режим подписи: приложения браузера должны использовать всплывающие окна TronLink; Подписание на стороне сервера должно быть изолировано от ключей внешнего интерфейса.
  3. После трансляции сразу скопируйте txid/хэш.
  4. Проверьте TronScan: отметьте SUCCESS/REVERT/OUT_OF_ENERGY и сравните поля токена/получателя с вашим намерением.
  5. Только потом приступайте: если вы видите несоответствие, остановитесь и исправьте ввод (неправильный контракт, неправильный отправитель/маршрутизатор, неправильный формат заметки), а не повторяйте вслепую.

Контрольный список проверки

  • Вы скопировали точный txid/хэш из кошелька?
  • Отображает ли TronScan тот же txid, что и предполагаемый контракт/получатель?
  • Если вы столкнулись с ошибкой, соответствует ли ошибка ресурсам (OUT_OF_ENERGY) или параметрам (REVERT)?
  • Вы подтвердили стандарт токена и адрес контракта (TRC-20 по сравнению с другими сетями)?

Отладка транзакций TRON является детерминированной, если вы начинаете со статуса цепочки. Используйте проводник как источник истины и меняйте по одной переменной за раз.

Контрольный список для устранения неполадок

Если что-то пойдет не так на TRON, отнеситесь к этому как к проблеме структурированной отладки: подтвердите точный txid в цепочке, проверьте адрес целевого контракта и только затем решите, можно ли устранить сбой. В TRON многие «загадочные» проблемы — это просто одна из следующих: неправильная сеть (основная сеть или тестовая сеть), неправильный контракт токена (поддельный USDT / токены с одинаковым названием), недостаточность ресурсов (OUT_OF_ENERGY / пропускная способность) или задержка пользовательского интерфейса/индексатора между кошельком и проводником.

Начните с этих цепочек проверок:

  • Всегда копируйте полный txid/хэш из своего кошелька или проводника.
  • Подтвердите статус результата отправки на TronScan (SUCCESS, REVERT, OUT_OF_ENERGY или все еще в ожидании).
  • Проверьте, соответствует ли адрес получателя/договора тому, что вы намеревались отправить.
  • Если это вызов контракта, убедитесь, что селектор функций и параметры соответствуют стандарту токена, который, по вашему мнению, вы используете (TRC-20 vs TRC-10 vs BEP-20 на BSC).

Затем примените путь исправления для вашей категории:

  • Ожидание вечно или все еще ожидание: сравните статус кошелька и статус проводника; индексаторы могут ненадолго отставать.
  • «SUCCESS, но неверный результат» обычно означает проблему интерпретации пользовательского интерфейса или несоответствие между входными данными и тем, что, по вашему мнению, вы отправили.
  • Если REVERT: декодируйте причину возврата, если это возможно, и повторяйте попытку только после изменения сбойного параметра/цели вызова.

Распространенные ошибки

Эти шаблоны вызывают большинство сбоев на уровне пользователя:

  • Использование адресов основной сети в тестовой сети (или наоборот).
  • Копирование символа токена вместо фактического адреса контракта TRC-20.
  • Подписание неправильного адреса одобрения/платежа, поскольку ссылка пользовательского интерфейса является вредоносной или устаревшей.
  • Повторная попытка без изменения ошибочного ввода (например, REVERT продолжает возвращаться до тех пор, пока вы не исправите параметр).

Если вы не уверены, не «просто отправьте еще раз». Внесите одно контролируемое изменение, проверьте TronScan, затем продолжайте.

Часто задаваемые вопросы

Как узнать, действительно ли транзакция подтверждена?

Используйте TronScan и проверьте статус результата передачи. Ярлыки кошелька «ожидающие» могут отставать; Статус цепочки является источником истины. Скопируйте txid и проверьте SUCCESS/REVERT/OUT_OF_ENERGY, а не только текст пользовательского интерфейса.

Почему пользовательский интерфейс отличается от TronScan?

Некоторые кошельки и децентрализованные приложения используют разные индексаторы или уровни кэша. Короткая задержка между трансляцией и индексированием является нормальной; сравните txid и подождите, пока цепочка стабилизируется, прежде чем сделать вывод об ошибке.

Что мне делать после REVERT?Остановитесь и декодируйте неудачный вызов. Большинство ошибок REVERT вызваны неверными параметрами, неправильным адресом контракта, отсутствием утверждений или несоответствием между стандартом токена и методом. Устраните причину и подпишите заново.

Безопасно ли подписывать неограниченное разрешение?

Неограниченное одобрение безопасно только для проверенных вами адресов доверенных отправителей (проверенный источник, правильный маршрутизатор и ожидаемый контракт токена). Для тестирования отдавайте предпочтение ограниченному утверждению и отзыву после завершения.

Какие ресурсы требуются TRON для вызовов контракта?

Выполнение смарт-контракта в основном потребляет энергию, а байты транзакций потребляют пропускную способность. Если вы получили OUT_OF_ENERGY, добавьте/заморозьте/делегируйте Энергию. Если полоса пропускания исчерпана, сосредоточьтесь на сохранении достаточного количества TRX для байтов и распределения ресурсов.

Как я могу уменьшить количество обращений в службу поддержки?

Покажите пользователям четкое сообщение «что произошло» на основе статуса цепочки и дайте прямую ссылку на соответствующее руководство (ожидание, сбой, отсутствие энергии или проверка). Сохраните txid, чтобы можно было быстро выполнить согласование.

Дополнительная проверка, прежде чем продолжить

После выполнения основного действия проверьте результат, используя проводник как источник истины. Интерфейсы кошелька могут кэшировать или задерживать сообщения; статус цепочки и txid/hash подтверждают, что произошло на самом деле.

  • Подтвердите SUCCESS/REVERT/OUT_OF_ENERGY на TronScan.
  • Сравните txid/хэш, который вы скопировали, с тем, который отображается в проводнике.
  • Проверьте адрес контракта токена (TRC-20) и предполагаемый контракт получателя/получателя.
  • Если результаты в пользовательском интерфейсе и цепочке различаются, отдайте приоритет статусу цепочки. Внесите одно контролируемое изменение и перепроверьте тот же txid.