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

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

Способи оновлення контрактів Ethereum

Смартконтракти на Ethereum мають незмінність, після розгортання їх неможливо безпосередньо змінити. Зазвичай для оновлення використовують такі способи:

1. Розгортання нового контракту, зміна адреси контракту в DApp. Недолік полягає в тому, що необхідно перенести стан даних старого контракту.

2. Архітектура, що розділяє дані та логіку. Зберігайте дані в смартконтрактах, а логіку реалізуйте в іншому контракті. Під час оновлення потрібно лише оновити логічний контракт.

3. Використання проксі-контрактів. Проксі-контракти зберігають дані та викликають логічний контракт через delegatecall, під час оновлення потрібно лише змінити адресу логічного контракту.

!

Спосіб оновлення контрактів NEAR

В якості прикладу проекту StatusMessage розглянемо методи оновлення NEAR смартконтрактів:

1. Структура даних контракту не була змінена

Якщо змінюється лише логіка контракту, без змін у структурі даних, можна безпосередньо використовувати команду near deploy для повторного розгортання нового коду. Існуючі дані залишаться.

2. Структура даних смартконтракту була змінена

Якщо змінити структуру даних, пряме повторне розгортання призведе до несумісності нової та старої структур даних, що ускладнить нормальне зчитування даних.

3. Використовуйте метод Migrate для оновлення

NEAR надає метод Migrate для допомоги в оновленні:

1. Додати метод migrate до нового смартконтракту
2. Виклик методу migrate під час розгортання для міграції даних
3. Після завершення міграції можна нормально використовувати нові функції смартконтрактів.

!

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

1. Контроль доступу - функція оновлення повинна бути функцією only owner
2. Рекомендується встановити owner на DAO, щоб уникнути ризиків централізації
3. Використовуйте #[init(ignore_state)], щоб забезпечити, що перед виконанням міграції стан не завантажується.
4. Після міграції видалити функцію міграції, щоб уникнути повторних викликів
5. Додана структура даних ініціалізується під час міграції

Завдяки розумному проектуванню плану оновлення можна досягти можливості оновлення контракту при забезпеченні безпеки, що підвищує довгострокову підтримуваність проєкту.

!