Обновление смарт-контрактов с помощью OpenZeppelin Upgradable Plugin

Зачем обновлять смарт-контракты?

В блокчейн-разработке смарт-контракты после размещения в сети становятся неизменяемыми. Неизменяемость защищает пользователей, поскольку никто не может тайно изменить код. Однако такая постоянность мешает исправлять критические ошибки или уязвимости, обнаруженные уже после запуска.

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

Поэтому возникает потребность в более эффективном решении, позволяющем обновлять смарт-контракты после запуска, при этом обеспечивая удобство для пользователей и сохраняя уровень безопасности блокчейна.

Обновляемые контракты

Обновляемый смарт-контракт — это контракт, который можно изменять после размещения. Такой подход позволяет преодолеть ограничения обычных неизменяемых контрактов. OpenZeppelin, ведущий разработчик библиотек и инструментов для смарт-контрактов, создал специальный плагин «hardhat-upgrades», упрощающий разработку и поддержку обновляемых контрактов.

Плагин OpenZeppelin Upgradable реализует архитектурный паттерн proxy. В этом подходе функциональность контракта разделяется на два слоя: прокси и реализация. Прокси-контракт — это постоянная точка входа с фиксированным адресом, с которой взаимодействуют пользователи. Контракт реализации содержит бизнес-логику. При вызове функций все обращения проходят через прокси и направляются в текущий контракт реализации, который выполняет операции и возвращает результат.

Главное преимущество такой архитектуры — при необходимости обновить логику достаточно развернуть новый контракт реализации и перенаправить на него прокси. Пользователи продолжают использовать прежний адрес, а все переменные состояния хранятся на стороне прокси и автоматически сохраняются при обновлении. Нет необходимости пересылать данные или перенаправлять пользователей на новые адреса.

Руководство по внедрению

Для внедрения обновляемых смарт-контрактов с OpenZeppelin выполните несколько шагов. Сначала инициализируйте новый проект Hardhat командой npx hardhat и выберите нужные параметры.

Далее установите плагин OpenZeppelin Upgrades командой:

npm install --save-dev @openzeppelin/hardhat-upgrades

После установки добавьте в hardhat.config.js такие require-выражения:

require('@nomiclabs/hardhat-ethers');
require('@openzeppelin/hardhat-upgrades');

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

Для размещения обновляемого контракта используйте функцию deployProxy вместо стандартного deploy. Укажите функцию-инициализатор и её параметры:

const { ethers, upgrades } = require('hardhat');
const Greeter = await ethers.getContractFactory('Greeter');
const greeter = await upgrades.deployProxy(Greeter, ['Hello!'], { initializer: 'setGreeting' });
console.log('Greeter deployed to:', greeter.address);

Чтобы обновить контракт до новой версии, создайте новый файл с доработанной логикой и примените функцию upgradeProxy с оригинальным адресом прокси:

const GreeterV2 = await ethers.getContractFactory('GreeterV2');
await upgrades.upgradeProxy('0x...original_proxy_address...', GreeterV2);

Такой подход сохраняет адрес прокси, все данные и обеспечивает плавный переход на новую реализацию.

Важные аспекты и компромиссы

Обновляемые смарт-контракты дают много преимуществ, но влекут и риски. Основная проблема — централизация: поскольку контракт можно обновлять, администратор или владелец прокси может изменять логику и получать доступ к средствам на контракте. Это противоречит принципам децентрализации блокчейна.

В истории экосистемы смарт-контрактов уже были случаи, когда злоумышленники получали приватные ключи админа и меняли реализацию контракта для кражи средств. Поэтому обновляемые контракты требуют надёжного управления ключами и, возможно, многоуровневой авторизации (мультиподписи), чтобы минимизировать риски.

Разработчикам важно оценить, оправдывает ли возможность обновления риски для их ситуации. Для критичных контрактов с большими суммами риски могут быть выше преимуществ, а для растущих проектов на ранних этапах гибкость обновления особенно полезна.

Выводы

Плагин OpenZeppelin Upgradable — это практичное решение для развития и поддержки обновляемых смарт-контрактов. Благодаря proxy pattern, контракты можно обновлять после запуска без потери данных и с сохранением пользовательского опыта. Процесс внедрения прост и близок к стандартному развертыванию контрактов.

В то же время обновляемость усиливает централизацию и предъявляет новые требования к безопасности. Разработчикам следует учитывать, соответствует ли обновляемость целям безопасности и децентрализации их проекта. При ответственном подходе и корректном управлении ключами обновляемые смарт-контракты делают разработку более гибкой и устойчивой.

Часто задаваемые вопросы

Можно ли изменить смарт-контракт?

Смарт-контракты после размещения в блокчейне неизменяемы. Однако обновляемые контракты используют proxy pattern, который позволяет изменять логику. Новая логика размещается с сохранением исходного адреса, что даёт возможность обновлять контракт без потери безопасности и данных.

Можно ли обновить смарт-контракт?

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

Как обновить смарт-контракт?

Используйте паттерн proxy: прокси-контракт делегирует вызовы контракту логики через delegatecall. Для обновления вызовите функцию upgrade и измените адрес контракта логики, чтобы добавить новые функции без изменения прокси и хранящихся данных.

Какой подход к обновлению смарт-контракта считается лучшей практикой?

Используйте проверенные фреймворки с прокси-контрактами для плавного внедрения изменений. Соблюдайте модульную структуру, разделяйте данные и логику, и тщательно тестируйте все изменения до размещения.

Какие риски и особенности безопасности при обновлении смарт-контракта?

Основные риски: уязвимость из-за централизации, ошибки в структуре хранения данных, которые могут повредить данные, мгновенные обновления (flash upgrades), создающие риск rug pull, и уязвимые пути обновления. Чтобы снизить риски, применяйте строгий контроль доступа, комплексные аудиты, timelock-механизмы и тщательно тестируйте обновления до запуска.

Какие есть типовые паттерны обновления смарт-контрактов (proxy pattern, beacon pattern и др.)?

Основные паттерны: proxy — прокси-контракт делегирует вызовы реализации, и beacon — отдельный beacon-контракт централизованно управляет обновлениями, что позволяет быстро обновлять несколько прокси.

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

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