Чому транзакції в Liquid Network застрягають і губляться
У сайдчейні біткоїна Liquid Network блоки підписує не майнер, а федерація підписантів — розподілена група вузлів, кожен з яких незалежно перевіряє набір переказів.
Поки потрібна кількість учасників не поставить підпис, блок не зібрано, і переказ залишається в статусі очікування: у гаманці це виглядає як зависла транзакція, хоча мережа формально працює.
Причин зазвичай три. Розсинхрон вузлів — частина учасників відстала за висотою блоків і бачить інший набір переказів, ніж решта. Неповний набір підписантів — вузол випав із ротації або втратив ключ, і поріг голосів не збирається.
Ручні звірки — розбіжність закривають листуванням і таблицями, а не автоматикою, тому переказ висить годинами.
Втрачені підтвердження — окремий клас відмов. Облікова система вважає переказ завершеним, не дочекавшись фінальності, а при зміні гілки блоків запис змінюється. Розбіжність балансів між учасниками спливає пізніше, вже на звірці, і розбирати її доводиться вручну.
Ціна помилки — не лише затримка: учасник втрачає довіру до розрахунків, а бізнес-процес зупиняється на розборі інциденту. Нижче розбираємо, як ці збої закриваються на рівні конфігурації вузлів, моніторингу стану федерації та регламенту підтверджень.
Що дає випуск активів і розрахунки на біткоїн-сайдчейні
Токенізація активів починається не з коду, а з правил випуску: хто має право розпоряджатися емісією, які ліміти діють, за яких умов власник обмінює актив на базовий біткоїн.
Ці правила фіксуються в самому активі, тому партнерам більше не потрібно вірити випискам одне одного — обидві сторони читають один і той самий стан реєстру.
Далі випуск активів на сайдчейні Liquid Network вкладається в передбачувану хронологію. Емісія, передача прав і погашення — це транзакції з підтвердженням у кількох блоках, а не доручення, які чекають відкриття операційного вікна. Розрахунки йдуть цілодобово, тому угода закривається того самого дня, коли сторони домовилися.
- Узгодження — описуємо ролі підписантів, ліміти випуску та порядок обміну активу на базовий біткоїн.
- Емісія — актив випускається під забезпечення, обсяг і отримувач видно учасникам одразу.
- Розрахунок — сторони змінюють актив і забезпечення в одній транзакційній моделі, без посередника посередині.
- Звірка та погашення — стан реєстру збігається в обох сторін, ручні звірки залишаються лише для зовнішніх систем обліку.
Що це змінює в метриках: час розрахунків скорочується з днів до годин, частка автоматичних звірок доходить до одиниці, а клас відмов «розрахунок завис через недоступність учасника» зникає — правила виконує мережа, а не черговий оператор.
Порівняння режимів мережі: відкритий і закритий контур
Режим роботи визначає, хто бачить операції, хто має право випускати активи і на якій множині вузлів тримається консенсус. Вибір залежить від кількості учасників, їхньої готовності розкривати обороти одне одному та від потреби у зовнішній ліквідності. Нижче — три режими роботи Liquid Network, між якими обирають під час підключення.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Відкритий режим мережі | Публічний випуск активу, розрахунки із зовнішніми контрагентами, вихід на біржову ліквідність | Суми та тип активу приховані, але факт, час і зв’язки адрес видно спостерігачу |
| Закритий контур підписантів | Розрахунки всередині групи компаній або клубу учасників, де всі відомі та допущені | Консенсус тримається на довіреному наборі: недоступність частини підписантів зупиняє мережу, зовнішньої ліквідності немає |
| Гібридна схема | Приватний розрахунковий контур плюс публічний для виходу на ринок | Дорожче в супроводі: облік і баланси зводяться між двома контурами, аудит складніший |
Відкритий режим сумісний із зовнішніми гаманцями та кастодіальними сервісами майже без доопрацювань — він підходить, коли в розрахунках є контрагенти, яких ви не контролюєте.
Закритий контур вимагає, щоб кожен учасник підняв вузол і пройшов процедуру допуску; зате периметр відомий, і операції не покидають групу.
Обмеження конфіденційності проговорюємо до старту: в обох режимах приховані суми та тип активу, але підписанти контуру бачать сам факт операції та її учасників.
Якщо потрібно приховати й це, знадобиться інша архітектура — такі вимоги розбираємо на етапі сумісності, а не після запуску.
Етапи впровадження: від аудиту вимог до запуску
Роботи будуємо так, щоб рішення щодо інфраструктури та емісії ухвалювалися до першого запуску в основній мережі: спочатку аудит вимог і пілот у тестовій мережі, і лише потім доступ реальним учасникам. Кожен етап закривається артефактом, який замовник може перевірити.
- Аудит інфраструктури — обстежуємо сервери, мережу та канали зв’язку між майданчиками, визначаємо, де розміщувати вузли і який запас за диском і пропускною здатністю потрібен під зростання кількості транзакцій.
- Схема ролей і ключів — фіксуємо, хто підписує випуск, хто проводить розрахунки, як ключі розподіляються між зберігачами і що відбувається при вибутті одного з них.
- Налаштування вузлів — піднімаємо екземпляри, підключаємо до пірів, доводимо синхронізацію до стійкої, ставимо моніторинг і резервний вузол, щоб відмова одного не зупиняла роботу.
- Підготовка випуску активу — узгоджуємо параметри активу, точність подрібнення, правила блокування та перевипуску, збираємо конфігурацію під конкретний сценарій розрахунків.
- Випуск активу — проводимо емісію в тестовому контурі, звіряємо розподіл із реєстром зберігачів, потім повторюємо в основній мережі.
- Перевірка розрахунків — проганяємо приймання та відправлення, часткове підписання, блокування й розблокування, відновлення після розриву зв’язку; результат фіксуємо за кожним сценарієм.
- Передача та навчання — віддаємо документацію й регламенти, навчаємо вашу команду штатним операціям, залишаємося на зв’язку для розбору інцидентів.
Політики доступу, ключі та схеми випуску активів
Проєкт вважається зданим не в момент, коли вузол синхронізувався, а коли команда експлуатації випускає актив, додає підписанта і відновлює доступ без нас. Тому разом із розгорнутою інфраструктурою замовник отримує комплект артефактів — від конфігурацій до регламентів.
- Політики доступу — матриця ролей із поділом на випуск, підтвердження та читання: що доступно вузлу, який випускає, що — гаманцю спостерігача, які операції потребують другого підпису.
- Схема ключів підписантів — поріг підписів для випуску та перевипуску, склад утримувачів, порядок видачі ключів і правила зберігання резервних копій поза мережею.
- Схема випуску активів — покроковий порядок емісії: підготовка гаманця, формування транзакції, підтвердження утримувачами, прив’язка токена перевипуску до наступних емісій.
- Конфігурації вузла — файли налаштувань із коментарями: які параметри впливають на індексацію, ліміти з’єднань і глибину зберігання історії.
- Регламент обслуговування — що перевіряється і з якою періодичністю, як застосовуються планові оновлення, як проходить перезапуск без зупинки випуску.
- Резервне копіювання та відновлення — склад копій, порядок підйому вузла в чистому середовищі й перевірка цілісності стану після відновлення.
- Ротація та відкликання ключів — виведення підписанта зі схеми та заміна ключа при компрометації без перезбирання активу.
- Документація вузла — карта сервісів, схема мережі, точки моніторингу й оповіщень, журнал змін інфраструктури.
Такий комплект знімає залежність від підрядника: випуск, ротація та відновлення залишаються на вашій стороні.
Розбір впровадження: метрики розрахунків до і після
Розрахунковий контур із чотирьох учасників — брокер, кастодіан, маркетмейкер і кліринговий відділ — закривав угоду за дев’ять кроків.
Підтвердження лімітів, ручна звірка доручень, виписки, повторне підтвердження: від доручення до розрахунку минало близько двох робочих днів, а розбіжності в сумах спливали вже після клірингу — до 12 випадків на місяць, кожен розбирався поштою й таблицями.
Ми перевели облік зобов’язань у Liquid Network: активи випускаються в цифровому вигляді, адреси закриті мультипідписом, суми угод недоступні зовнішнім спостерігачам.
Звірку пов’язав один ідентифікатор угоди — він же в дорученні, в транзакції та у виписці, тому розбіжність видно в момент фіксації, а не через день.
Метрики до і після
Час розрахунку скоротився з двох робочих днів до десятків хвилин: підтвердження надходить в одному раунді замість листування. Зниження ручних операцій — близько 90%: залишилися лише винятки, як-от відхилені ліміти та нестандартні комісії.
Розбіжності за підсумками кварталу — нуль проти попередніх 12 на місяць, розбір кожного більше не займає час розрахункової групи.
Окремо закрили питання аудиту: журнал зберігає ідентифікатор і час фіксації угоди, суми контрагентів до нього не потрапляють. Такий розбір впровадження повторюємо — логіка переноситься на нові пари активів без переписування розрахункового контуру.
Чим відрізняється Liquid Network від основного шару Bitcoin?
Основний шар Bitcoin тримає сам BTC і безпеку через майнерів. Liquid Network — незалежна мережа зі своїм консенсусом, яка не замінює основний шар, а розширює його: застава BTC залишається на основному шарі біткоїна, а операції йдуть у сайдчейні через двосторонню прив’язку.
Швидкість розрахунків відрізняється на порядок. Блоки в сайдчейні виходять часто й з передбачуваним інтервалом, підтвердження займає секунди, а комісія не бере участі в аукціоні за місце в блоці при перевантаженні основного шару.
Для потоку дрібних операцій — виплат, розрахунків між контрагентами — це змінює архітектуру всього сервісу.
Конфіденційність влаштована інакше. Транзакції приховують суму та тип активу від сторонніх спостерігачів, але адреси відправника й отримувача залишаються видимими: це приватність розрахунків, а не анонімність учасників. Повністю прихований граф зв’язків на одному сайдчейні не побудувати.
Склад підписантів — головна відмінність сайдчейну. Блоки виробляють функціонери федерації, виведення BTC контролюють зберігачі мультисигу зі зв’язаною заставою, тобто довіра зміщується від обчислювальної потужності майнерів до заздалегідь визначеного кола операторів. Звідси вимоги до порогів підписів, змінюваності та публічної звітності.
Розподіл активів простий: випуск і обіг токенізованих активів, часта торгівля та емісія йдуть у сайдчейн, а сам BTC і підсумкове врегулювання залишаються на основному шарі.
Переведення активів між шарами потребує блокування та випуску з підтвердженнями федерації, лімітами й затримкою на виведення, тому зворотний шлях завжди довший за внутрішній переказ.
Технічні питання: комісії, конфіденційність, відкати
Технічні сумніви щодо інтеграції з Liquid Network зазвичай зводяться до чотирьох питань: скільки коштує операція, хто бачить суми, що відбувається при збої та чим покриті випущені активи. Нижче — короткі відповіді; деталі розбираємо на етапі проєктування.
Як розраховуються комісії в Liquid Network?
Комісія сплачується в L-BTC, прив’язана до ваги транзакції й не залежить від поточного завантаження: блоки виробляються підписантами з постійним інтервалом. Аукціону за місце в блоці немає, тому вартість операції передбачувана і закладається в тариф сервісу заздалегідь.
Наскільки конфіденційні транзакції?
Суми та тип активу приховані — в ланцюжку видно входи, виходи й сам факт переказу. Ключ засліплення передається контрагенту, і його можна пред’явити аудитору для розбору однієї операції, не розкриваючи всю історію гаманця.
Чи можливий відкат транзакції?
Підтверджений переказ стає незворотним. Тому адреса валідується до відправлення, ставляться ліміти й мультипідпис, а в логіці обміну передбачається гілка з блокуванням за часом — вона повертає кошти, якщо друга сторона не завершила угоду.
Чим забезпечені випущені активи?
Кожен такий актив емітується під базовий і забезпечений 1:1: емітент тримає резерв, а ключ аудиту дозволяє звірити обсяг емісії з фактичним покриттям. Сам L-BTC забезпечений біткоїном, заблокованим в основній мережі через федерацію підписантів.
Обговоримо задачу: підберемо режим і склад вузлів
Оцінка обсягу робіт починається не з вибору технологій, а з меж системи: що саме випускається, хто тримає ключі та який рівень відмовостійкості потрібен.
Нижче — вступні, яких достатньо, щоб обговорити задачу предметно й повернутися з планом впровадження, а не із загальними міркуваннями.
- опис активу та логіки випуску: що емітується, на яких умовах, хто підтверджує операції;
- бажаний склад вузлів: власний повний вузол, полегшений або лише спостережний за станом мережі;
- контур розгортання: публічна мережа або ізольоване середовище із заздалегідь визначеним колом учасників;
- модель доступу до ключів: апаратні сховища, мультипідпис, розподіл ролей між співробітниками;
- вимоги до доступності та відновлення: допустимий час простою й порядок повернення після збою;
- точки стикування із наявними системами: обліковий контур, внутрішні сервіси, аналітика;
- обмеження щодо розкриття даних: кому і в якому обсязі видна історія операцій.
З цих відповідей збирається план впровадження: спочатку піднімаємо контур Liquid Network і перевіряємо синхронізацію, потім виводимо актив в обіг на обмеженому колі учасників, після — стикування й моніторинг.
Обсяг робіт оцінюємо за кожним етапом окремо, тому проєкт можна призупинити на будь-якому кроці без втрати вже зробленого. Опишіть задачу у вільній формі — повернемося з оцінкою та планом.
