Разработка прокси-контрактов UUPS и Transparent Proxy

Разработка прокси-контрактов (UUPS, Transparent Proxy)

Контракт задеплоен на mainnet, в нём нашли критическую уязвимость. Без прокси — всё, миграция вручную, уговаривать пользователей переходить на новый адрес, хоронить старый TVL. Мы понимаем: с правильно настроенным прокси — апгрейд через мультисиг за 15 минут, адрес контракта не меняется. Но «правильно настроенным» — ключевое словосочетание. Прокси-паттерны добавляют целый класс уязвимостей, которых нет в immutable-контрактах: storage collision, неинициализированные имплементации, потеря права апгрейда. Наша команда за 7 лет реализовала десятки прокси-систем для DeFi-протоколов с TVL до $500M. Выбор паттерна — не техническая формальность, а архитектурное решение, влияющее на gas, безопасность и управление. Ниже разберём два основных паттерна — Transparent Proxy и UUPS, их компромиссы и типовые ошибки, а также как мы проектируем и тестируем такие системы.

Проблемы, которые решаем

Главная задача — дать возможность исправлять ошибки и добавлять фичи без миграции пользователей. Но за это приходится платить:

• Storage collision: при апгрейде переменные могут перезаписаться — молчаливая порча данных.
• Неинициализированная имплементация: если забыть вызвать initialize(), злоумышленник может захватить контракт.
• Потеря права апгрейда: имплементация без upgradeTo навсегда блокирует обновление.
• Gas overhead: Transparent Proxy добавляет SLOAD на каждый вызов, что критично для высоконагруженных протоколов. Например, при 10 000 транзакций в день дополнительный расход газа составляет 1 000 000 gas ($20 по текущим ценам).

Два паттерна и их реальные отличия

Transparent Proxy

Классическая реализация из OpenZeppelin EIP-1967. Proxy-контракт содержит логику маршрутизации: если вызывает admin — он управляет прокси напрямую (upgrade, changeAdmin). Если вызывает любой другой — вызов делегируется в имплементацию.

Проблема: каждый вызов контракта требует дополнительного SLOAD для чтения адреса admin (100 gas по EIP-2929) и сравнения с msg.sender. На горячих путях — это постоянный overhead. Для протокола с миллионами вызовов в день — ощутимо. Второй момент: ProxyAdmin — отдельный контракт, который владеет правами апгрейда. Это добавляет ещё один контракт в систему, ещё одну точку ответственности за ключи.

Почему UUPS сегодня — стандарт индустрии?

Логика апгрейда перенесена из proxy в имплементацию. Proxy сам по себе — тупой делегатор без какой-либо логики маршрутизации по caller. Нет дополнительного SLOAD на каждый вызов — дешевле в эксплуатации. OpenZeppelin начиная с версии 4.x рекомендует UUPS для новых проектов, что подтверждено в официальном репозитории.

Но есть критический риск: если задеплоить новую имплементацию без функции upgradeTo (забыть унаследовать UUPSUpgradeable, или намеренно убрать в целях экономии газа) — прокси навсегда потеряет возможность апгрейда. Контракт заморожен на текущей версии без возможности исправления.

Реальный кейс: несколько протоколов на UUPS столкнулись с проблемой неинициализированной имплементации. Имплементация деплоилась без вызова initialize(), и атакующий вызывал initialize() первым, становясь owner, после чего upgradeTo() позволял подменить имплементацию на самоуничтожающийся контракт. Все прокси, указывавшие на эту имплементацию, превращались в нерабочие. Решение: _disableInitializers() в конструкторе имплементации — обязательный паттерн в OpenZeppelin 4.3+.

Как избежать storage collision на этапе проектирования?

Суть проблемы: proxy и имплементация используют один storage. Если в proxy есть переменная в slot 0, а в имплементации тоже есть переменная в slot 0 — они перезаписывают друг друга.

EIP-1967 решает это для служебных переменных proxy (адрес имплементации, адрес admin) — они хранятся в псевдослучайных слотах на основе keccak256 хэша строки, практически исключая коллизию с пользовательским storage.

Но storage имплементации при апгрейдах — ответственность разработчика. Если в V1 была структура:

uint256 public totalSupply;   // slot 0
address public owner;         // slot 1

А в V2 добавили переменную перед существующими:

bool public paused;           // slot 0 — КОЛЛИЗИЯ с totalSupply
uint256 public totalSupply;   // slot 1 — КОЛЛИЗИЯ с owner
address public owner;         // slot 2

totalSupply теперь читает то, что раньше было owner (адрес, интерпретированный как число). Молчаливая порча данных, без reverting транзакций, без ошибок компилятора.

ERC-7201 (Namespaced Storage Layout) решает это радикально. Все переменные имплементации собираются в одну struct, которая хранится в заранее вычисленном слоте:

bytes32 private constant STORAGE_LOCATION = 
    keccak256(abi.encode(uint256(keccak256("myprotocol.storage.v1")) - 1)) & ~bytes32(uint256(0xff));

Новые переменные добавляются в конец struct. Никаких коллизий со служебными слотами proxy, никаких проблем при апгрейдах. Это текущий best practice для production UUPS-контрактов.

Как инициализировать прокси-контракт?

В прокси-архитектуре конструктор имплементации не выполняется в контексте proxy — он выполняется только при деплое самой имплементации. Поэтому все инициализирующие действия (установка owner, начальные параметры) переносятся в функцию initialize(), защищённую initializer модификатором.

Распространённый баг: initialize() забыли вызвать после деплоя proxy. Контракт работает, но owner не установлен — первый, кто вызовет initialize(), станет владельцем. В результате инцидента с контрактом WalletLibrary было потеряно 587 ETH (на момент атаки ~$1.5M) из-за захвата неинициализированного контракта. Решение: деплой-скрипт должен атомарно деплоить proxy и вызывать initialize() в рамках одного скрипта. Никогда не деплоить прокси без немедленной инициализации.

Как мы реализуем прокси-контракты

Базовая библиотека — OpenZeppelin Upgrades (Hardhat plugin или Foundry-совместимый вариант). Плагин автоматически проверяет storage layout совместимость между версиями при каждом апгрейде — это обязательный инструмент, не опциональный.

Для UUPS выбираем UUPSUpgradeable из OpenZeppelin 5.x. Для систем, где апгрейд должен управляться DAO или мультисигом — AccessControlUpgradeable с ролью UPGRADER_ROLE, выданной Gnosis Safe адресу.

Тестируем апгрейды через Foundry fork-тесты: форкаем mainnet, симулируем апгрейд, проверяем, что все storage-переменные сохранили значения, функции работают корректно, новые переменные инициализированы правильно.

Когда прокси не нужен

Immutable-контракт проще, дешевле в аудите, вызывает больше доверия у пользователей (нет риска rug через апгрейд). Если логика стабильна и риск критической ошибки минимален — прокси добавляет сложность без необходимости. Для DeFi-протоколов с большим TVL обычно лучше immutable + timelock на параметрах, чем upgradeability без формального governance. Однако, если вы предвидите необходимость обновлений — прокси незаменим.

Процесс работы и сроки

1. Аналитика требований — 1-2 дня. Выбор паттерна, определение ролей и таймлоков.
2. Проектирование storage layout — 1 день. Схема с ERC-7201, проверка на коллизии.
3. Разработка имплементаций — 2-3 дня. Solidity код с тестами на Foundry (fork).
4. Развёртывание и инициализация — 1 день. Атомарный деплой через скрипт.
5. Тестирование апгрейда — 1 день. Проверка совместимости хранения.
6. Внутренний аудит — 2-4 дня. Включает Slither, Mythril и ручной review.

Общие сроки: от 5 рабочих дней для простого прокси до 2-3 недель для сложных систем с governance и несколькими имплементациями. Свяжитесь с нами для точной оценки вашего проекта — мы рассчитаем сроки под ключ.

Гарантия и опыт

Мы разработали более 50 прокси-систем для DeFi, NFT и инфраструктурных проектов. 7+ лет практического опыта в Solidity и Ethereum. Каждый проект сопровождаем аудитом и предоставляем гарантию корректности апгрейда на тестнете. Получите консультацию по выбору паттерна и архитектуры прокси для вашего проекта — это бесплатно.

Разработка смарт-контрактов

Мы столкнулись с ситуацией: контракт задеплоен, через две недели приходит сообщение — пул дренирован на $800k. Смотрим транзакцию в Tenderly: атакующий вызвал deposit(), внутри callback на ERC-777 повторно вызвал withdraw() — баланс обновился только после второго выхода. Классическая reentrancy, но не через ETH transfer, а через хук ERC-777. ReentrancyGuard стоял только на withdraw().

Такие случаи — не редкость. Смарт-контракт — это финансовая логика без возможности пропатчить её ночью. Наша команда разрабатывает контракты под ключ, встраивая защиту от reentrancy, MEV и gas-атак на ранних этапах.

Как мы разрабатываем смарт-контракты под ключ

Начинаем с аудита бизнес-логики и выбора стека. Solidity 0.8.x — стандарт для EVM-совместимых чейнов: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. Для Solana используем Rust и Anchor: модель аккаунтов и программ требует явного объявления всех ресурсов. Для проектов с формальной верификацией подходит Move (Aptos, Sui) — линейные типы языка исключают копирование ресурсов на уровне компилятора. Vyper выбираем для контрактов, где критична простота аудита (Curve Finance).

Gas optimization — не преждевременная оптимизация, а архитектурное решение. На Ethereum mainnet деплой плохо спроектированного контракта может стоить 2–5 ETH только из-за неоптимального storage layout. Переупаковка структуры Proposal с 7 слотов до 4 сэкономила 18k gas на каждом голосовании — около $1.5 при gas price 30 gwei. Экономия на масштабе протокола с тысячами голосований в день даёт ощутимую годовую выгоду.

Типичные ошибки в gas: передача массивов через memory вместо calldata в external функциях (дороже в 2–3 раза); использование require с длинными строками вместо custom error error InsufficientBalance(...). Кастомные ошибки дешевле на 50–200 gas на revert и передают структурированные данные фронтенду.

Почему аудит смарт-контрактов критичен для безопасности

Аудит — не разовая проверка, а встроенный этап разработки. Используем три уровня:

1. Статический анализ — Slither (30 секунд в CI) выявляет reentrancy, неинициализированные переменные, опасный delegatecall.
2. Фаззинг и invariant тесты — Foundry с --fuzz-runs 50000 находит edge cases, которые пропускают сотни unit-тестов. Реальный кейс: AMM контракт с кастомной математикой после 150 тестов в Hardhat — Foundry нашёл integer division truncation, позволявший пылевой атаке копить dust на контракте. Echidna проверяет инварианты («сумма всех балансов ≤ totalSupply»).
3. Ручной code review — наши инженеры с опытом 10+ лет в блокчейне выявляют логические ошибки, которые не ловят инструменты. Для протоколов с TVL > $1M обязателен внешний аудит со стороны Trail of Bits, Consensys Diligence или OpenZeppelin. Срок — 2–4 недели.

Любой апгрейдируемый протокол должен иметь timelock. TimelockController из OpenZeppelin: операция предлагается → ждёт минимальный delay (48–72 часа) → выполняется. Без timelock один скомпрометированный deployer wallet = потеря всего пула.

Какие паттерны апгрейда выбираем

Storage collision — главная опасность прокси. Implementation v2 не должен добавлять переменные перед существующими. OpenZeppelin Upgrades plugin для Hardhat и Foundry проверяет это автоматически, но только при использовании его API.

Как защитить контракт от MEV и front-running

На Ethereum mainnet транзакции в mempool видны всем. MEV-боты проводят sandwich-атаки на DEX, фронтраннинги минтинга и governance. Решение: commit-reveal scheme для аукционов, приватная отправка через Flashbots PROTECT RPC. EIP-7702 и PBS (proposer-builder separation) меняют картину, но пока не массово.

Процесс разработки

1. Аналитика — спецификация функций, диаграмма вызовов, анализ edge cases. Без этого кодинг начинается впустую.
2. Разработка — Solidity/Rust с тестами параллельно. Тест → код → рефакторинг. Используем Foundry для fuzz и invariant тестов.
3. Внутренний аудит — Slither + Echidna + ручной code review. Foundry invariant tests для протокольных инвариантов.
4. Внешний аудит — для проектов с реальными деньгами. Срок: 2–4 недели.
5. Деплой — Foundry scripts или Hardhat Ignition с verify на Etherscan. Gnosis Safe для ownership transfer сразу после деплоя.
6. Мониторинг — Tenderly alerts, OpenZeppelin Defender, Forta Network.

Что входит в работу

• Документация на архитектуру и спецификацию контракта (NatSpec).
• Исходный код с репозиторием и CI (Slither, Foundry, coverage).
• Развёрнутая версия контракта с verify на блокчейн-эксплорере.
• Результаты аудита (внутреннего и внешнего по запросу).
• Доступы к мониторингу и управлению (Gnosis Safe).
• Гарантия на код: фиксы критических багов в течение месяца после деплоя.
• Консультация по интеграции с веб-интерфейсом (wagmi, RainbowKit).

Сроки ориентировочно

• ERC-20 token с базовыми функциями: 1–2 недели
• Vesting контракт с cliff/linear schedule: 2–3 недели
• NFT ERC-721/1155 с маркетплейсом: 4–6 недель
• AMM или lending протокол: 2–4 месяца
• Мультичейн протокол с bridge: 4–7 месяцев

Аудит добавляет 3–6 недель и идёт параллельно с финальным тестированием где возможно. Стоимость рассчитывается индивидуально — свяжитесь с нами, и мы оценим ваш проект бесплатно.

Закажите разработку смарт-контракта — получите консультацию по архитектуре и защите от reentrancy, MEV и gas-атак. Хотите обсудить детали? Напишите нам — мы подберём оптимальный стек под вашу задачу.