FREEBLOCK / WEB3 С 2018 ГОДА
Аудит
смарт-контрактов
Проверяем код, бизнес-логику и движение активов в согласованной версии контракта. Результат — отчёт с найденными проблемами, объяснением рисков и рекомендациями по исправлению.
Можно начать с короткого описания задачи.
01 / ЧТО ПРОВЕРЯЕМ
Проверка безопасности контракта
Аудит смарт-контракта — анализ того, соответствует ли код ожидаемым правилам и где его поведение может привести к нежелательным действиям. До проверки определяем активы, роли и доверенные зависимости.
Доступы и управление
Права администратора, ограничения функций, смена ролей и обновление контрактов. Проверяем, кто может менять правила и распоряжаться активами.
Расчёты и активы
Ввод и вывод средств, награды, вестинг, округление и граничные значения. Сопоставляем реализацию с ожидаемой бизнес-логикой.
Вызовы и зависимости
Повторные входы, внешние контракты, оракулы и порядок операций. Для TON отдельно рассматриваем сообщения и проверки отправителя.
Методы дополняют друг друга
| Метод | Что даёт | Что учитываем |
|---|---|---|
| Ручной анализ | Проверка правил продукта, ролей и цепочек действий. | Нужны спецификация, архитектура и ожидаемые сценарии. |
| Автоматические проверки | Поиск типовых проблем и исследование поведения в тестах. | Срабатывания проверяем вручную; инструмент не понимает все бизнес-требования. |
| Формальная верификация | Проверка явно заданных свойств с помощью формальных методов. | Свойства, модель и объём такой проверки согласуем отдельно. |
Проверяем токены ERC-20, NFT на ERC-721 и ERC-1155, вестинг, стейкинг, а также логику DeFi, DEX и DAO в согласованных границах. Для каждого типа важны свои правила учёта, доступа и взаимодействия с другими контрактами.
02 / СОСТАВ РАБОТ
Чёткие границы вместо общей оценки безопасности
Перед началом фиксируем, какие контракты и сценарии входят в аудит. Сайт, backend, кошельки и инфраструктура не становятся проверенными автоматически вместе с контрактом.
-
Код и окружение
Репозиторий, commit, версия компилятора, инструкции сборки и тесты.
-
Ожидаемое поведение
Описание механики, ролей, движения активов и допустимых состояний.
-
Область проверки
Контракты, зависимости и интеграции; отдельно указываем исключения.
-
Отчёт и обсуждение
Находки, степень серьёзности, техническое обоснование и рекомендации.
-
Повторная проверка
Согласованный объём проверки изменений и статусы замечаний в новой версии.
03 / СТОИМОСТЬ И СРОКИ
Стоимость аудита — по коду и глубине проверки
Количество строк — только один из факторов. На трудоёмкость влияют связи между контрактами, экономическая логика, внешние зависимости и готовность тестов.
Объём и сложность
Контракты, роли, сети, нестандартная логика и сторонние компоненты.
Глубина анализа
Ручная проверка, инструменты, дополнительные тесты и выбранные свойства.
Готовность и retest
Документация, воспроизводимая сборка и объём проверки исправлений.
04 / РЕЗУЛЬТАТ ПРОВЕРКИ
Что будет в отчёте по аудиту
Отчёт должен помогать команде воспроизвести проблему, исправить её и понять, что осталось вне проверки. Ниже — структура результата, которую согласуем перед работой.
СТРУКТУРА ОТЧЁТА · БЕЗ ДАННЫХ КЛИЕНТСКОГО ПРОЕКТА
- Область
- Репозиторий и commit, список контрактов, методы и ограничения проверки.
- Находка
- Название, степень серьёзности, файл и функция, условия возникновения.
- Обоснование
- Влияние на продукт, техническое объяснение и шаги воспроизведения, где применимо.
- Рекомендация
- Предлагаемое исправление и связанные изменения, которые нужно проверить.
- Статус после retest
- Версия исправлений и итог по замечанию: исправлено, частично исправлено или остаётся открытым.
05 / АРХИТЕКТУРА И ПРОВЕРКИ
Аудит привязан к версии продукта
Важен не только исходный код, но и конфигурация, с которой его используют. Поэтому отдельно обсуждаем развёртывание, доверенные роли и действия после отчёта.
Развёрнутый контракт
Сверяем адрес и доступные исходники, учитываем proxy и реализацию. Без кода и контекста возможности анализа ограничены.
Изменения после проверки
Новый код или параметры могут изменить поведение. Определяем, какие изменения требуют дополнительной проверки.
Эксплуатация
Ключи администраторов, процедуры обновления и внешние сервисы обсуждаем как зависимости и отдельные области риска.
Аудит помогает выявлять уязвимости, но не гарантирует отсутствие всех ошибок и не является сертификатом полной безопасности. Выводы относятся к согласованной версии кода и объёму проверки.
Технологии и интеграции
Solidity и EVM
Права, внешние вызовы, расчёты и особенности обновляемых контрактов в Ethereum и совместимых сетях.
Инструменты анализа
Slither — статический анализ; Mythril — символьный анализ; Echidna — fuzzing заданных свойств. Набор подбираем под код.
TON и модель сообщений
Проверки отправителя, повторные сообщения, состояния и обработка ошибок. Границы анализа согласуем под архитектуру TON.
Технологии
Блокчейны
Технические ориентиры: Безопасность смарт-контрактов · Slither · Echidna
06 / ЭТАПЫ
Как строим работу
-
Уточняем объём
Согласуем код, сценарии, доступы и исключения.
-
Проводим анализ
Сочетаем ручной разбор и подходящие инструменты.
-
Разбираем отчёт
Объясняем находки и предлагаем исправления.
-
Проверяем изменения
Выполняем согласованный retest новой версии.
07 / ПОРТФОЛИО
Наш опыт разработки
Все проектыПримеры продуктов из нашего портфолио. Состав работ по каждому проекту описан в его кейсе.
SEC.Markets
Криптовалютная биржа
TrueRich
Блокчейн игра на смарт-контракте Ethereum
Pandas.Money
Криптовалютный обменник
Lionapy
NFT-коллекция и DeFi инструменты
Mainflex
Костадиальный веб-кошелек
Tugan
Криптовалютный веб-кошелек и обмен для тендерной платформы
Gold Digital
Платформа и смарт-контракт для токена обеспеченного золотом
AVO Staking
Смарт-контракт cтейкинга для токена AVO и Front-End
08 / FAQ
Что важно знать
до начала работ
Что входит в аудит смарт-контракта?
Анализ согласованной версии кода, бизнес-логики, ролей, движения активов и зависимостей. Объём ручной проверки, автоматических методов и повторной проверки фиксируем до начала работ.
Можно ли проверить безопасность контракта по адресу?
Начать можно с сети и адреса. Для полноценного анализа нужны исходники и описание ожидаемого поведения. Учитываем proxy, реализацию и конфигурацию; при недоступном коде заранее объясним ограничения.
Что предоставить перед началом аудита?
Ссылку на репозиторий и commit, инструкции сборки, тесты, описание архитектуры, ролей и внешних зависимостей. Если материалы неполные, сначала согласуем, что нужно подготовить.
Чем аудит отличается от автоматического сканера?
Сканер помогает искать известные типы проблем. Ручной анализ проверяет логику конкретного продукта, цепочки действий и достоверность срабатываний. Эти методы дополняют друг друга.
Гарантирует ли аудит полную безопасность?
Нет. Проверка ограничена выбранной версией кода, доступной информацией и согласованным объёмом. Внешние сервисы, эксплуатация и последующие изменения могут создавать дополнительные риски.
Проверяете ли вы исправления?
Да, объём и порядок retest согласуем отдельно. Проверяем изменения относительно зафиксированной версии и обновляем статусы замечаний. Новые функции могут потребовать расширения проверки.
От чего зависят стоимость и сроки аудита?
От сложности логики, объёма кода, сетей, зависимостей, документации и глубины проверки. Отдельно учитываем retest и формальную верификацию выбранных свойств, если она нужна.
FREEBLOCK / ОБСУДИТЬ ПРОЕКТ
Начнём с вашей задачи.
Пришлите сеть, ссылку на репозиторий или адрес контракта и описание механики. Определим границы проверки и материалы для оценки.
Или напишите напрямую:
@FreeBlockOfficial
info@freeblock.dev