Детальний опис плану оновлення смартконтрактів Rust

Смартконтракти в основному є програмами, і неминуче можуть містити недоліки. Навіть після великої кількості тестів і аудитів можуть виникати вразливості. Якщо їх використають зловмисники, це може призвести до втрати активів користувачів, наслідки можуть бути серйозними. Тому можливість оновлення контрактів є дуже важливою, головним чином для виправлення вразливостей і додавання нових функцій. У цій статті будуть представлені поширені способи оновлення контрактів на Rust.

Плани оновлення контрактів Ethereum

Ефірні смартконтракти мають незмінність, їх неможливо змінити після розгортання. Щоб усунути вразливості або додати нові функції, звичайною практикою є повторне розгортання нового контракту. Але це призведе до зміни адреси контракту, і потрібно буде змінити всі DApp, що використовують цей контракт. Крім того, необхідно мігрувати стан даних зі старого контракту, що є трудомістким і схильним до помилок.

Для цього зазвичай використовують архітектуру, що відокремлює дані від логіки: дані зберігаються в контракті стану, а вся логіка реалізується в іншому логічному контракті. Під час оновлення потрібно лише оновити логічний контракт, без необхідності мігрувати стан даних.

Конкретно реалізація може використовувати проксі-контракт (Proxy Contract). Проксі-контракт зберігає дані, через deleGatecall викликає логічний контракт A. Під час оновлення потрібно лише розгорнути новий логічний контракт 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 під час розгортання:

поряд з розгортанням
--wasmFile target/wasm32-unknown-unknown/release/status_message.wasm
--initFunction 'migrate'
--initArgs '{}'
--accountId statusmessage.blocksec_upgrade.testnet

Так можна успішно перенести дані старого контракту до нової структури.

!

Безпека при оновленні смартконтрактів

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

2. Рекомендується встановити owner як DAO, керуючи контрактом через пропозиції та голосування.

3. Додайте #[init(ignore_state)] перед функцією міграції, щоб переконатися, що перед виконанням не завантажується стан.

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

5. Нові структури даних ініціалізуються під час міграції.

Розумне використання цих планів оновлення може забезпечити гнучке оновлення та обслуговування смартконтрактів, гарантуючи при цьому безпеку.

!