Деплой смарт-контрактів Fantom: де ламається і чому
Публікація контракту в мережі Fantom виглядає як одна команда, але саме тут вилазять помилки, невидимі в тестовому середовищі. Нижче — де найчастіше ламається деплой смарт-контрактів Fantom і чому команди дізнаються про проблему вже після того, як код пішов у основну мережу.
Перша причина — невідповідність версії компілятора та налаштувань оптимізації між локальною збіркою та публікацією. Байткод виходить іншим, розгорнутий код не збігається з вихідним кодом, який подається на перевірку, і верифікація перестає проходити.
Друга часта помилка публікації контракту — необроблений виняток у конструкторі або в підключеній бібліотеці: транзакція відкочується повністю, а списаний ресурс не повертається.
Окрема група — операції запису. Якщо ліміт ресурсу виставлений на око, виклик зі зміною стану падає з повідомленням, що не вистачає ресурсу на операцію, хоча читання того ж контракту проходить.
Читання не змінює стан і коштує кратко дешевше, а запис у сховище — найдорожча частина виклику, і запас під неї рахують окремо.
Сюди ж додається різниця між Opera і Sonic: правила оплати зберігання даних у цих мережах відрізняються, і параметр, підібраний під одну, тихо не проходить в іншій.
Найдорожчий сценарій — контракт розгорнувся не туди. Адреса визначається адресою відправника та порядковим номером його транзакції, тому повторна публікація з того ж ключа дає нову адресу, а клієнтська частина, скрипти та проксі продовжують дивитися на стару.
Зовнішні інтеграції працюють із застарілим кодом, і розбіжність випливає вже за даними, а не на етапі викладки.
Усі чотири точки закриваються процесом, а не уважністю одного інженера: відтворюваною збіркою, розрахунком ресурсу під запис і явною передачею адреси в конфігурацію. Про це і поговоримо далі.
Що змінюється після керованого розгортання
Кероване розгортання контрактів переводить випуск змін з ручної операції у відтворюваний процес: збірка йде із зафіксованого стану репозиторію, перевірки проганяються на локальній копії мережі, і тільки потім код іде в основну.
Час виведення зміни вимірюється десятками хвилин замість днів очікування вікна, причому однаково для мереж гілки Opera і Sonic Fantom — різниця залишається тільки в параметрах публікації.
Першим іде клас відмов, пов'язаний з людиною за терміналом: переплутана мережа, не та адреса бібліотеки, пропущена ініціалізація, повторна публікація поверх робочої версії. Такі помилки не ловляться рев'ю, тому що проявляються в момент підпису.
Коли публікацію виконує один і той самий перевірений сценарій з фіксованими аргументами і кворумом ключів замість єдиного підпису, ймовірність помилки падає до нуля, а не «знижується».
Логіка і сховище розділені: оновлення змінює реалізацію за проксі, стан залишається на місці. Тому перенесення контракту в нову версію не вимагає зупинки сервісу і перезаливки даних — гаманці та інтеграції продовжують працювати за тими ж адресами.
Відкат теж не аварія, а перемикання вказівника на попередню реалізацію, якщо перевірки після публікації показали відхилення.
Стабільність роботи контракту тримається на спостережуваності: частка успішних викликів, витрата газу на операцію та події контракту йдуть у моніторинг з алертами щодо відхилення від норми. Це дає не «спокій», а конкретне: інцидент видно до звернень користувачів, а не після.
Режими публікації: Opera, Sonic і тестові мережі Fantom
Один і той самий байткод у різних мережах сімейства поводиться по-різному: змінюються ідентифікатор мережі, монета для оплати газу, набір публічних вузлів і адреса оглядача блоків.
Контракт із зашитим ідентифікатором або адресою зовнішнього сервісу формально розгорнеться, але не заробить. Тому режим публікації ми визначаємо до збірки, а не після.
Чотири варіанти, між якими реально обирають на проектах:
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Opera, основна мережа | Промисловий запуск: токен, розрахунки, публічна логіка | Відкат тільки механізмами контракту, правки — новою версією |
| Sonic, друга мережа сімейства | Новий контур на спільному стеку і знайомих інструментах | Свої адреси, стан і активи — потрібен перенос |
| Тестова мережа Fantom | Перевірка сценаріїв, ролей і оплати газу до запуску | Інші дані та зовнішні сервіси, поведінка розходиться |
| Локальний стенд на копії стану | Швидкі ітерації, регрес, перевірка оновлення | Не відтворює конкуренцію за блоки та затримки |
Маршрут зазвичай такий: локальний стенд, тестова мережа, потім Opera або Sonic — збірка і набір перевірок на всіх кроках одні й ті самі. Ідентифікатори мереж, адреси вузлів і ключі виносимо в конфігурацію, тому перемикання не вимагає правок у коді.
Порівняння мереж розгортання виходить предметним: що перевірено, який клас помилок закрито і що залишилося на основний запуск.
Як проходить перенесення контрактів: етапи інженерної роботи
Перенесення контрактів у Fantom — це не перепублікація коду, а перенесення прав, ролей і зв'язків між контрактами. Помилка в порядку розміщення або в початкових параметрах обертається повторною публікацією і втратою стану, тому кожен етап закінчується перевірюваним артефактом.
- Аудит контрактів. Розбираємо вихідні коди та вже розгорнуті адреси: зовнішні виклики, залежності від оракулів і сторонніх контрактів, ролі власника, механізми оновлення. Фіксуємо, що переноситься разом із кодом, а що потребує повторної ініціалізації.
- Схема публікації контрактів. Будуємо граф залежностей: бібліотеки та допоміжні модулі розміщуються раніше основних, тому що їхні адреси прописуються в конструкторах. Схема задає черговість транзакцій, початкові параметри та власників.
- Збірка артефактів. Компілюємо під цільову мережу, домагаємося відтворюваної збірки, зберігаємо вихідні коди та метадані — без цього верифікація коду в оглядачі мережі не пройде.
- Перевірка на тестовому контурі. Проганяємо сценарії життєвого циклу: випуск, перекази, зміна прав, пауза, аварійне завершення. Порівнюємо поведінку з поточним розгортанням і закриваємо розбіжності до виходу в основну мережу.
- Публікація в основній мережі. Виконуємо за схемою, контролюючи споживання газу та результат кожної транзакції; після розгортання звіряємо адреси, права та початковий стан.
- Передача контуру в експлуатацію. Віддаємо адреси, інтерфейси, матрицю ролей, регламент оновлення та відкату, налаштування моніторингу подій — команда замовника веде систему далі без нашої участі.
Що замовник отримує на руки після публікації
Публікація контракту в мережі — не фінальна точка, а момент передачі системи в експлуатацію. Замовник отримує не тільки адресу в оглядачі, а й набір артефактів, за якими його команда зможе розвивати та обслуговувати контракти без автора.
- Конфігурації контрактів — файли з параметрами для мереж Opera і Sonic: адреси залежностей, ліміти газу, значення, які відрізняються між середовищами.
- Схема взаємодії контрактів — граф викликів між основним контрактом, бібліотеками та зовнішніми сервісами, з позначеними точками заміни компонентів.
- Політики доступу до ключів — розділення деплой-ключа, адміністративного та операційного, підпис через мультисиг, порядок ротації та зберігання резервних копій.
- Регламент оновлення контракту — схема оновлюваності, порядок погодження змін, вікно паузи для користувачів і умови випуску нової версії.
- Регламент відкату — як повернутися до попередньої реалізації, які дані мігруються і хто приймає рішення про відкат.
- Документація по контрактах — опис публічних методів, подій та інваріантів, на які спирається інтеграція.
- Матриця ролей — хто зі співробітників і до якого рівня управління має доступ після передачі.
Все складається в репозиторій замовника з інструкцією щодо відтворення: розгорнути копію контуру, виконати контрольні виклики, звірити стан з очікуваним. Підтримка не залежить від того, чи залишається автор контрактів у команді.
Кейс: перенесення контрактів без простою та втрати стану
Замовник — протокол ліквідних пулів на Fantom. Контракти розгорталися вручну: кожна правка логіки означала нову адресу, ручне перенесення балансів і звірку стану за журналами.
До третьої ітерації публікація займала до шести хвилин, при піковому навантаженні 3-4% звернень завершувалися відмовою, а розбіжність балансів між версіями шукали за логами вручну.
Що зробили
Логіку винесли за проксі-шар: адреса для користувачів та інтеграцій залишається незмінною, змінюється тільки реалізація. Перед перемиканням зібрали зліпок стану і прогнали міграцію на локальній копії мережі — з тими ж даними і тим же порядком викликів.
Саме перемикання зайняло один блок: частина викликів залишилася на попередній логіці, нові пішли на оновлену, а відкат виконується поверненням вказівника на попередню реалізацію.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Час публікації | 4-6 хвилин | 20-40 секунд |
| Звернення з відмовою | 3-4% | менше 0,5% |
| Перенесення стану | вручну, за журналами | зліпок і звірка хешів |
| Відкат на попередню версію | перевипуск контракту | повернення вказівника |
Збереження стану підтвердили звіркою хешів до і після — розбіжностей немає, звернення користувачів не переривалися. Оновлення далі виходять за відпрацьованим сценарієм: зліпок, репетиція на копії мережі, перемикання в одному блоці.
Чим відрізняється розгортання в Opera від Sonic?
Обидві мережі одного сімейства — EVM-сумісні, і один і той самий байткод контракту розгортається в Fantom Opera і в Sonic без переписування логіки.
Різниця починається нижче рівня коду: у моделі розрахунку за операції, в лімітах блоку і в тому, як мережа враховує займаний контрактом стан. Від цього залежить і профіль навантаження після запуску, і те, як доведеться організувати зберігання даних.
В Opera плата за операції рахується за звичною схемою: газ за обчислення плюс газ за запис у стан, а ліміт блоку обмежує обсяг транзакцій. В Sonic перероблено облік зберігання — займане місце оплачується окремо від обчислень, а пропускна здатність вища.
Для контрактів з великими таблицями записів це змінює розклад: стратегію зберігання варто обирати до деплою, а не після першого напливу користувачів.
Перенести працюючий контракт однією транзакцією не можна: адреси і стан у мережах незалежні, а різний ідентифікатор мережі виключає повтор підпису.
На практиці розгортають той самий байткод заново і окремо переносять дані — снапшотом стану або через міст, якщо важлива безперервність балансів користувачів. Тому мережу обирають до першого деплою: зміна майданчика пізніше означає міграцію з усіма її перевірками.
Технічні сумніви перед стартом робіт
Перед стартом робіт технічні команди задають одні й ті самі питання: що робити з уже розгорнутим контрактом, як перевіряти чужий код і кому дістаються ключі. Нижче — прямі відповіді для мереж Fantom, без загальних слів.
Як перевірити контракт, якщо вихідний код недоступний?
Звіряємо байткод з опублікованим вихідним кодом, якщо він викладений; за його відсутності відновлюємо логіку за декомпільованим кодом і перевіряємо поведінку викликами на локальній копії мережі.
Окремо фіксуємо список адрес і прав, які контракт може змінювати, — це показує реальну поверхню ризику.
Чи можна оновити контракт після публікації?
Так, якщо схема закладена заздалегідь: логіка виноситься в окремий контракт за постійною адресою-посередником, а стан і баланси залишаються на місці. Якщо контракт незмінний — оновлення неможливе, і ми плануємо міграцію з перенесенням даних на нову адресу.
Де зберігаються ключі розгортання?
Ключ залишається у замовника на апаратному носії, ми отримуємо тільки адресу та підписані транзакції. Для критичних операцій налаштовуємо схему з кількома підписами, а роль адміністратора відокремлюємо від облікового запису, який виконав публікацію.
Що робити з уже розгорнутим контрактом?
Переписувати його не потрібно: підключаємося до існуючої адреси, розбираємо інтерфейс і стан. Далі — або надбудова сумісного контракту, або міграція з перенесенням балансів і прав, з перевіркою на копії мережі до основної транзакції.
Обговоримо задачу: що потрібно для старту
Старт робіт по контрактах починається не з коду, а з розбору задачі та вихідних даних. Чим конкретніша ввідна, тим менше допущень в оцінці і тим точніший план розгортання — під обрану мережу Fantom, тестовий контур і майбутні оновлення логіки.
Щоб повернутися з оцінкою та планом, а не із загальними формулюваннями, достатньо такого мінімуму:
- Логіка і межі контракту: що він зберігає і які дії дозволяє — деплой, виплати, доступ за ролями, зупинка та оновлення коду.
- Ролі та права: хто власник, кому потрібні адміністративні повноваження, хто підписує транзакції і як діємо при втраті ключа.
- Передача доступів до мережі: вузли та сервіси відправки транзакцій, тестові акаунти, права на публікацію та верифікацію коду.
- Існуючі адреси: вже працюючі контракти, якщо інтеграція йде в живу систему, і зовнішні сервіси для обміну даними.
- Зберігання ключів: як зараз підписуються операції, де лежать секрети, хто до них допущений і за яким регламентом.
- Вимоги до перевірок: які сценарії обов'язково покрити тестами і який набір перевірок потрібен до виведення в основну мережу.
- Супровід після запуску: чи потрібні оновлення логіки, моніторинг транзакцій і розбір інцидентів.
Доступи приймаємо за захищеним каналом, секрети не пересилаємо в листуванні — порядок передачі узгоджуємо заздалегідь. Далі повертаємося з оцінкою, планом робіт з розгортання за етапами та переліком ризиків з точками, де потрібне ваше рішення.
Опишіть задачу — запропонуємо терміни та формат старту.
