Безопасность смарт-контрактов на TRON: лучшие практики для разработчиков

Развертывание на TVM TRON (виртуальной машине TRON) кажется знакомым разработчикам Ethereum — Solidity, аналогичные шаблоны ABI, сопоставимые примитивы DeFi. Сбои в системе безопасности одинаково известны: утечки повторного входа, отсутствие контроля доступа, неограниченное количество монет и манипуляции оракулами — все это произошло на TRON.

В этом руководстве рассматриваются конкретные аспекты TRON и универсальные методы обеспечения безопасности смарт-контрактов для токенов TRC-20, протоколов DeFi и платежных контрактов.

Модель угроз

Предположим, злоумышленники:

• Вызовите свой контракт напрямую, минуя интерфейс
• Используйте transferFrom после того, как обманом вынуждаете пользователей получать неограниченное количество разрешений.
• Ранние транзакции там, где они выгодны (меньше инфраструктуры MEV, чем у Ethereum, но все еще актуально на DEX)
• Исследование непроверенного байт-кода с помощью реверс-инжиниринга.
• Злоупотреблять ключами администратора, если они централизованы.

Риск, с которым сталкивается пользователь, пересекается с мошенничеством с неограниченным одобрением и токенами-приманками.

Контроль доступа

Каждая привилегированная функция (mint, pause, setFee, withdraw) требует явного ограничения.

import "@openzeppelin/contracts/access/Ownable.sol";

contract SecureToken is Ownable {
    function mint(address to, uint256 amount) external onlyOwner {
        _mint(to, amount);
    }
}

Проверки:

• Нет незащищенных selfdestruct или delegatecall для пользовательского ввода.
• Мультиподпись или временная блокировка для администратора на производственном TVL
• Отказаться от владения только тогда, когда он действительно неизменен.

TRON мультиподпись: разрешения учетной записи.

Повторный вход {#возврат}

TRC-20 transfer и transferFrom вызывают внешние контракты, когда получателем является контракт. Классическая схема слива:

⟦Т1⟧

Исправление: Проверки-эффекты-взаимодействия + ReentrancyGuard из OpenZeppelin.

TRC-20 не использует call для TRX — но transfer для злонамеренного контракта может быть повторно введен.

Целочисленное переполнение

Solidity 0.8+ имеет встроенные проверки переполнения. Для более старых контрактов 0.5.x TRON может потребоваться SafeMath.

Проведите аудит устаревших TRC-20 шаблонов перед развертыванием основной сети.

Подводные камни контракта токена

Опубликуйте проверенный источник на TronScan — проверить смарт-контракт.

Oracle и манипулирование ценами

Спотовыми ценами DEX в сети можно манипулировать при атаках одного блока. Не используйте резервы пула SunSwap в качестве единственного ценового оракула для ликвидации кредитов.

Используйте TWAP, несколько источников или оракулы вне сети с проверкой пульса.

Прокси и обновляемые контракты

Обновляемые шаблоны (прозрачный прокси, UUPS) скрывают изменения логического адреса.

Риски:

• Скомпрометированные обновления администратора до вредоносной реализации.
• Конфликт хранения между версиями
• Пользователи взаимодействуют с прокси-сервером — проверьте реализацию на TronScan.

Публично документируйте политику обновления.

Примечания, относящиеся к TVM

См. Объяснение TVM и Solidity на TRON.

• Затраты на электроэнергию отличаются от газа Ethereum — оптимизируйте циклы для обеспечения доступности для пользователей.
• Формат адреса — типы address компилируются аналогично; внешняя интеграция использует адреса Base58 T
• Шаблоны trx.call.value различаются — для токенов предпочитаете TRC-20
• тестирование на Шасте/Ниле перед основной сетью — руководство по тестовой сети

Стратегия тестирования

1. Юнит-тесты — TronBox/Hardhat с адаптером TRON
2. Интеграционные тесты — развертывание в Shasta, полные пользовательские потоки.
3. Фуззинг — Ехидна, Литейная, если совместимо
4. Статический анализ — Скольжение на Solidity AST
5. Внешний аудит — требуется при значительном ТВЛ.

Смарт-контракты TronBox Настройка тестирования.

Гигиена развертывания

• Развертывание из аппаратного кошелька или холодного ключа для владельца.
• Немедленно проверьте контракт на TronScan.
• Передача права собственности на мультиподпись в отдельной транзакции.
• Документируйте адреса контрактов в README и внутрисетевых событиях.
• Никаких закрытых ключей во внешнем интерфейсе или на GitHub.

Безопасность интерфейса и API

Безопасность смарт-контрактов распространяется на взаимодействие пользователей:

• Никогда не запрашивайте начальные фразы на веб-сайтах dApp.
• Показывать удобочитаемые суммы одобрения
• Отображать адреса контрактов, против которых подписывают пользователи.
• риски подключения dApp обучение пользователей

Внутренние платежные системы: принимать платежи USDT.

Реагирование на инцидент {#incident}Если эксплойт активен:

1. Приостановить контракт, если его можно приостановить.
2. Общайтесь открыто
3. Обмен контактами, если украденные средства попали на указанные адреса
4. Сообщить о мошеннических адресах

Профилактика важнее восстановления неизменяемых цепочек.

Контрольный список безопасности

• [ ] Solidity 0.8+ или SafeMath
• [ ] ReentrancyGuard для внешних вызовов
• [ ] onlyOwner / доступ на основе ролей
• [ ] Нет произвольного delegatecall
• [ ] Задокументировано наличие свежего колпачка или фиксированного запаса
• [ ] Проверено на TronScan
• [ ] Протестировано развертывание тестовой сети.
• [ ] Сторонний аудит средств пользователей
• [ ] Электронная почта об обнаружении ошибок или раскрытии информации

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

Если что-то пойдет не так на 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, чтобы можно было быстро выполнить согласование.

Похожие руководства {#связанные}

• Solidity на TRON
• Разверните TRC-20 с помощью TronWeb
• Проверить смарт-контракт на TRON
• TRC-20 риски утверждения токена

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

Отличается ли безопасность смарт-контрактов TRON от Ethereum?

Шаблоны надежности во многом перекрываются, но TVM различается по стоимости кодов операций и форматам адресов. Основные классы уязвимостей те же.

Должен ли я проверять свой TRC-20 перед развертыванием основной сети?

Да, для любого контракта, содержащего средства пользователя. Эксперименты с низким уровнем риска по-прежнему выигрывают от автоматического сканирования.

Могут ли пользователи слить мой контракт без ошибки?Если пользователи предоставили неограниченное количество утверждений токенов для вашего контракта, скомпрометированный ключ администратора или обновление могут истощить этих пользователей — создавайте минимальные утверждения.

Безопасны ли контракты OpenZeppelin на TRON?

В целом да, при использовании текущих версий Solidity 0.8+. Проверьте версию компилятора и пути импорта в TronBox.

Что является наиболее распространенным мошенничеством с токеном TRON?

Контракты Honeypot разрешают покупки, но блокируют продажи — это не уязвимость в вашем протоколе, а экосистемный риск для ваших пользователей.