Rust смарт-контракты养成日记（9）合约升级

Смарт-контракты по своей сути являются программами, и избежать дефектов трудно. Даже смарт-контракты, прошедшие множество тестирований и аудитов, все равно могут иметь уязвимости. Если уязвимость контракта будет использована злоумышленником, это может привести к потере активов пользователей, что может иметь серьезные последствия. Исправление уязвимостей обычно требует обновления контракта. Кроме исправления уязвимостей, добавление новых функций также требует обновления контракта. Поэтому возможность обновления контракта очень важна. В этой статье будет рассмотрен способ обновления контрактов на Rust.

1. Частые способы обновления смарт-контрактов на Solidity

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

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

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

Для решения этой проблемы можно использовать прокси-контракт (Proxy Contract). Прокси-контракт используется для хранения данных и вызывает логический контракт A с помощью deleGatecall, так что данные, которые читает и записывает контракт A, хранятся в прокси-контракте. При обновлении развертывается новый контракт B, а затем отправляется транзакция, чтобы прокси-контракт указывал на новый логический контракт B.

!

2. Популярные методы обновления контракта NEAR

На примере проекта StatusMessage рассмотрим распространенные методы обновления смарт-контрактов NEAR.

2.1 Структура данных смарт-контрактов не была изменена

Если изменить только логику контракта, не затрагивая изменения структуры данных, можно напрямую использовать near deploy для развертывания нового кода. Данные из старого контракта могут быть успешно прочитаны.

2.2 Структура данных смарт-контрактов была изменена

Если изменена структура данных контракта, повторное развертывание приведет к невозможности десериализации состояния контракта. Это связано с тем, что состояние контракта хранится в виде сериализованных данных, и после повторного развертывания структура данных в коде изменилась, но состояние осталось прежним, новая структура данных не может соответствовать старому состоянию.

2.3 Миграция обновления смарт-контрактов

NEAR предоставляет метод Migrate для помощи в обновлении смарт-контрактов. В новом смарт-контракте добавьте метод migrate:

ржавчина #[private] #[init(ignore_state)] pub fn migrate() -> Self { let old_state: OldStatusMessage = env::state_read().expect('failed'); Я { Слоганы: old_state.records, bios: LookupMap::new(b'b'.to_vec()), } }

При повторном развертывании смарт-контрактов вызывайте метод migrate:

near развертывание
--wasmFile target/wasm32-unknown-unknown/release/status_message.wasm
--initFunction 'migrate'
--initArgs '{}'
--accountId statusmessage.blocksec_upgrade.testnet

Таким образом, можно успешно развернуть новый смарт-контракт и перенести старые данные.

!

3. Безопасные аспекты обновления смарт-контрактов

Безопасность смарт-контрактов при обновлении сначала должна учитывать контроль доступа, обычно контракты могут обновляться только разработчиком или DAO. Функция обновления должна быть only owner функцией, чтобы гарантировать, что она может быть вызвана только владельцем.

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

Кроме того, разработчики при миграции контрактов могут учитывать следующие рекомендации:

• Перед функцией миграции добавьте #[init(ignore_state)], чтобы убедиться, что состояние не загружается перед выполнением функции миграции.
• После завершения миграции удалите функцию миграции, убедитесь, что функция миграции вызывается только один раз.
• Новая структура данных инициализируется во время миграции.

!