Подробное объяснение плана обновления смарт-контрактов на Rust

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

Планы по обновлению контрактов Ethereum

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

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

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

!

План обновления контракта NEAR

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

Структура данных контракта не изменена

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

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

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

Используйте метод Migrate для обновления

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

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

!

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

1. Контроль доступа: функция обновления должна быть только для владельца, и может вызываться только владельцем.

2. Рекомендуется установить владельца как DAO, управляя смарт-контрактами через предложения и голосование.

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

4. После завершения миграции удалите функцию миграции, чтобы убедиться, что она вызывается только один раз.

5. Новая структура данных инициализируется во время миграции.

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

!