Зафиксируйте активы и недопустимые состояния
Опишите, какими данными, токенами, правами или денежными лимитами управляет контракт. Для каждой функции укажите инициатора, предусловия, изменение состояния, внешние вызовы и ожидаемый результат. Отдельно запишите инварианты: баланс не становится отрицательным, выпуск не превышает лимит, закрытый объект не открывается без утверждённой процедуры.
Модель угроз должна охватывать не только анонимного злоумышленника, но и скомпрометированный административный ключ, ошибочный оракул, недоступный внешний контракт, конфликт обновления и легитимного пользователя с неожиданной последовательностью действий.
Ограничьте административные полномочия
Проверьте роли для выпуска, паузы, обновления, изменения параметров и вывода активов. Критические операции не должны зависеть от одного личного ключа. Используйте раздельные роли, многостороннее подтверждение, временную задержку и лимиты там, где это соответствует риску.
Опишите полный жизненный цикл ключей: создание, хранение, резервирование, ротацию, отзыв и восстановление после компрометации. Служебный ключ в переменной окружения приложения не является достаточной моделью защиты для необратимых операций.
Проверьте логику и взаимодействия
Валидируйте адреса, диапазоны, повторные запросы, пустые значения и граничные состояния. Для внешних вызовов учитывайте повторный вход, возврат ошибки, нехватку газа, изменение чужого контракта и нежелательный обратный вызов. Сначала проверяйте условия, затем изменяйте собственное состояние и только после этого взаимодействуйте с внешними контрактами.
Оракул является частью доверенной вычислительной базы. Определите источники, допустимую давность данных, агрегацию, отклонение, резервный канал и безопасное поведение при отсутствии обновления. Нельзя считать внешний показатель истинным только потому, что он записан в цепочку.
Постройте несколько уровней проверки
Минимальный набор включает модульные и интеграционные тесты, негативные сценарии, проверку прав доступа и воспроизводимую сборку. Для критичной логики добавьте property-based testing, fuzzing, статический анализ и проверку инвариантов. Формальная верификация полезна для небольшого ядра с высокой ценой ошибки, но не заменяет проверку интеграций и процессов.
Независимый аудит проводится по замороженной версии кода. После исправлений нужен повторный просмотр изменённых участков и регрессионный прогон. Исходный код, версия компилятора, параметры сборки и развернутый байткод должны быть сопоставимы.
Подготовьте безопасный выпуск
Перед основной сетью отработайте развёртывание на тестовой среде тем же конвейером. Проверьте адреса зависимостей, владельцев ролей, начальные параметры, лимиты и порядок передачи управления. Зафиксируйте хеш коммита, артефакты сборки, адрес контракта и протокол утверждения.
Механизм обновления сам создаёт привилегированный путь. Если используются прокси или миграция состояния, отдельно тестируйте совместимость хранилища, авторизацию обновления и откат. Если контракт неизменяем, процедура замены и переноса должна быть спроектирована до запуска.
Мониторинг и аварийный режим обязательны
Создайте события для критичных изменений, наблюдайте аномальные суммы, частоту, ошибки, смену ролей и вызовы административных функций. Уведомление должно приводить к конкретному сценарию: кто принимает решение, как ограничивается ущерб, можно ли поставить операции на паузу и как информируются участники.
Проведите настольное учение по компрометации ключа, ошибочному обновлению оракула и обнаружению уязвимости после выпуска. Наличие функции паузы бесполезно, если ключ недоступен или команда не знает условий её применения.
Финальный контроль допуска
- требования и инварианты утверждены владельцем процесса;
- роли и ключи соответствуют принципу минимальных полномочий;
- внешние вызовы и оракулы имеют отказоустойчивое поведение;
- тесты, анализ и независимый аудит относятся к выпускаемой версии;
- исходный код и байткод проверяемы;
- мониторинг, пауза, обновление и реагирование испытаны;
- остаточный риск письменно принят ответственными лицами.
Если хотя бы один критичный пункт нельзя подтвердить артефактом, выпуск следует остановить, а не компенсировать обещанием проверить после развёртывания.