Миграция смарт-контрактов SushiSwap завершена, но возникла проблема — если команда разработчиков захочет внести изменения в протокол, то может потребоваться еще одна более масштабная миграция.
SUSHI — токен поставщика ликвидности, который выдается пользователям за размещение токенов в пулах ликвидности SushiSwap. Сообщество SushiSwap проголосовало за уменьшение вознаграждения со 100 SUSHI на блок до 50 SUSHI и с последовательным уменьшением вдвое каждые два года. Кроме того, две трети всех вновь выпущенных SUSHI будут блокироваться на один год. Эти заблокированные токены будут приносить комиссию за транзакции, но не могут быть перемещены или использованы при голосовании до истечения годовой блокировки.
Однако ограничения в коде SushiSwap делают предложенные изменения невозможными без серьезных изменений в коде, а именно еще одной миграции. Например, контракт под названием MasterChef не позволяет изменять вознаграждения, потому что уровень эмиссии жестко запрограммирован.
«В текущей версии смарт-контракта MasterChef жестко запрограммировано количество предоставляемых токенов SUSHI на блок. Это сделано с помощью переменной sushiPerBlock, которая во время создания контракта инициализируется значением 100 и не может быть изменена. Проще говоря, изменение значения переменной sushiPerBlock потребует развертывания нового смарт-контракта», — говорится в исследовательском документе IntoTheBlock.
Исследователи полагают, что можно сделать своего рода «костыль», который не потребует еще одной миграции — часть вознаграждения можно отправлять на тупиковый адрес, к которому никто не имеет доступа. То есть из 100 SUSHI, 50 будет передаваться пользователям, а 50 пойдет на тупиковый адрес.
Однако внесение других изменений или устранение каких-то еще ограничений все равно неизбежно потребует полного пересмотра смарт-контрактов SushiSwap. Дизайн контракта MasterChef (который контролирует протокол) совершенно не подлежит обновлению и фактически управляет контрактом токенов SushiToken. Поэтому для перехода на новый контракт MasterChef (например, MasterChefV2) одновременно потребуется развернуть и новый контракт токенов (SushiTokenV2).
Ограничение кода также помешает реализации предложения о выплате комиссионных на временно заблокированные токены, потому что нет возможности перенести токены из контракта MasterChef в другой контракт для назначения новых комиссионных.
«Эту часть сделать еще сложнее, — говорит исследователь. — Чтобы получать комиссионные, вы должны вложить SUSHI в контракт SushiBar, но если ваши SUSHI заблокированы на один год и находятся в контракте MasterChef, вы не сможете перевести их из MasterChef в SushiBar для получения комиссионных».
Фактически, не подлежащий обновлению дизайн контракта MasterChef создает каскадный эффект, при котором каждый смарт-контракт, находящийся под его контролем, также требует обновления для внесения изменений. Единственное решение — это перенос каждого смарт-контракта на совершенно новую версию.
Однако такой процесс миграции будет более трудоемким, чем предыдущий. Полная миграция каждого смарт-контракта будет включать создание моментального снимка всех балансов пользователей и выпуск новых токенов после развертывания новых контрактов, а также перенос данных отдельных пользователей из всех пулов ликвидности SushiSwap. Перед снимком пользователям также необходимо отключить все токены SUSHI в контракте SushiBar и в пулах ставок SUSHI/ETH.
Хотя эти действия не кажутся такими уж сложными, смарт-контракты, которые полагаются на SushiToken, могут перестать работать, если они не будут обновлены для использования нового контракта SushiTokenV2.
Разработчики и новое управление SushiSwap еще одну миграцию не одобрили.
«Никакой миграции в ближайшее время», — ответил 0xMaki, ведущий разработчик SushiSwap, который участвует в проекте с самого начала.
0xMaki сказал, что они хотели бы реализовать предложения, но, похоже, этот процесс потребует больше обдумывания. Некоторые члены команды не так категоричны, но они тоже пока не готовы выполнить его на практике.