Запуск смарт-контракта на TRON: TronWeb и руководство по API
Взаимодействие со смарт-контрактами TRON — будь то передача USDT, замена на SunSwap или вызов собственной логики DeFi — сводится к кодированию параметров функции, трансляции транзакции triggerSmartContract и оплате Energy за выполнение.
В этом руководстве рассматриваются высокоуровневый API TronWeb, необработанные триггеры HTTP, вызовы чтения и записи и производственные шаблоны.
Чтение и запись {#чтение-запись}
| Тип | Трансляция | Затраты энергии | Метод |
|---|---|---|---|
| Чтение (просмотр/чистый) | Нет | Нет | ⟦Т10⟧ |
| Запись (изменение состояния) | Да | Да | ⟦Т11⟧ |
При чтении используется triggerconstantcontract — локальная симуляция TVM.
Пишет, используя triggersmartcontract — добытый в блоке.
TronWeb экземпляр контракта
const TronWeb = require('tronweb');
const tronWeb = new TronWeb({
fullHost: 'https://api.trongrid.io',
privateKey: process.env.PRIVATE_KEY
});
const USDT = 'TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t';
const abi = [/* TRC-20 ABI fragment */];
const contract = await tronWeb.contract(abi, USDT);
Если contract not found — неправильная сеть или адрес. Устранение неполадок, связанных с контрактом не найден.
Чтение баланса
⟦Т1⟧
Запись передачи
⟦Т2⟧
Полное руководство: отправить USDT программно.
Fee_limit и Энергия
feeLimit колпачки TRX сгорают, если Энергии недостаточно (на солнце — 1 TRX = 1e6 солнца).
Типичные настройки:
| Операция | FeLimit (вс) |
|---|---|
| TRC-20 трансфер | 50_000_000 – 100_000_000 |
| Комплекс DeFi | 150_000_000 – 500_000_000 |
На аккаунте должна быть заморожена энергия или жидкость TRX. При неудачных транзакциях по-прежнему взимается комиссия — транзакция не удалась.
HTTP API: триггерSmartContract
Низкоуровневый POST для полного узла:
⟦Т3⟧
Тело (упрощенное):
⟦Т4⟧
Ответ содержит объект transaction — подписывается локально и транслируется через broadcasttransaction.
TronWeb абстрагирует это. Необработанный HTTP полезен для стеков, отличных от JS. См. TRON Справочник по HTTP API.
триггерConstantContract (чтение)
⟦Т5⟧
Та же кодировка без трансляции. Возвращает шестнадцатеричный код constant_result.
⟦Т6⟧
Кодировка параметра
Селектор функции = первые 4 байта keccak256("transfer(address,uint256)").
Параметры ABI закодированы в 32-байтовые слоты. TronWeb обрабатывает кодировку при использовании .send()/.call().
Ошибка ручного кодирования → REVERT в цепочке.
TronLink порядок действий в браузере
Фронтенд-приложения используют инъекцию TronLink:
⟦Т7⟧
Пользователь регистрируется во всплывающем окне — закрытый ключ никогда не отображается на веб-странице. Предупреждайте пользователей о рисках dApp.
Журналы событий после триггера
После записи получите квитанцию:
⟦Т8⟧
Прослушиватели событий для мониторинга.
Распространенные ошибки
| Ошибка | Причина |
|---|---|
| REVERT | Плохие параметры, недостаточный баланс/пособие |
| OUT_OF_ENERGY | Поднимите комиссиюОграничьте или заморозьте TRX |
| CONTRACT_VALIDATE_ERROR | Неправильный ABI или селектор |
| BANDWIDTH_ERROR | Заморозить пропускную способность |
Лучшие практики
- Сначала протестируйте Шасту/Нил — testnet
- Проверьте контракт на TronScan — проверить контракт
- Установите явный
feeLimit— избегайте слишком низких значений по умолчанию. - Разберите квитанцию
result, прежде чем предположить успех. - Идемпотентные повторы — проверьте txid перед повторной отправкой
Шаблоны множественных вызовов
Пакетная замена маршрутизаторов за одну транзакцию. В ваших контрактах могут использоваться внутренние вызовы — обратите внимание на reentrancy и лимиты энергии на передачу.
Контрольный список устранения неполадок
Если что-то пойдет не так на TRON, отнеситесь к этому как к проблеме структурированной отладки: подтвердите точный txid в цепочке, проверьте адрес целевого контракта и только затем решите, можно ли устранить сбой. В TRON многие «загадочные» проблемы — это просто одна из следующих: неправильная сеть (основная сеть или тестовая сеть), неправильный контракт токена (поддельный USDT / токены с одинаковым названием), недостаточность ресурсов (OUT_OF_ENERGY / пропускная способность) или задержка пользовательского интерфейса/индексатора между кошельком и проводником.
Начните с этих цепочек проверок:
- Всегда копируйте полный txid/хэш из своего кошелька или проводника.
- Подтвердите статус результата передачи на TronScan (SUCCESS, REVERT, OUT_OF_ENERGY или все еще в ожидании).
- Проверьте, соответствует ли адрес получателя/договора тому, что вы намеревались отправить.
- Если это вызов контракта, убедитесь, что селектор функций и параметры соответствуют стандарту токена, который, по вашему мнению, вы используете (TRC-20 vs TRC-10 vs BEP-20 на BSC).
Затем примените путь исправления для вашей категории:
- Подтвердите статус и параметры транзакции.
- Проверка адресов (контракт токена, получатель, маршрутизатор/отправитель).
- Добавляйте или делегируйте ресурсы (энергию/пропускную способность), если сбой связан с ресурсами.
Распространенные ошибки
Эти шаблоны вызывают большинство сбоев на уровне пользователя:- Использование адресов основной сети в тестовой сети (или наоборот).
- Копирование символа токена вместо фактического адреса контракта TRC-20.
- Подписание неправильного адреса одобрения/платежа, поскольку ссылка пользовательского интерфейса является вредоносной или устаревшей.
- Повторная попытка без изменения ошибочного ввода (например, REVERT продолжает возвращаться до тех пор, пока вы не исправите параметр).
Если вы не уверены, не «просто отправьте еще раз». Внесите одно контролируемое изменение, проверьте на TronScan, затем продолжайте.
Часто задаваемые вопросы
Как узнать, действительно ли транзакция подтверждена?
Используйте TronScan и проверьте статус результата передачи. Ярлыки кошелька «ожидающие» могут отставать; Статус цепочки является источником истины. Скопируйте txid и проверьте SUCCESS/REVERT/OUT_OF_ENERGY, а не только текст пользовательского интерфейса.
Почему пользовательский интерфейс отличается от TronScan?
Некоторые кошельки и децентрализованные приложения используют разные индексаторы или уровни кэша. Короткая задержка между трансляцией и индексированием является нормальной; сравните txid и подождите, пока цепочка стабилизируется, прежде чем сделать вывод об ошибке.
Что мне делать после REVERT?
Остановитесь и декодируйте неудачный вызов. Большинство ошибок REVERT вызваны недопустимыми параметрами, неправильным адресом контракта, отсутствием утверждений или несоответствием между стандартом токена и методом. Устраните причину и подпишите заново.
Безопасно ли подписывать неограниченное разрешение?
Неограниченное одобрение безопасно только для проверенных вами адресов доверенных отправителей (проверенный источник, правильный маршрутизатор и ожидаемый контракт токена). Для тестирования отдавайте предпочтение ограниченному утверждению и отзыву после завершения.
Какие ресурсы требуются TRON для вызовов контракта?
Выполнение смарт-контракта в основном потребляет энергию, а байты транзакций потребляют пропускную способность. Если вы получили OUT_OF_ENERGY, добавьте/заморозьте/делегируйте Энергию. Если пропускная способность исчерпана, сосредоточьтесь на сохранении достаточного количества жидкости TRX для байтов и распределения ресурсов.
Как я могу уменьшить количество обращений в службу поддержки?
Покажите пользователям четкое сообщение «что произошло» на основе статуса цепочки и дайте прямую ссылку на соответствующее руководство (ожидание, сбой, отсутствие энергии или проверка). Сохраните txid, чтобы можно было быстро выполнить согласование.
Похожие руководства {#связанные}
- TronWeb введение
- Развертывание TRC-20 с помощью TronWeb
- API проверки транзакции
- TronGrid Руководство по API
Часто задаваемые вопросы
В чем разница между вызовом и триггером на TRON?
Постоянные вызовы считывают состояние без транзакции. TriggerSmartContract транслирует изменения состояния, затрачивающие энергию.
Сколько энергии потребляет вызов смарт-контракта?
TRC-20 передать ~65 000 Энергии. Больше сложных вызовов — протестируйте в тестовой сети.
Могу ли я выполнить запуск без закрытого ключа?
Читать звонки да. Для записи требуется подпись — TronLink или ключ на стороне сервера.
Что означает «visible: true» в API?
Адреса в запросе/ответе используют формат Base58 T, если истинно, и шестнадцатеричный, если ложно.
Как мне утвердить последующий обмен в двух транзакциях?
Сначала approve(router, amount) на контракте токена, затем swap на маршрутизаторе — два отдельных триггера. Некоторые пользовательские интерфейсы группируются через контракты с несколькими вызовами.
Спасибо — ваш фидбек помогает улучшать документацию.