Деплой смарт-контрактов на Near: Rust, аккаунты и storage

Деплой смарт-контрактов на Near: узкие места и сбои

Деплой смарт-контрактов Near — это не одна операция, а две независимые: загрузка кода в хранилище аккаунта и вызов метода-инициализатора, который создаёт состояние. Ручной порядок ломается предсказуемо: код обновили, а схему состояния к нему — нет. Контракт публикуется успешно, но первый же вызов падает на разборе хранимых данных, и аккаунт остаётся в состоянии, из которого штатного выхода уже нет.

Вторая категория сбоев — сборка. Если версия компилятора, набор зависимостей и параметры оптимизации не зафиксированы, один и тот же исходник даёт разные артефакты. Невоспроизводимая сборка означает, что опубликованный код невозможно сверить с репозиторием: нельзя ни подтвердить отсутствие посторонних правок, ни собрать ровно ту же версию для возврата.

Третья — доступ. Ключи аккаунта, под которыми шла публикация, часто живут в истории команд, в переписке или на машине одного инженера. Потеря ключей аккаунта не останавливает уже работающий контракт, но закрывает возможность обновления: аккаунт остаётся без владельца, и вернуть управление нечем.

Отдельно — отсутствие отката. Публикация в основной сети необратима, и если предыдущий код не сохранён и не проверен на тестовой сети, ошибка публикации контракта всплывает уже на живых пользователях. Ниже разбираем, как это закрывается.

Что даёт управляемая выкладка: скорость и предсказуемость

Управляемая выкладка начинается с повторяемой сборки: один и тот же исходник и зафиксированные зависимости дают идентичный артефакт, поэтому проверенное на тестовой сети уходит в основную без расхождений. Время до рабочего запуска на чистом окружении укладывается в один проход — подготовка аккаунтов, публикация и инициализация состояния идут по заранее описанному порядку, а не по памяти исполнителя.

Доля неудачных публикаций в сети Near падает первой. До наведения порядка срывалась примерно каждая третья попытка: аккаунт не создан, ключ не тот, на хранилище не хватает покрытия под состояние контракта. Теперь эти проверки проходят до отправки транзакции, и в основную сеть уходит только то, что уже отработало на копии.

Время восстановления после сбоя сокращается с часов до десятков минут. Известно, какой артефакт развёрнут, какое состояние ему соответствует и на какую версию можно вернуться — откат превращается в операцию вместо расследования.

Вместе с этим уходит целый класс отказов: неверные адреса аккаунтов, незакрытые миграции состояния, ручные правки, не попавшие в историю. Выкладка перестаёт быть событием с напряжением и становится рутинным шагом, который можно поручить дежурному инженеру.

Режимы выкладки: сравнение подходов и ограничений

Режимы выкладки различаются не инструментом запуска, а тем, кто инициирует публикацию и что в этот момент происходит с данными контракта. Код обновляется одной операцией, а состояние остаётся прежним — если структура записей изменилась, новый код начинает читать несовместимые данные. Поэтому в сети Near выбор режима определяется тремя параметрами: обратимостью, требованиями к доступам и ценой ошибки.

Режимы чаще комбинируют, чем выбирают один: код уходит через конвейер, перенос состояния выполняется отдельным шагом с предварительной копией, а смена аккаунта планируется как отдельная кампания — с периодом, когда оба адреса работают параллельно и трафик переводится постепенно.

Этапы инженерной работы: от аудита до передачи

Процесс строим так, чтобы обновление контракта выходило предсказуемо, а состояние не приходилось пересобирать вручную. Пропуск аудита схемы хранения или прав ключей обычно всплывает уже после развёртывания в основной сети — когда исправление стоит дороже всего.

1. Аудит кода и схемы хранения. Разбираем структуру состояния: какие поля остаются неизменными, что потребует миграции, сколько занимает хранение на аккаунте контракта. Фиксируем места, где обновление затронет уже записанные данные.
2. Схема аккаунтов и ролей. В Near аккаунт — это и есть контракт, поэтому права разделяем: субаккаунты под контракты, отдельный ключ на развёртывание, функциональные ключи только на вызов конкретных методов. Смена кода и списание баланса в одном ключе не совмещаются.
3. Воспроизводимая сборка. Задаём параметры компилятора и порядок формирования артефакта, чтобы у любого инженера получался идентичный результат, а хеш сборки совпадал с тем, что уходит в сеть.
4. Тестовые среды. Локальный узел для быстрых прогонов и отдельная тестовая сеть для интеграции, где проверяем миграции состояния, работу ключей и сценарии с реальной задержкой финализации.
5. Проверка перед выпуском. Прогоняем тесты по критичным путям контракта, проверяем граничные значения депозитов и репетируем откат на предыдущий артефакт.
6. Поэтапное развёртывание. Сначала ограниченный список аккаунтов, затем все — с наблюдением за расходом хранения и отказами вызовов.
7. Передача и обучение. Отдаём документацию, схему аккаунтов и ролей, доступы и инструкцию по выпуску обновлений, чтобы команда дальше работала без нас.

Аккаунты и хранилище в Near: политики доступа

На Near доступ определяется не только кодом контракта, но и иерархией аккаунтов: у каждого свой ключ, свой набор разрешённых вызовов и свой объём данных в постоянном хранилище. Поэтому в поставку входит не только контракт, но и документы, по которым доступ и хранение можно воспроизвести и передать другой команде — без восстановления логики по переписке.

• Карта аккаунтов и ролей: владелец, аккаунт для выката новых версий, служебные аккаунты для автоматических вызовов и роли только для чтения — права не смешиваются в одном ключе.
• Политики доступа: какие методы доступны каждой роли, что требует подтверждения вторым ключом, что ограничено списком адресов или временным окном.
• Схема хранения состояния: какие данные лежат в постоянном хранилище, что считается на лету, как устроены ключи записей и как меняется баланс хранения при росте объёма.
• Регламент обновления: порядок выката новой версии — подготовка переноса состояния, прогон на копии сети, переключение — с точками, где процесс можно остановить безопасно.
• Регламент отката: как вернуть предыдущую версию вместе с совместимым состоянием, кто принимает решение и за какое время операция выполняется.
• Разграничение сред: отдельные наборы ключей для тестовой и основной сети, запрет на перенос ключей и данных между ними.
• Журнал операций: какие действия фиксируются, где хранятся записи и как по ним разобрать инцидент, не пересобирая контракт.

Документация нужна не для отчётности: через полгода новый инженер входит в проект по ней. Всё перечисленное ведём в репозитории рядом с кодом — контракт на Rust и описания доступа меняются в одном наборе изменений.

Кейс: перенос логики на новый аккаунт с сохранением данных

Что было

На одном аккаунте жили и логика, и состояние, а выпуск версии состоял из ручных шагов: собрать контракт, выложить код, догнать состояние и сверить его глазами. Сборка не повторялась — два прогона из одних исходников давали разные артефакты, а расхождение всплывало уже на живом аккаунте. Отката не было: при ошибке аккаунт поднимали из копии, и недоступность растягивалась на часы.

Что стало

Перенос логики на новый аккаунт в Near разложили на воспроизводимую сборку и отдельный шаг миграции состояния. Скрипт считает ключи и контрольные суммы на старом аккаунте, затем на новом и останавливается при расхождении — битое состояние не уходит в работу. Старый аккаунт остаётся точкой отката: пока проверки не пройдены, переключение отменяется одной операцией.

Ручных шагов стало 3 вместо 12, перенос занимает около получаса вместо четырёх часов. Все переносы проходят без расхождений состояния, тогда как раньше сбоила примерно каждая вторая попытка. Возврат на прежний аккаунт — минуты, а не часы восстановления из копии, и выполняется той же командой, что и перенос.

Что делать, если логика уже развёрнута и хранит данные?

Обновление контракта на Near устроено так: код перезаписывается целиком, а хранилище состояния остаётся нетронутым. Поэтому повторный деплой на тот же аккаунт сам по себе данные не сбрасывает — риск в другом: новый код начинает читать старые ключи по изменившейся схеме и падает на первом же вызове или, что хуже, молча отдаёт неверные значения.

Совместимость схемы держат дисциплиной: поля добавляют в конец структуры, порядок и типы существующих не трогают без необходимости, а несовместимые правки выносят в отдельный метод миграции. Он повторно инициализирует контракт с явным игнорированием прежнего состояния, читает старые ключи, раскладывает их в новом формате и записывает обратно одним вызовом — чтобы состояние не осталось в промежуточном виде при обрыве.

Переход на новый аккаунт нужен, когда меняется владелец или сам адрес. Автоматического переезда здесь нет: состояние переносят чтением ключей и записью на новый аккаунт, либо оставляют старый тонкой прослойкой, которая делегирует вызовы вперёд. Второй путь предпочтительнее, если на адрес уже ссылаются кошельки, фронтенд и другие контракты — их вызовы продолжают работать без правок.

Чтобы приложение осталось рабочим, сохраняют прежние имена и сигнатуры методов, а миграцию выносят в отдельный вызов, который выполняется до переключения. Репетиция идёт на копии состояния, до и после сверяются контрольные значения — балансы, число записей, доступность публичных методов. Предыдущий код держат под рукой для откатного деплоя, если проверки на живых данных не сойдутся.

Технические сомнения перед стартом работ

Перед стартом почти каждая команда задаёт одни и те же вопросы: где будут лежать ключи, что произойдёт с аккаунтом при обновлении кода, как перенести доступ со стенда на продуктив и можно ли доверять чужому контракту. Ниже — короткие ответы по каждому.

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

Что будет с аккаунтом и данными при обновлении контракта?

Код обновляется на месте, аккаунт и его хранилище сохраняются, поэтому обращения по прежнему адресу продолжают работать. Разрыв возникает, если поменялась структура данных или сигнатуры методов. Мы заранее описываем миграцию состояния, добавляем функции переноса и прогоняем обновление на изолированном стенде, прежде чем касаться продуктивного аккаунта.

Как переносится доступ между стендом и продуктивом?

Переносить состояние напрямую нельзя — среды независимы. Переносится конфигурация: список аккаунтов, набор ключей, схема прав и данные инициализации, а состояние разворачивается заново теми же миграциями. Так продуктив повторяет проверенный сценарий стенда, а не копирует его вслепую.

Можно ли доверять уже написанному контракту — своему или чужому?

Перед доработкой чужого кода мы сверяем опубликованный байткод с исходниками и составом зависимостей: если они расходятся, менять логику опасно. Дальше — проверка прав ключей, точек обновления и логики вывода средств. Найденные расхождения фиксируем как условие, которое нужно снять до начала работ.

Обсудим задачу: вернёмся с оценкой и планом

Чтобы вернуться с оценкой и планом работ, а не с общими формулировками, нам хватает минимального набора вводных. Чем конкретнее вход, тем точнее сроки и меньше уточняющих кругов до начала работ.

Что прислать для старта:

• Ссылку на репозиторий или архив с исходниками контракта на Rust, включая манифест сборки и зафиксированную версию компилятора.
• Список и назначение аккаунтов: какой контракт куда разворачивается, кто владелец, какие ключи доступа выданы и на какие методы.
• Описание storage: какие структуры пишутся в состояние, ожидаемый объём, есть ли миграции и как планируется перенос данных.
• Целевую сеть и режим работы: тестовая или основная, требуемая пропускная способность, лимиты на запись.
• Текущую схему выкладки: скрипты сборки, ручные шаги, что уже автоматизировано, а что делается руками.
• Требования к проверкам: какие сценарии обязаны проходить до релиза и кто подтверждает готовность.

Мы разберём контракт, модель состояния и права на ключи отдельно — при развёртывании это три независимых источника отказов. Посмотрим, где зашиты допущения о размере состояния, как ведёт себя логика при частично применённых изменениях и что происходит с аккаунтом при неудачной выкладке.

Вернёмся с оценкой и планом работ: этапы, порядок выкладки, точки возврата к предыдущему состоянию, состав проверок и то, что потребуется от вашей стороны на каждом шаге. Опишите задачу — пришлём разбор с конкретными сроками.