Міграція DEX на StarkNet: від розробки Cairo-контрактів до верифікації

Деплой смарт-контрактів StarkNet: де ламаються DEX

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

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

Друга точка відмови — логіка AMM під час міграції DEX. Перенесення математики з EVM-моделі в Cairo ламає розрахунки там, де раніше все сходилося: округлення при діленні, порядок операцій із фіксованою точкою, робота з felt-типами замість звичних цілих.

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

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

У підсумку команда втрачає час на ручний перезапуск, а частина класів залишається в невизначеному стані.

Розбираємо, як це закривається: від структури Cairo-контрактів і коректної верифікації до відмовостійкого деплою та міграції DEX без простою.

Що дає перенесення DEX на StarkNet: швидкість і вартість

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

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

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

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

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

Що змінюється в цифрах

• Пропускна здатність. Біржа обробляє кратно більше операцій за одиницю часу: вузьке місце зміщується з першого рівня на власні сервіси матчингу.
• Вартість газу. Комісія за своп і скасування ордера падає до рівня, за якого дрібні угоди перестають бути збитковими.
• Фінальність. Підтвердження надходить за секунди, а не за хвилини — арбітражники та боти бачать результат раніше і не будують стратегію навколо невизначеності.
• Клас відмов. «Зависла транзакція» зникає: якщо операція не пройшла, стан відкочується повністю, а не залишає користувача із замороженими коштами.

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

Варіанти міграції: повне перенесення, гібрид, проксі

Перенесення DEX на StarkNet — це не «переписати контракти й задеплоїти».

Cairo відрізняється від Solidity моделлю обчислень і зберігання стану, тому той самий пул ліквідності не можна просто скопіювати: логіка AMM, оракули й розрахунок комісій переписуються під нове середовище виконання.

Від вибору схеми залежить, як довго біржа житиме в двох мережах одночасно і як поводитиметься ліквідність у перехідний період.

Повне перенесення DEX — найчистіший шлях: контракти пишуться з нуля під Cairo, без легасі-компромісів, а архітектура одразу заточується під дешеві обчислення. Ціна — втрата накопиченого стану й повторний запуск пулів.

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

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

Етапи робіт: від аудиту поточного DEX до верифікації

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

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

1. Аудит DEX. Розбираємо поточну архітектуру: як влаштовані пули, де зберігається стан, які зовнішні виклики критичні. Фіксуємо інваріанти — що зобов'язане зберегтися після міграції, — і вузькі місця, які дорожче переносити, ніж переписати.
2. Проєктування схеми. Визначаємо розкладку сховища, розбиття на модулі та точки довіри між ними. На цьому кроці стає ясно, які частини логіки йдуть в окремі контракти, а які залишаються в одному.
3. Написання Cairo-контрактів. Реалізуємо логіку на Cairo з урахуванням моделі обчислень і вартості зберігання. Окремо опрацьовуємо обробку помилок і доступи — у StarkNet ціна невірного виклику вища, ніж у звичних мережах.
4. Налаштування середовища та тестова мережа. Піднімаємо локальний стенд, проганяємо сценарії свопів, додавання та виведення ліквідності. Тестова мережа дає перевірку на реальній поведінці до публікації в основній мережі.
5. Верифікація контрактів. Публікуємо вихідні коди, звіряємо байт-код із зібраним артефактом, перевіряємо відтворюваність збірки. Без цього контракт формально працює, але недоказовий для користувачів і аудиторів.
6. Передача. Віддаємо конфігурації, схеми розгортання, політику оновлень та інструкції з відкату.

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

Артефакти: конфігурації, схеми, політики доступу, регламенти

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

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

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

Кейс: міграція DEX із втратою 0,3% ліквідності

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

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

Що зробили

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

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

Результат

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

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

Чим відрізняється деплой смарт-контрактів StarkNet від EVM?

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

StarkNet виконує програму off-chain, а на L1 надсилає доказ коректності: перевірка коштує приблизно однаково незалежно від того, скільки обчислень усередині.

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

Звідси друга відмінність — вартість газу рахується інакше. У EVM ви платите за кроки віртуальної машини; у StarkNet — за так званий крок, за обсяг записуваних даних і за оновлення сховища.

Контракт, який у EVM дешевий за обчисленнями, але активно пише в storage, у StarkNet може виявитися дорожчим, ніж очікувалося.

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

Третя — інструменти розробки. Мова контрактів тут не Solidity, а Cairo: статична типізація, явне керування пам'яттю, інша система типів і інший підхід до зберігання.

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

Четверта — верифікація. У EVM контракт компілюється в байткод, який можна звірити з вихідником. У StarkNet компілятор Cairo видає проміжне представлення, і перевірка відповідності опублікованого коду вихідному потребує окремого процесу.

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

Часті технічні сумніви при перенесенні DEX

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

Які ризики несуть проксі-контракти при оновленнях?

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

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

Як забезпечується безпека ключів і аудит контрактів?

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

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

Обговоримо ваше завдання з міграції DEX на StarkNet

Щоб повернутися з оцінкою та планом робіт, нам потрібно зрозуміти поточну архітектуру DEX: на якому стеку написані контракти, як влаштовані пули ліквідності, оракули та маршрутизація ордерів, які зовнішні сервіси зав'язані на смарт-контракти. Опишіть це у вільній формі — далі наші інженери самі поставлять уточнювальні запитання.

Далі робота йде за етапами:

• Розбір поточної архітектури. Дивимося контракти, схеми зберігання стану, залежності між модулями — фіксуємо, що переноситься як є, а що потребує переписування під модель виконання StarkNet.
• Аудит DEX перед міграцією. Перевіряємо логіку пулів, розрахунок свопів, права адміністратора та обробку зовнішніх викликів — знаходимо місця, які на новій мережі поводитимуться інакше.
• План міграції та оцінка. Розбиваємо роботу на етапи: контракти, інтеграції, тестова мережа, основна мережа. По кожному — склад робіт, залежності та строки.
• Розробка Cairo-контрактів. Переносимо логіку з урахуванням особливостей мережі: розділення на компоненти, робота зі сховищем, виклики між контрактами.
• Тестування та верифікація. Проганяємо сценарії свопів, додавання та виведення ліквідності, перевіряємо граничні випадки та поведінку при відмовах.
• Деплой та супровід. Розгортаємо контракти, перевіряємо їх в оглядачі мережі, передаємо документацію та залишаємося на зв'язку після запуску.

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

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