Аудит смарт-контрактов

Аудит смарт-контрактов — стандартная практика серьёзных DeFi-проектов: перед запуском (и часто после крупных апгрейдов) код проверяет внешняя команда специалистов по безопасности. Цель — найти уязвимости, которые могут привести к потере средств, до того как контракт будет задеплоен и заполнится пользовательскими активами.

Что покрывает аудит

• Логика и инварианты. Делает ли контракт то, что заявлено? Не нарушаются ли в edge-cases ключевые свойства — например, сумма всех jetton-балансов держателей всегда равна total supply.
• Экономика. Можно ли манипулировать ценой через flash-loan, sandwich-атаку, MEV? Корректно ли распределяются комиссии? Не возникает ли дыра в стимулах валидаторов или LP-провайдеров?
• Газ и DoS. Возможны ли ситуации, когда контракт «застревает» — например, цикл по списку пользователей, который при росте размера выходит за газ-лимит?
• Доступы и права. Кто может вызывать привилегированные методы? Корректно ли реализован owner/admin/upgrade authority? Не оставлены ли «чёрные ходы»?
• Инициализация. Безопасны ли первые вызовы после деплоя? Нельзя ли украсть проект через атаку на не инициализированный контракт?
• Соответствие стандартам. Для jetton-а — соответствие TEP-74, для NFT — TEP-62. Несоответствие может ломать интеграции с кошельками и эксплорерами.

Известные команды, аудирующие TON-проекты

• CertiK — крупнейший игрок, делает много audit-as-marketing, но качество репортов варьируется.
• Trail of Bits — глубокие отчёты, академический подход. Берут не каждый проект.
• Halborn — солидный игрок в DeFi-аудите.
• SlowMist — азиатский лидер, аудит и форензика инцидентов.
• TON-фокусные команды — SecureLayer, CertiK с TON-командой, ряд бутиков, специализирующихся на FunC/Tact. Их преимущество — понимание TVM-специфики.

Стоимость аудита — обычно от 15 до 200 тысяч долларов в зависимости от сложности кода и сроков.

Специфика аудита TON-контрактов

TON принципиально отличается от EVM, и аудиторы без опыта TVM могут пропустить классы уязвимостей, которых в Ethereum просто не существует:

• Асинхронность. В TON нельзя «получить ответ функции другого контракта» синхронно. Все вызовы — асинхронные сообщения. Это меняет модель reentrancy и требует careful state machine между сообщениями.
• BoC и cell-based storage. Состояние хранится в cell-структурах. Ошибки сериализации/десериализации могут залочить контракт навсегда.
• Get-методы. Бесплатные read-only вызовы, не пишущие в стейт. Аудитор должен проверить, что они не имеют побочных эффектов и не раскрывают чувствительные данные через публичные геттеры.
• Сообщения и bounce. Что произойдёт, если внутреннее сообщение «отскочит» — обработан ли возврат корректно?
• TVM-стек. В отличие от EVM, TVM работает на стеке. Опкоды и ограничения отличаются. Атаки через переполнение стека или non-обработанные exception-ы — TON-специфика.
• Storage rent. Контракт может «вымерзнуть» из-за нехватки баланса на оплату хранения. Это влияет на доступность средств.

Чего аудит НЕ гарантирует

• Аудит — не страховка. Многократно бывало, что контракты с двумя-тремя аудитами всё равно ломали из-за уязвимости, которую все пропустили.
• Аудит проверяет код, а не команду. Если разработчики сделают rug pull через легитимные admin-функции — аудитор это увидит и отметит, но не предотвратит сам факт.
• Аудит на момент времени. Если после аудита деплоят апгрейд, новый код не покрыт.
• Покрытие зависит от scope. Иногда заказчик ограничивает scope только частью контрактов; критическая дыра может быть в незааудированной части.

Для пользователя «есть аудит» — необходимое, но недостаточное условие доверия. Полезно прочитать сам отчёт: что нашли, что исправили, что приняли как «known risk». Качественный отчёт читается как технический документ, а не как маркетинговый сертификат.