Прокси контракты, как они работают, какие бывают и как это работает в EVMPack. Часть 1
Прокси-контракты: Сравнение подходов OpenZeppelin и EVMPack
Обновление смарт-контрактов в mainnet - задача нетривиальная. Развернутый код неизменяем, и любая ошибка или необходимость добавить функционал требуют сложных и рискованных миграций. Для решения этой проблемы используется паттерн "прокси", позволяющий обновлять логику контракта, сохраняя его адрес и состояние.
Что такое прокси-контракт?
Прокси-контракт - это, по сути, "пустая" обертка с очень важной деталью - кастомной `fallback` функцией. Эта функция - фундаментальная часть EVM, она автоматически вызывается, когда кто-то обращается к контракту с вызовом, не соответствующим ни одной из явно объявленных функций.
Вся магия происходит именно здесь. Когда вы вызываете, например, `myFunction()` на адресе прокси, EVM не находит такой функции в самом прокси. Срабатывает `fallback`. Внутри этой функции находится низкоуровневый код (inline assembly), который берет все данные вашего вызова (`calldata`) и перенаправляет их с помощью `delegatecall` на адрес "логического" контракта.
Особенность `delegatecall` в том, что код логического контракта исполняется, но все изменения состояния (`storage`) происходят в контексте прокси-контракта. Таким образом, прокси хранит данные, а логический контракт - код. Для обновления достаточно просто указать прокси новый адрес реализации.
Классический подход: Hardhat + OpenZeppelin
Самый популярный стек для разработки - это Hardhat в связке с плагинами от OpenZeppelin. Плагин hardhat-upgrades значительно упрощает работу с прокси, абстрагируясь от ручного развертывания всех необходимых компонентов.
Рассмотрим реальный код из теста для контракта Blog.
Пример 1: Процесс, управляемый с клиента
Вот как выглядит развертывание прокси с помощью плагина в JavaScript-тесте:
Это решение удобно, но его фундаментальная особенность в том, что вся логика оркестрации находится на стороне клиента, в JavaScript. Выполнение скрипта инициирует серию транзакций. Этот подход хорошо подходит для администрирования или разработки, но не для предоставления возможности создания экземпляров контракта другим пользователям или смарт-контрактам.
Ончейн-подход: EVMPack
EVMPack переносит логику оркестрации ончейн, действуя как ончейн-менеджер пакетов, аналогично npm или pip.
Пример 2: Ончейн-фабрика EVMPack
Предположим, разработчик Blog зарегистрировал свой пакет в EVMPack под именем "my-blog". Любой пользователь или другой смарт-контракт может создать экземпляр блога одной транзакцией через фабрику EVMPackProxyFactory:
Важно понимать, что вызывать usePackageRelease можно не только из другого контракта. Представьте себе веб-интерфейс (dApp), где пользователь нажимает кнопку "Создать мой блог". Ваш JavaScript-клиент, используя ethers.js, делает одну транзакцию - вызов этой функции. В результате пользователь с ходу получает готовое "приложение" на стороне блокчейна - его личный, обновляемый экземпляр контракта. К тому же, это очень экономно по газу, так как каждый раз разворачивается только легковесный прокси-контракт (и опционально его админ), а не вся тяжеловесная логика реализации. Да, останется задача отрисовать для него UI, но это уже другая история. Главное - мы заложили мощную и гибкую базу.
Процесс, который ранее был в JS-скрипте, теперь находится ончейн, стандартизирован и доступен для всех участников сети.
Сравнение подходов
А как обновляться?
Процесс обновления так же прост, но устроен хитрее, чем можно было предположить. Владелец прокси вызывает функцию upgradeAndCall на своем персональном контракте EVMPackProxyAdmin (который фабрика создала для него автоматически).
Этот контракт-админ не обращается к реестру EVMPack напрямую. Вместо этого он дает команду самому прокси-контракту обновиться до указанной версии.
Как и в случае с созданием, процесс полностью происходит ончейн, он безопасен (вызывается только владельцем) и не требует запуска каких-либо внешних скриптов.
Такая архитектура также дает важные преимущества в безопасности. Во-первых, есть четкое разделение ролей: простой контракт-админ отвечает только за авторизацию обновления, что минимизирует его поверхность атаки. Во-вторых, так как прокси сам знает свое имя пакета и ищет реализацию по версии, это защищает владельца от случайной или злонамеренной ошибки - невозможно обновить прокси до реализации от другого, несовместимого пакета. Владелец оперирует понятными версиями, а не сырыми адресами, что снижает риск человеческой ошибки.
Преимущества ончейн-фабрики
Подход EVMPack превращает создание прокси в публичный, компонуемый ончейн-сервис. Это создает новые возможности:
DeFi протоколы, позволяющие пользователям создавать изолированные обновляемые хранилища.
DAO, которые могут автоматически разворачивать новые версии продуктов по результатам голосования.
NFT-проекты, где каждая NFT может быть прокси с кастомизируемой логикой.
Это делает ончейн-код по-настоящему переиспользуемым, по аналогии с npm-пакетами.
Итог
Плагин hardhat-upgrades - это эффективный инструмент, решающий задачу для разработчика.
EVMPack предлагает более высокий уровень абстракции, перенося процесс на блокчейн и создавая из него публичный сервис. Это не просто управление прокси, а инфраструктура для нового поколения децентрализованных приложений, ориентированных на компонуемость и взаимодействие контрактов между собой.
В следующей части разберём Beacon прокси
