Версионирование смарт-контрактов и миграция состояний из одной версии в другую.
Основная идея заключается в создание нового контракта и перенос в него состояния из старого контракта. Изначально новый развернутый контракт будет иметь пустое хранилище.
Процесс перехода на новую версию может выглядеть следующим образом:
- Создание нового экземпляра контракта.
- Перенос состояния или миграция данных. Это может быть реализовано двумя способами:
- On-chain. Миграция при помощи смарт-контрактов.
- Off-chain. Сбор данных со старого контракта происходит за пределами блокчейна. На последнем этапе собранные данные записываются по адресу нового контракта.
- Обновить адрес нового контракта для всех контрактов, сервисов и клиентских приложений. То есть заменить старый адрес, на новый.
- Убедить пользователей перейти на использование нового контракта. Если это контракт токена, вам также необходимо связаться с биржами, чтобы отказаться от старого контракта и использовать новый контракт.
Важно ! Перенос данных относительно несложная и простая операция, но она может занять значительное время и потребовать значительных затрат на газ. Также стоит помнить, что не все пользователи захотят перейти на новую версию, а значит необходимо продумывать меры поддержки для таких пользователей и старых версий контрактов.
Миграция при помощи смарт-контрактов. Такая миграция может быть реализована двумя способами.
- За счет пользователя. Когда мы предлагаем пользователю заплатить за газ. Мы пишем некий функционал миграции, который при вызове определяет пользователя и переносит функционал на новый контракт.
- За счет мигратора. Мы можем это делать за счет протокола и переносить состояния в ручную или при помощи еще одного контракта. В этом случае затраты на газ покрывает компания(владельцы контрактов, протокола).
Считываем все данные из блокчейн. Если был взлом или сбой, то читать необходимо до блока со сбоем. При этом работу действующего смарт-контракта лучше приостановить(если это возможно). Все публичные примитивы легко считываются. Для приватных переменных чуть сложнее, но можно полагаться на события(Events) или использовать метод getStorageAt() для чтения таких переменных из хранилища. Массивы также легко восстанавливаются, поскольку известно количество элементов. С mapping все намного сложнее, так как ключи не сохраняются, поэтому можно полагаться только на события(Event). После сбора всех данных необходимо записать их на новый контракт.
Чтобы восстановить данные из событий необходимо понимать, как события хранятся, как индексируются и как фильтруются за пределами блокчейн. Про это хорошо описано тут.
Одним из вариантов сбора данных является использования сервиса Google BigQuery API
Подробнее с примерами смотреть тут