Арк і Спарк: Відновлення канальних фабрик для масштабування Lightning Network

Арк і Спарк: Канальні фабрики, яких ми чекали

Візії майбутніх технологій часто мають правильне уявлення про загальні напрямки, але програють у деталях. Плашки у фільмі «2001: Космічна одіссея» дійсно нагадують iPad, але ви ніколи не бачите, як астронавти платять за підписки чи витрачають години на Candy Crush.

Канальні фабрики є одним із бачень, які з`явилися на початку історії Lightning Network для вирішення деяких викликів, з якими стикається Lightning з самого початку. Незважаючи на те, що вона стала найбільш успішним рішенням другого рівня для масштабування Біткойна з миттєвими та низькими комісіями, масштабування Lightning обмежене залежністю від платіжних каналів. Хоча Lightning переносить більшість транзакцій поза ланцюг, кожен платіжний канал все ж вимагає транзакції в ланцюзі для відкриття та (зазвичай) для закриття. З ростом прийняття, зростає і тиск на блокчейн. Необхідність у більш масштабованому підході до управління каналами є очевидною. Канальні фабрики повинні були задовольнити цю потребу, але де ж вони?

У 2025 році з`являються підмережі, які відновлюють імпульс канальних фабрик з новими деталями, що значно підвищують їх потенціал. Вони є нативно сумісними з Lightning і досягають більшого масштабу, дозволяючи групі учасників відкривати спільний multisig UTXO та створювати кілька двосторонніх каналів, що зменшує кількість транзакцій у ланцюзі та покращує капітальну ефективність. Досягнення більшого масштабу шляхом зменшення складності, Арк і Спарк виконують ту ж функцію, що й традиційні канальні фабрики, але з новими дизайнами та додатковими можливостями, заснованими на спільних UTXO.

Канальні фабрики 101

Канальні фабрики існують з моменту виникнення Lightning. Фабрика - це багатоучасницький контракт, де кілька користувачів (не лише двоє, як у каналі Dryja-Poon) спільно блокують кошти в одному мультипартійному UTXO. Вони можуть відкривати, закривати та оновлювати канали поза ланцюгом без оновлення блокчейну для кожної операції. Тільки коли учасники покидають або фабрика розпадається, потрібна транзакція в ланцюзі.

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

Проте, не випадково, що канальні фабрики в основному залишалися на етапі проектування, незважаючи на їхні обіцянки. Зазвичай канальна фабрика вимагає, щоб усі учасники були онлайн і співпрацювали для оновлення її стану, якщо не існують спеціальні домовленості або протоколи для обробки асинхронності. Наприклад, постачальники послуг Lightning (LSP) не можуть використовувати канальні фабрики для управління каналами з їхніми користувачами, оскільки всі партнери повинні бути відомі на момент створення фабрики. Без можливості поступово додавати партнерів до існуючої фабрики модель стає непрактичною для вузлів, чия масштабованість вбудована в їх бізнес-модель, як це відбувається з LSP. Крім того, обробка виходів з фабрики, особливо коли учасники не реагують або є зловмисними, передбачає складні механізми, які можуть вимагати від учасників попереднього підписання великого дерева потенційних вихідних транзакцій, охоплюючи всі можливі комбінації співпраці та неспівпраці. Уявіть собі фабрику з п`яти осіб, де один партнер виходить з мережі або виявляє ненадійність — кожному з залишених учасників знадобиться попередньо узгоджений, попередньо підписаний шлях виходу для кожного можливого випадку. Без автоматизації або підтримки договорів управління цим стає комбінаторним та експлуатаційним кошмаром. Ці технічні та UX обмеження ускладнюють доставку безшовного досвіду для користувачів або масштабування таких систем на виробництві.

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

Коротка історія пропозицій канальних фабрик

Одна з перших та дуже комплексних пропозицій для канальних фабрик була запропонована Конрадом Бурчерт, Християном Декером та Роджером Ваттенгольфером у їхній статті 2017 року «Масштабоване фінансування мереж мікроплатежів Біткойна». Їхній дизайн дозволяє групі учасників блокувати кошти в одному мультипартійному UTXO та відкривати кілька каналів поза ланцюгом між парами учасників. Кожен перехід стану (відкриття каналу, закриття або перерозподіл) вимагає повного набору попередньо підписаних транзакцій. Це забезпечує криптографічно захищений спосіб виходу з фабрики для кожного учасника, якщо це необхідно.

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

Зусилля з покращення цієї моделі використовували нові функції Біткойна. Taproot спрощує структуру вихідних транзакцій, дозволяючи їх умовам бути інкапсульованими в дереві Меркла скриптів, з виявленим лише шляхом витрати під час викупу. Це зменшує як розмір транзакції, так і витік приватності. OP_CHECKTEMPLATEVERIFY (OP_CTV), пропонований м`який форк, істотно спростив би фабрики, дозволяючи попередньо зобов`язані вихідні шляхи без необхідності вичерпного попереднього підписання. З OP_CTV фабрика могла б зобов`язатися до набору вихідних транзакцій під час створення. Кожен учасник знав би, що може односторонньо вийти чітко визначеним чином, зменшуючи як взаємодію, так і експлуатаційну складність.

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

Арк і Спарк: Канальні фабрики наступного покоління

Два недавні проекти, Арк і Спарк, переосмислюють канальну фабрику з різними компромісами. Хоча жоден з проектів не позиціонує себе явно як «канальна фабрика», їх архітектури ефективно реалізують багато цілей, які переслідували ранні пропозиції канальних фабрик. Оскільки обидва засновані на спільному UTXO і обидва нативно сумісні з Lightning, Спарк і Арк представляють сучасні втілення канальних фабрик, які використовують сьогоднішнє обладнання та припущення. Нарешті! Обидва прагнуть зберегти переваги канальних фабрик (зменшене використання ланцюга, масштабоване розподілення ліквідності) при розв`язанні ключових слабкостей щодо активності, взаємодії та складності виходу. Найважливіше, що обидва проекти підходять до масштабування з практичної точки зору. Вони працюють в межах поточних консенсусних правил Біткойна, уникаючи необхідності в м`яких форках чи нових опкодах для того, щоб бути корисними сьогодні.

Спільне використання UTXO

Арк впроваджує модель спільного використання UTXO, побудовану навколо концепції віртуальних UTXO (VTXO). Замість того, щоб призначати користувачам індивідуальні виходи в ланцюзі, Арк дозволяє їм проводити транзакції поза ланцюгом, використовуючи спільний пул ліквідності, керований сервером Арк. Користувачі проводять транзакції, запитуючи, щоб новий розподіл VTXO було включено в наступний раунд, коли сервер Арк створює «блок Арка», агрегуючи недавню діяльність користувачів і публікуючи новий спільний UTXO в блокчейні. Таким чином, Арк дозволяє користувачам передавати VTXO між собою і періодично компенсувати розподіл VTXO у спільному UTXO через згруповані транзакції закріплення на блокчейні.

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

Спарк обирає інший шлях до спільних UTXO, що базується на концепції statechains. Ключовою ланкою спільного протоколу підписання Спарк є Оператори Спарк (SO), які об`єднуються в консорціум під назвою Сутність Спарк (SE). Коли користувач приєднується до Спарк, він вносить кошти на адресу спільного підпису, контрольовану як ними, так і SE. SE та користувач попередньо підписують транзакцію на виведення, гарантуючи, що користувач завжди може вийти односторонньо. Платіж відбувається щоразу, коли з`являється нова транзакція на виведення, що створює новий поточний стан. З часом історія транзакцій набуває структури дерева, що відгалужується від оригінального спільного UTXO, і кожна термінальна транзакція, що належить користувачу, називається «листом». Звісно, після кожної зміни SO повинні видалити минулі ключі, що використовувалися для попереднього власника (тобто видалити старі листи), і лише один із SO в SE повинен це зробити, щоб система працювала безпечно. Це дозволяє Спарк пропонувати мінімізовані в плані довіри, самообслуговуючі поза ланцюгові платежі, зберігаючи базовий UTXO незмінним.

Як і Арк, Спарк також вводить деякі нові припущення про довіру. Спарк вимагає, щоб принаймні один SO (або деякий вищий конфігуруємий поріг) у SE діяв чесно і видаляв застарілі транзакції на виведення. Результатом є модель довіри «моменту часу», у якій довіра потрібна лише в момент передачі: система зберігає ідеальну безпеку в далеких перспективах, якщо оператори видаляють свої частки ключів після передачі. Як тільки ключі видаляються, навіть скомпроментований або злостивий оператор не може ретроактивно вплинути на минулі транзакції або вкрасти кошти, і видалення будь-якого SO зараховується всім SO в SE, розподіляючи відповідальність між кількома операторами.

Сумісність з Lightning

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

Якщо це виглядає як качка...

Канальні фабрики збільшують масштаб, використовуючи спільні UTXO для збільшення масштабованості Lightning. З цієї точки зору Арк і Спарк є безумовно канальними фабриками, хоча і з найновішими технологіями VTXO та statechain. В умовах того, що моделі спільних UTXO вже досягли, ми можемо очікувати великих досягнень від лабораторій канальних фабрик у найближчому майбутньому — особливо якщо до L1 буде додано нові опкоди.

І Арк, і Спарк є значними досягненнями самі по собі, але вони також валідують Lightning. Без можливості взаємодії з іншими підмережами — Liquid, Fedimint, Cashu тощо — ці модернізовані канальні фабрики були б значно менш цінними. І саме Lightning дозволяє їм взаємодіяти практично скрізь, куди може піти Біткойн. Поява Спарка та Арка не є знаком обмежень Lightning, а свідченням його незамінності в сучасній економіці Біткойн.

Не пропустіть свій шанс отримати випуск «Lightning Issue» — з ексклюзивним інтерв`ю з співавтором Lightning Таджем Дріджею. Це заглиблюється в найпотужніший шар масштабування Біткойна. Обмежений тираж. Доступно тільки поки є запаси.

Цей матеріал є статтею, представленою в останньому друкованому виданні Bitcoin Magazine, «The Lightning Issue». Ми ділимося ним тут, щоб показати ідеї, розглянуті по всьому випуску.

Цей пост «Арк і Спарк: Канальні фабрики, яких ми чекали» вперше з`явився на Bitcoin Magazine і написаний Роєм Шейнфельдом.