Розробка Stacks: де ламається зв'язка з Bitcoin
Stacks обирають, коли застосунку потрібна розрахункова база Bitcoin, але логіка має жити в контрактах. Стан і обчислення залишаються на другому шарі, а розрахунки та порядок успадковуються від базової мережі. Саме цей стик — зв'язка шарів розрахунків — і стає місцем, де розробка Stacks ламається найчастіше.
Перше вузьке місце — підтвердження. Операція на другому шарі проходить швидко, але остаточною її робить запис у базовий шар, а той збирає блок не за нашим розкладом.
Поки запис не пройшов, транзакція виглядає успішною, хоча розрахунок ще не закріплено — застосунок показує користувачу актив, яким той поки не розпоряджається.
Друге — порядок виходу даних у базовий шар. Дані другого шару потрапляють туди пакетом, і черговість усередині пакета не збігається з тією, у якій операції йшли в користувача.
Введення та виведення sBTC додають свої вікна очікування, тому «успішно» й «розрахунково» — два різні стани, які потрібно розрізняти в коді.
Третє — розходження стану. Контракти Clarity і те, що читає застосунок, оновлюються не синхронно: сервіс читання відстає на кілька блоків. Наслідок — ручні звірки: черговий звіряє баланси, розбирає завислі виведення й вручну дораховує операції, які мережа вже підтвердила.
Далі розбираємо, як це закривається інженерно: проєктуванням очікування фінальності, ідемпотентними операціями та автоматичними звірками, які знаходять розходження раніше, ніж його побачить користувач.
Що змінюється після впровадження: строки, відмови, перевірність
Перевірність операцій тут не декларація, а властивість платформи: логіка на Stacks описується читабельним вихідним кодом, стан реєстру виводиться із самого ланцюга Bitcoin, а не з вивантаження внутрішньої бази.
Операцію можна перевірити за опублікованим кодом і поточним станом — без доступу до нашої інфраструктури. Ручна звірка реєстру перестає бути щомісячною процедурою: розходження видно на рівні правил, а не в кінці кварталу.
Строк виходу нової версії логіки скорочується, тому що правило описується декларативно й проганяється набором тестів на клоні мережі до публікації.
Випуск більше не залежить від ручних вивантажень і листування між системами: зміна проходить одну процедуру, а попередня версія залишається доступною для відкату. Типовий цикл правки правила займає дні замість тижнів погоджень.
Клас відмов, який закривається першим, — розсинхрон між обліком і фактичним станом у ланцюгу. Подвійні записи, загублені події, «завислі» перекази sBTC зникають, тому що джерелом істини стає перевірюваний стан, а не база-посередник.
Вартість простою падає завдяки локалізації: інцидент зводиться до конкретного правила, а не до всієї інтеграції, і відтворюється на тестовому клоні. На виході у замовника свій контур перевірки — доступ до контрактів, тестів і журналу операцій.
Розробка на Stacks: порівняння варіантів інтеграції
Схему інтеграції обирають за двома питаннями: де живе стан і хто відповідає за фінальність розрахунків. Контракти Clarity на базовому шарі, окремий шар із мостом, гібридна схема та закритий контур закривають різні класи задач — і різняться не зручністю, а моделлю довіри.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Контракти Clarity на базовому шарі | Розрахунки мають успадковувати безпеку Bitcoin, логіка публічна й перевірювана | Комісія та затримка на кожну операцію, обмежений обсяг стану, часті виклики дорогі |
| Окремий шар розрахунків із мостом | Багато операцій, потрібен швидкий відгук і низька вартість транзакції | Міст між шарами — додаткова точка довіри та період виведення коштів |
| Гібридна схема | Критичні правила залишаються на базовому шарі, навантажені виносяться назовні | Рознесена логіка: дорожчий аудит, потрібна синхронізація стану між частинами |
| Закритий контур | Внутрішні розрахунки, конфіденційні дані, вимоги до ізоляції | Безпека публічної мережі не успадковується, збереженість цілком на операторі |
Межі між варіантами розмиває sBTC: актив переміщується між шарами, не втрачаючи прив'язки до базового.
Але правила це не скасовує — чим більше логіки йде з контрактів Clarity, тим більше припущень про довіру потрібно зафіксувати до старту, інакше гібридна схема перетворюється на закритий контур із зайвими сутностями.
Етапи: аудит логіки, схема контрактів, перевірка, передача
Порядок робіт тут не декоративний: контракт на Clarity після публікації незмінний — виправити одрук у ньому не можна, можна лише випустити новий і перенести в нього стан. Тому спочатку йде аудит і схема, а код пишеться вже під зафіксовану схему.
- Аудит логіки та поточного контуру — читаємо наявні контракти й звернення до сховища, розмічаємо опубліковані функції, права адрес і пов'язані баланси. На виході — карта ризиків: що не можна переписати й що доведеться переносити.
- Схема контрактів — розкладаємо логіку на мінімальну кількість модулів: ядро зі станом, модуль прав, допоміжні виклики. Фіксуємо публічні функції, події, структуру сховища та порядок публікації — від нього залежить, до якої точки можливий відкат.
- Реалізація та перевірка граничних випадків — пишемо контракти й покриваємо кожну гілку відмови окремою перевіркою: повторний виклик, недостатність прав, нульовий ввід, спроба вивести більше, ніж є на балансі.
- Тестовий контур — прогін в ізольованій мережі на реальних сценаріях: поповнення та виведення sBTC, обмін між контрактами. Окремо дивимося поведінку при перевантаженні мережі Bitcoin, коли підтвердження йдуть повільно.
- Розгортання — публікація етапами: спочатку контракти, потім права, далі перенесення стану, кожен крок із перевіркою. Ключі й доступи видаємо за мінімально необхідним набором.
- Приймання та передача — проганяємо контрольні сценарії разом із вашою командою, звіряємо результат з очікуваним, віддаємо документацію: схему контрактів, перелік функцій, порядок оновлення та аварійної поведінки, плюс навчання команди.
Що входить до пакета передачі: код, схеми, регламенти
Передача проєкту — це не архів із кодом і не список адрес розгорнутих контрактів. Ми віддаємо комплект, за яким ваша команда може провести незалежну перевірку, внести зміну та відновити роботу після збою без нашої участі. Нижче — що саме входить до пакета.
- Вихідні коди контрактів. Тексти контрактів на Clarity з коментарями, тести, скрипти розгортання та відтворюваної збірки. Репозиторій піднімається на чистій машині однією командою — без «у мене локально працює».
- Схеми взаємодії шарів. Як контракти пов'язані з гаманцем і зовнішніми сервісами, де проходять межі довіри, які точки відмови до якого збою призводять і як це діагностується.
- Політики доступу та ключів. Ролі, пороги підписів, порядок ротації ключів і видачі прав. Права адміністратора передаються вам — ми не залишаємося єдиними, хто може змінити контракт.
- Документація. Опис інтерфейсів, форматів викликів, подій і структури зберігання. Окремий розділ — чому ухвалено ті чи інші рішення й що розглядали як альтернативу.
- Регламент оновлення. Покрокове викочування нової версії: підготовка, міграція стану, вікно та умови відкату на попередню версію без втрати даних.
- Регламент розбору інцидентів. Що вважається інцидентом, хто реагує, як призупиняється робота контракту, як фіксується причина й що змінюється після розбору.
Приймання йде по-інженерному: ваша команда розгортає проєкт за нашою документацією та проводить пробну зміну в тестовій мережі. Усе, що не відтворюється або потребує наших пояснень, вважаємо дефектом передачі й закриваємо до підписання.
Кейс: розрахунки в Bitcoin-мережі без простою та ручних звірок
Клієнт — розрахунковий сервіс, де логіка виплат і обліку жила у зв'язці внутрішньої бази та ручних звірок оператора.
Правила випускали за регламентною процедурою: правка, рев'ю, ручний прогін, міграція — цикл займав близько трьох тижнів, а кожна зміна тягла за собою чотирьох людей і вікно нічних робіт.
Що змінили
Логіку розрахунків і лімітів перенесли в контракти на Stacks — другий шар Bitcoin-мережі з власним виконанням і фінальністю, прив'язаною до Bitcoin. Стан і правила стали єдиним джерелом істини: оператор перестав зводити баланси вручну й підтверджує лише винятки.
Випуск оновлення скоротився з трьох тижнів до двох днів — перевірки контракту відпрацьовують до викочування, а не після.
Що стало
Частка відмов на операціях виплат упала з 4,1% до 0,3%: спірні випадки відсікаються перевірками до запису, а не розбираються постфактум.
Час відновлення після збою скоротився з восьми годин до сорока хвилин — стан піднімається з мережі, відкат виконується переходом на попередній контракт.
Обсяг ручних звірок знизився з дев'ятисот операцій на місяць до шістдесяти: залишилися лише розходження на боці зовнішніх контрагентів, які в контурі не закриваються.
Що робити, якщо логіка вже розгорнута в іншій мережі?
Переноситься один в один те, що не залежить від мови: модель даних, ролі й права, інваріанти — сума балансів, графік розблокування токенів, пороги мультипідпису — і математика розрахунків.
Це правила, а не код, тому під час розробки на Stacks їх описують заново, але перевіряють тими самими тестами на тих самих наборах даних.
Далі починається міграція логіки, і тут вирішує модель виконання. Clarity — не Тюринг-повна мова: циклів із наперед невідомою кількістю ітерацій і виклику контракту за адресою під час виконання в ній немає.
Зате немає й повторного входу — звичні блокування знімаються як непотрібні, а обхід масиву розкладається на індекс і окремі виклики.
Активи влаштовані інакше: залишок прив'язаний до розрахунків у Bitcoin-мережі, тому введення та виведення коштів — окремий контур із власними правилами підтвердження.
Там, де облікова модель давала миттєвий запис балансу, тут з'являється очікування й власна обробка скасованих операцій.
Перенесення контуру цілком — це знімок, а не перелив усієї історії: фіксуємо блок, вивантажуємо агрегати й карту залишків, за журналом операцій рахуємо корінь. Він і слугує доказом походження коштів, коли деталі згортаються в архів.
Паралельні контури тримають на час переходу: попередній переводять у режим лише читання, новий приймає запис, випуск активів на це вікно закривається — інакше подвійна витрата.
Перемикання йде за звіркою контрольних сум на кожному кроці, а відкат — це повернення трафіку на попередній контур.
Часті технічні сумніви перед стартом робіт
Перед стартом замовник і його інженери задають одні й ті самі питання. Вони стосуються не самої технології, а ризиків: навантаження на базовий шар, приватності даних, гарантій коректності та того, що буде після передачі коду. Нижче — короткі відповіді.
Чи не стане застосунок дорожчим у роботі зі зростанням кількості операцій?
Дії користувачів не створюють окрему транзакцію в базовому шарі: логіка виконується в шарі Stacks, а в Bitcoin іде агрегований запис.
Навантаження зростає від кількості таких записів, а не від кількості викликів контракту, тому піковий трафік не дає лінійного зростання споживання базового шару.
Як бути, якщо частину даних не можна розкривати?
У контракті зберігається ідентифікатор або хеш запису, а не сам вміст. Дані лежать у зовнішньому сховищі з розмежуванням доступу, при цьому перевірність зберігається: за хешем видно, що запис не підмінявся.
Як ви доведете, що контракт коректний?
Clarity виконується детерміновано й без циклів, тому логіка піддається статичному розбору. Ставимо перевірки властивостей на випадкових наборах входів, проганяємо сценарії відмови на локальній копії мережі та віддаємо код на незалежний аудит до публікації.
Що буде після передачі проєкту?
Опублікований контракт незмінний, тому оновлення — це нова версія плюс перенесення стану. Передаємо вихідні коди, схему розгортання, регламент міграції та набір перевірок, які ловлять розходження стану після випуску.
У нас своя команда. Як ділимо роботу?
З першого дня працюємо у вашому репозиторії: спільні перевірки коду, єдиний порядок гілок, доступ до стендів. Зони відповідальності фіксуємо явно — ваші інженери ведуть продуктову логіку та інтерфейс, ми закриваємо контракти й інтеграцію з базовим шаром.
Обговоримо задачу: з чого почати і що надіслати
Щоб повернутися з оцінкою та планом етапів, а не з уточнювальними питаннями через тиждень, нам достатньо одного листа з ввідними. Нижче — те, що реально впливає на трудомісткість розробки на Stacks: від моделі доступу до sBTC до того, хто на боці замовника ухвалює рішення.
- Опис процесу — як логіка працює зараз: хто ініціює операцію, де фіксується результат, які перевірки обов'язкові перед записом у мережу.
- Схема контуру — з яких сервісів складається система, де зберігаються ключі підпису, які зовнішні системи викликаються і в який бік ідуть дані.
- Межі першої ітерації — які сценарії йдуть у контракти на Clarity, а які свідомо залишаються за периметром.
- Обмеження за строками — чи є зовнішні дати, від яких залежить порядок етапів, і що важливіше: ранній робочий прототип чи одразу промисловий контур.
- Ролі в команді замовника — хто володіє продуктом, хто приймає результат, хто відповідає за інфраструктуру та доступи.
- Доступи та середовища — репозиторій, тестовий контур, тестові активи для перевірки переказів і відкатів.
- Поточні напрацювання — якщо контракти або серверна частина вже є, надішліть їх: розбір готового коду змінює і план, і порядок етапів.
Чорнова схема теж підходить: за нею ми фіксуємо межі робіт, ризики та точки приймання. Щоб обговорити задачу предметно, достатньо короткого опису — повернемося з оцінкою та планом етапів.
