Деплой смарт-контрактів у Base: налаштування, деплой і верифікація

Розгортання смарт-контрактів у Base: де ламається процес

Публікація контракту в Base найчастіше виглядає як набір ручних кроків: розробник компілює проєкт локально, підставляє приватний ключ зі змінної середовища і запускає скрипт розгортання через публічний вузол мережі. Поки це робить одна людина на одній машині, все сходиться.

Щойно з’являється друге середовище — тестова гілка, друга команда, автоматична збірка — версія компілятора та параметри оптимізації розходяться, і той самий вихідний код дає різний байткод.

Далі починаються помилки публікації контракту, які видно не відразу. При паралельному запуску скриптів ламається черга транзакцій: частина йде у відбракування, а витрата комісії мережі списується за невдалу спробу.

Недоступність вузла в момент відправлення призводить до того, що скрипт падає вже після компіляції — незрозуміло, пішла транзакція чи ні, — і повторне розгортання створює другий екземпляр контракту за новою адресою зі своїм станом.

Окремий біль — верифікація.

Непідтверджена збірка означає, що в оглядачі мережі за адресою видно лише байткод без вихідного коду: користувач не може перевірити логіку, аудит не підтверджується, а команда втрачає зв’язок між тим, що лежить у репозиторії, і тим, що реально працює в мережі.

У сумі це не одноразова затримка, а некерований процес: адреси контрактів ніде не зафіксовані, зміни не відстежуються, відкат версії неможливий — незрозуміло, що відкочувати. Розбираємо, як це закривається: від відтворюваної збірки до передбачуваного повторного розгортання.

Що дає передбачуваний реліз: вимірювані ефекти

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

Час публікації та відкат версії

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

Повторний реліз у Base займає хвилини замість годин ручних проходів, а повернення до попередньої версії — це підміна адреси в конфігурації, а не переписування коду.

Один опис для всіх мереж

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

Клас відмов «на тесті пройшло, у мережі зламалося» перестає відтворюватися: перевірний контур повторює робочу топологію, включно з порядком ініціалізації, ролями та початковими значеннями.

Частка успішних випусків

Кожен реліз проходить однакові перевірки до відправлення транзакції. Помилки ловляться на звірці артефактів і прав доступу, тому частка випусків без відкату зростає, а пошук причини інциденту перестає бути ручним розбором журналів.

Керована витрата комісії мережі

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

Формати розгортання смарт-контрактів: що вибрати

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

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

Межі між підходами проходять по тому, де зберігається доказ перевірки. Якщо звіт про прогін у проміжному середовищі прив’язаний до того самого артефакту, що йде в мережу, — випуск відтворюваний, і розбір розбіжностей займає хвилини, а не добу.

Етапи робіт: від аудиту коду до передачі управління

Розгортання в Base — це не одна транзакція, а останній крок ланцюжка, на якому помилка коштує найдорожче.

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

1. Аудит контракту та карта залежностей. Розбираємо логіку, зовнішні виклики та бібліотеки, позначаємо місця, де поведінка залежить від чужих контрактів. Фіксуємо, що саме змінюється при кожному оновленні та які ролі до цього допущені.

2. Схема середовищ. Локальний запуск, тестова та основна мережа описуються одним конфігом із різними параметрами та різними ключами. Адреси й власники середовищ не перетинаються, щоб тестова перевірка не могла вплинути на робочі кошти.

3. Повторювана збірка. Версії компілятора та залежності закріплені, артефакти збираються однаково на будь-якій машині. Хеш байт-коду збігається в нас і в замовника — розбіжність видно до відправлення транзакції, а не після.

4. Налаштування доступів. Ролі адміністратора, призупинення й оновлення розводяться за окремими ключами; критичні операції закриваються мультипідписом, налаштовується ротація та зберігання в апаратному гаманці.

5. Перевірка в тестовій мережі. Прогоняємо повний сценарій, включно з граничними випадками та відмовними гілками, дивимося витрату газу, ліміти та поведінку під час відкату. Помилки виправляються тут, коли ціна виправлення мінімальна.

6. Публікація в основній мережі. Розгортання йде за чек-листом із підтвердженням параметрів і адрес на кожному кроці, потім вихідний код верифікується в публічному оглядачі — контракт читається та перевіряється незалежно від нас.

7. Передача управління. Віддаємо ключі та ролі, інструкції з оновлення й призупинення, схему середовищ і контакт відповідального. Замовник отримує звіт з адресами та хешами і може перевірити кожен пункт сам.

Що залишається у вас: конфігурації, схеми та регламенти

Передаємо не набір розрізнених файлів, а робочий контур, у якому наступна публікація контракту робиться без нас.

Усі артефакти лежать у вашому репозиторії, прив’язані до проєкту та описані так, щоб інженер, який не брав участі в розробці, відтворив цикл публікації та відкату за інструкцією.

• Конфігурації середовищ. Окремі профілі для локальної мережі, тестової мережі та Base-мейннету: адреси RPC-вузлів, ідентифікатори мереж, параметри газу, перевизначення для повторних прогонів. Перемикання між середовищами — однією змінною, без правки коду.
• Схема зберігання ключів. Де лежать ключі деплоєра, хто і через який підписувальний контур ними оперує, як влаштований multisig із порогом підтверджень і timelock на адміністративні виклики. Окремо — порядок ротації та що робити при компрометації.
• Політики доступу та ролі. Матриця «роль → які функції контракту доступні»: власник, оператор, паузер, казначейство. Із зазначенням, які ролі можна передати, а які зафіксовані незмінними при ініціалізації.
• Опис процесу публікації. Покроковий прогін: збірка артефактів, сухий запуск на форку мейннету, перевірка підсумкових адрес і параметрів конструктора, сама публікація, підтвердження верифікації вихідних кодів в оглядачі.
• Інструкція з відкату. Що переводиться в паузу, які виклики скасовують стан, як повернути трафік на попередню адресу і в якому порядку знімати права. Із зазначенням, які операції незворотні, — щоб рішення ухвалювалося усвідомлено.
• Регламент релізу. Хто ініціює, хто підтверджує, які перевірки обов’язкові перед публікацією, як фіксується факт виходу версії та де зберігається журнал змін контракту.
• План відновлення. Дії при недоступності вузла, при розбіжності стану та при інциденті на пов’язаних контрактах: точки входу, відповідальні, послідовність кроків.

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

Кейс: переведення проєктів на керований реліз

До нас прийшла команда платформи, яка публікувала контракти на Base вручну: збірка збиралася на машині інженера, ключі передавалися в листуванні, адреси нових модулів вписувалися в конфігурацію руками. Один реліз займав вечір і залежав від того, хто саме його виконував.

Дорожче обходилися не години, а розбіжності: частина контрактів ішла в основну мережу без прогону в тестовій, у бібліотек змінювалися адреси, і код переставав збігатися з уже опублікованим. Такі публікації відхилялися на верифікації, і реліз повторювали заново.

Наші інженери перенесли випуск у відтворюваний сценарій: фіксовані параметри збірки, обов’язковий прогін у тестовій мережі, перевірка зв’язків між модулями, автоматична верифікація та журнал операцій з адресами.

Метрики до та після

Ручним залишилося лише підтвердження релізу. Відмови сумісності перестали бути регулярними, витрата комісії мережі на випуск знизилася, а відкат на попередню версію зберігся.

Оновлення проти розгорнутого рішення: як не втратити дані?

Оновлення вже розгорнутого контракту — це не перезбірка з нуля, а вибір між двома сценаріями, і наслідки помилки в них різні. Перший — проксі-схема: сховище залишається на незмінній адресі, а логіка підмінюється новим контрактом реалізації.

Стан при цьому зберігається, але розкладка змінних має збігатися слот у слот — зсув хоча б однієї змінної перетворює баланси та ролі на нечитабельне сміття.

Другий — новий контракт і міграція даних: читаємо стан старої адреси пакетами, переносимо в новий, перемикаємо покажчики, старий залишаємо в режимі лише читання. Це довше й потребує короткої паузи в записі, зате знімає обмеження за структурою даних.

Коли в Base контракт уже тримає кошти користувачів, між варіантами обов’язкова перевірка сумісності версій — вона й визначає вибір.

Перевіряємо заздалегідь: розкладку сховища, ініціалізатори, повторний виклик яких ламає права, адреси адміністраторів і ролі, події, на які зав’язані зовнішні сервіси, і сценарій відкату.

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

Сумісність даних важливіша за швидкість публікації: неправильне оновлення не відкочується назад однією транзакцією, а відновлення стану перетворюється на окрему міграцію під навантаженням. Тому спочатку фіксуємо поведінку старої версії як еталон, потім випускаємо нову.

Технічні сумніви: вузли, ключі та доступи

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

Що буде, якщо втрачено ключ підпису?

Ключ власника визначає, хто змінює параметри та виводить кошти. Якщо його втрачено і резервної ролі немає, контракт залишається без управління — доступ не відновити.

Тому ми розділяємо ролі, критичні операції виводимо на мультипідпис, а резервний ключ зберігаємо окремо із затримкою на застосування.

Як переконатися, що опублікований код збігається з вихідними кодами?

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

Хто відповідає за витрату мережевої комісії при невдалій транзакції?

Комісію списує мережа, і неуспішний виклик її теж витрачає. Тому до публікації прогоняємо сценарії на локальній копії мережі, перевіряємо виклики в режимі симуляції та обмежуємо ліміт обчислень, щоб помилка не з’їдала резерв.

Обговоримо задачу: які дані надіслати для оцінки

Щоб повернутися з планом робіт та оцінкою, а не з уточнювальними питаннями, потрібен зріз поточного стану публікації контрактів і вимог до неї. Нижче — мінімальний набір вступних; якщо чогось немає, напишіть прямо про це, підкажемо, чим закрити прогалину.

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

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