Обновление и поддержка смарт-контрактов
Смарт-контракт в production — это не конец, это начало. Протоколы меняются: появляются новые требования, находятся уязвимости, меняются внешние зависимости (оракулы, токены, другие протоколы). Управление изменениями в immutable системе — отдельная инженерная дисциплина.
Самая дорогостоящая ошибка в этой области — не уязвимость в логике, а storage collision в proxy-паттерне. Это когда новая версия реализации случайно перезаписывает данные предыдущей из-за изменения порядка переменных. Пример из реальной жизни: команда добавила одну переменную в начало контракта-реализации, и весь balances mapping сдвинулся на один слот. Баланс пользователей стал читаться как адреса. Деплой пришлось откатывать через экстренный multisig в 3 ночи.
Proxy-паттерны: выбор архитектуры определяет стоимость поддержки
Transparent Proxy (EIP-1967)
Классика от OpenZeppelin. ProxyAdmin управляет обновлениями, пользователи взаимодействуют напрямую с proxy. Проблема: при каждом вызове proxy проверяет, является ли msg.sender admin'ом. Это дополнительный SLOAD — около 2100 gas при первом обращении к слоту.
Подходит для: большинства протоколов без микро-оптимизации газа.
UUPS (EIP-1822)
Логика обновления перенесена в контракт-реализацию. Proxy легче, меньше gas на обычные вызовы. Но: если задеплоить реализацию без функции обновления — контракт становится неизменяемым навсегда. Это не гипотетика — несколько проектов оказались в этой ситуации.
// UUPS: функция upgrade должна быть в реализации
function _authorizeUpgrade(address newImplementation)
internal override onlyOwner {}
Подходит для: gas-чувствительных протоколов с тщательным review процессом деплоя.
Beacon Proxy
Один beacon-контракт хранит адрес реализации. Сотни proxy-контрактов читают из beacon. Обновление всех proxy — один вызов на beacon. Критично для factory-паттернов: lending позиции, NFT коллекции с логикой, per-user vaults.
Diamond Pattern (EIP-2535)
Позволяет разбить логику на facets — несколько контрактов реализации. Обходит лимит размера контракта (24KB). Сложен в поддержке: storage layout нужно контролировать вручную через DiamondStorage паттерн.
Используем только когда контракт объективно не влезает в лимит. Иначе усложнение не оправдано.
Как мы проводим upgrade
1. Анализ storage layout
Перед написанием новой версии — сравниваем storage layout старой и новой реализации. Foundry предоставляет команду forge inspect ContractName storage-layout. Критическое правило: никогда не изменяем порядок и типы существующих переменных. Только добавляем в конец.
// ❌ Нельзя: balances сдвинется с slot 0 на slot 1
contract TokenV2 {
address public newFeature; // добавлено в начало
mapping(address => uint256) public balances;
}
// ✅ Можно: новые переменные только в конец
contract TokenV2 {
mapping(address => uint256) public balances;
address public newFeature; // добавлено в конец
}
Для UUPS и Transparent proxy OpenZeppelin предоставляет @openzeppelin/upgrades-plugins для Hardhat и Foundry — плагин автоматически проверяет совместимость storage layout при обновлении.
2. Миграция данных
Если обновление требует преобразования данных (например, изменение структуры маппинга), пишем отдельный миграционный скрипт. Для небольших наборов данных — on-chain миграция в initializer новой версии. Для больших — off-chain скрипт с пакетными транзакциями.
3. Staging деплой
Всегда тестируем upgrade на testnet fork реального mainnet-состояния:
# Форк mainnet с реальным состоянием контракта
anvil --fork-url $MAINNET_RPC --fork-block-number latest
# Деплой новой реализации и upgrade
forge script UpgradeScript --fork-url http://localhost:8545
Проверяем, что все storage слоты остались корректными, что старые данные читаются правильно, что новая функциональность работает.
4. Multisig + Timelock цепочка
Production upgrade идёт через: proposal в multisig → delay в Timelock → исполнение. Минимальный timelock для upgrade — 48 часов. За это время community и аудиторы могут проверить новую реализацию.
Поддержка и мониторинг
После деплоя настраиваем мониторинг через Tenderly Alerts или OpenZeppelin Defender Sentinel: уведомления о крупных транзакциях, необычных паттернах вызовов, изменениях ключевых переменных.
Для критических событий (паузирование, смена owner, крупный вывод) — немедленные alert'ы в Telegram/PagerDuty.
Типичный retainer для поддержки: мониторинг + приоритетный response на инциденты + quarterly review кодовой базы на новые уязвимости. Параметры и стоимость — индивидуально.
Типичные ошибки при upgrade
Забыть вызвать __init родительских контрактов в новом initializer. OpenZeppelin контракты с Initializable требуют вызова initializer-цепочки при каждом upgrade через reinitializer(N). Пропуск инициализации AccessControl или ERC20 приводит к потере ролей или некорректному состоянию.
Upgrade без проверки на testnet. «Мы же только добавили view-функцию» — и тем не менее storage layout изменился из-за унаследованного контракта.
Отсутствие плана отката. Если upgrade пошёл не так, нужно вернуться к предыдущей реализации. Это возможно в Transparent и UUPS proxy, если сохранить адрес старой реализации. Убеждаемся, что этот адрес есть в истории деплоя.