Деплой и верификация смарт-контракта: ключи, скрипты, Etherscan

Безопасный деплой смарт-контракта — это четыре шага: подготовить ключ деплоя в зашифрованном keystore или на аппаратном кошельке, развернуть контракт воспроизводимым скриптом, опубликовать исходный код в обозревателе и сразу передать административные права мультиподписи. Самая частая ошибка — приватный ключ в файле .env, который попадает в репозиторий, логи CI или на сервер подрядчика. Ключ деплоя должен давать минимум власти и жить минимум времени.

Ключ деплоя: где хранить

Адрес, с которого разворачивают контракт, часто получает права владельца по умолчанию. Если ключ утёк, злоумышленник может перехватить права до того, как вы их передадите, или развернуть поддельные контракты от «официального» адреса. Поэтому к ключу деплоя относятся как к ключу от сейфа.

В Foundry ключ импортируют в зашифрованное хранилище командой cast wallet import deployer --interactive: ключ вводится один раз, шифруется паролем и хранится локально. В скриптах затем указывают --account deployer, и пароль спрашивается при запуске. Ключ не появляется в истории командной строки и в файлах проекта.

Отдельный адрес под деплой

Используйте для деплоя новый адрес, на котором нет ничего, кроме суммы на газ. После деплоя и передачи прав на нём не должно остаться ни ролей, ни средств. Так утечка ключа в будущем ничего не даст. Секреты CI-конвейера, RPC-ключи и API-ключ обозревателя храните в секретах CI, а не в коде, и ограничивайте их права. Как злоумышленники охотятся за токенами разработчиков, видно по истории GhostAction со взломом аккаунтов GitHub.

Скрипт деплоя вместо ручных действий

Деплой через интерфейс Remix или вручную через кошелёк трудно повторить и проверить. Скрипт фиксирует порядок, параметры и адреса. В Foundry это контракт в папке script, который запускают командой forge script. Сначала скрипт прогоняется без отправки транзакций, затем с флагом --broadcast. Foundry сохраняет результаты в папке broadcast: адреса, хеши транзакций, параметры. Документация — в книге Foundry.

1. forge script script/Deploy.s.sol --rpc-url sepolia --account deployer — прогон без отправки, проверка параметров.
2. forge script script/Deploy.s.sol --rpc-url sepolia --account deployer --broadcast --verify — деплой в тестовую сеть с верификацией.
3. Ручная проверка сценариев в тестовой сети через интерфейс и кошелёк.
4. Тот же скрипт для основной сети, лучше с аппаратным кошельком: --ledger вместо --account.
5. Сохранение файлов из broadcast в репозиторий как журнала развёртываний.

В Hardhat 3 аналогичную роль играют модули Hardhat Ignition. Важно не средство, а принцип: деплой воспроизводим, параметры лежат в репозитории, результат записан.

Параметры, которые стоит проверить перед отправкой

• Адреса владельца, казначейства, мультиподписи и оракулов для этой конкретной сети.
• Версия компилятора, evmVersion и настройки оптимизатора совпадают с теми, что прошли тесты и аудит.
• Начальные параметры: эмиссия, лимиты, комиссии, задержки таймлока.
• Цена газа: деплой большого контракта в момент пиковой загрузки обходится заметно дороже.

Верификация исходного кода

Верификация публикует исходный код и подтверждает, что он компилируется в тот байт-код, который развёрнут по адресу. Без неё пользователи видят только байт-код и вынуждены верить на слово. Неверифицированный контракт выглядит подозрительно и для аудитории, и для бирж.

Если верификация не прошла при деплое, её можно выполнить позже командой forge verify-contract с адресом, путём к контракту и аргументами конструктора. Частые причины отказа: другая версия компилятора, другие настройки оптимизатора, неверно закодированные аргументы конструктора. Для прокси верифицируют и прокси, и реализацию, а затем отмечают связь в обозревателе.

Деплой обновляемых контрактов

Если контракт стоит за прокси, деплой состоит из двух частей: реализации и прокси с вызовом initialize в той же транзакции. В OpenZeppelin 5.6 и новее прокси без данных инициализации развернуть нельзя, это защищает от захвата неинициализированного прокси. Плагины OpenZeppelin Upgrades для Foundry и Hardhat делают оба шага и проверяют совместимость storage при последующих обновлениях. Подробнее — в статье о proxy и UUPS.

Типичные ошибки деплоя

• Ключ основной сети использовался и в тестовой, и лежал на общем сервере.
• Скрипт содержит адреса тестовой сети, и в основную сеть ушли неверные параметры.
• Контракт развёрнут, но не верифицирован, а аргументы конструктора уже никто не помнит.
• Права остались у адреса деплоя, потому что передачу «отложили на завтра».
• Прокси развёрнут отдельно от инициализации, и между транзакциями прошло время.
• Адрес нового контракта опубликован только в одном канале, а в другом остался старый.

Одинаковые адреса в разных сетях

Если продукт выходит в несколько сетей, удобно, чтобы адрес контракта был одинаковым. Для этого используют детерминированный деплой через CREATE2, где адрес зависит от адреса фабрики, соли и кода контракта. В OpenZeppelin 5.7 появилась библиотека Create3, где адрес зависит только от соли и развёртывающего, а не от байт-кода. Одинаковые адреса упрощают документацию и мешают мошенникам подсовывать похожие контракты. Какие сети выбрать — в статье о выборе сети.

После деплоя

1. Передайте права: владельца, роли, право обновления — мультиподписи или таймлоку. Для Ownable2Step не забудьте вызвать acceptOwnership() из мультиподписи.
2. Проверьте ончейн, что у адреса деплоя не осталось ни одной роли. Как устроены роли — в статье о контроле доступа.
3. Опубликуйте официальные адреса на сайте и в документации, предупредите о поддельных копиях.
4. Включите мониторинг событий и административных вызовов.
5. Выведите остаток газа с адреса деплоя и больше его не используйте.

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