Создание и развертывание смарт-контрактов в Sui: полный гайд

Почему развертывание смарт-контрактов Sui срывается на публикации

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

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

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

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

Что меняется, когда релиз контрактов перестаёт быть ручным

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

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

Чек-лист, по которому собираем контур:

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

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

Способы публикации и обновления пакетов: сравнение

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

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

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

Порядок работ: от аудита кода до передачи контура

Развертывание смарт-контрактов в Sui — это не одна команда публикации, а цепочка этапов, где каждый закрывается артефактом, который можно проверить до перехода дальше. Если пропустить проектирование, ошибка в правах владения объектом всплывает уже в основной сети, когда исправление требует миграции состояния и повторной проверки всех зависимостей.

Этапы работ

1. Разбор логики и аудит контрактов. Читаем требования вместе с вашей командой, фиксируем роли, права и сценарии отката. На выходе — перечень инвариантов, которые код обязан удерживать при любом порядке вызовов, и классы уязвимостей, закрываемые на этапе проектирования.
2. Проектирование схемы модулей. Раскладываем логику так, чтобы границы модулей совпадали с зонами ответственности: отдельно хранение состояния, отдельно правила доступа, отдельно вычисления. Схема согласуется до написания кода — правка на этом этапе дешевле переписывания готовых модулей.
3. Настройка окружений. Поднимаем локальный узел, тестовую сеть и кошельки с раздельными ключами для сборки и для управления. Конфигурации версионируются, чтобы окружение воспроизводилось с нуля на любой машине.
4. Реализация и локальные проверки. Прогоняем модульные тесты на каждый публичный метод, включая негативные сценарии: чужой владелец, повторный вызов, превышение лимита.
5. Проверка на тестовой сети. Публикуем пакет, измеряем расход ресурсов на операцию, прогоняем сценарии под нагрузкой и проверяем поведение при параллельных вызовах одного объекта. Результат — отчёт с транзакциями и найденными границами.
6. Передача контура. Отдаём исходники, схему модулей, скрипты публикации и обновления, регламент действий при инциденте и порядок отката на предыдущую версию.

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

Комплект поставки: конфигурации, схемы, регламенты

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

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

Каждый артефакт мы проходим вместе с вашей командой до передачи — вопросы по составу лучше снять на этом этапе. Опишите задачу, и мы вернёмся с оценкой и планом: развёртывание смарт-контрактов Sui перестанет зависеть от одного подрядчика.

Кейс: как сократили цикл выпуска контрактов в четыре раза

Как было: выпуск зависел от одного человека

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

Что изменили

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

Что стало

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

Что делать, если контракт уже развёрнут в Sui и требует правок?

Опубликованный код в Sui неизменяем: контракт разворачивается как объект-пакет, а не как файл на сервере, поэтому «поправить пару строк и перезалить» здесь не работает. Любая правка логики проходит процедуру обновления пакета, и то, что в ней разрешено, определяется политикой обновления, зафиксированной в момент первой публикации.

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

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

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

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

Частые технические сомнения перед стартом

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

Как проверяется безопасность логики контракта?

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

Что будет, если в новой версии найдётся ошибка?

Политику обновления выбираем до релиза. У обновляемого контракта версии публикуются по одной, и откат версии — это возврат предыдущего пакета без потери накопленных данных. Если контракт неизменяемый, бизнес-логику выносим в отдельный слой, который можно заменить.

Насколько подробной должна быть документация по контракту?

Документация по контракту описывает модули и их связи, роли и матрицу прав, точки входа, процедуру выпуска новой версии и порядок действий при инциденте. Этого достаточно, чтобы ваша команда сопровождала контракт без нас, а сторонний аудитор разобрался за один проход.

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

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

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

В состав первого этапа сотрудничества входит:

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

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