Системний розбір Fiber: великий експеримент з впровадження Lightning Network на CKB

23 серпня офіційний CKB опублікував рішення Fiber Network (оптична мережа) на основі мережі CKB. Ця новина швидко викликала дискусії в спільноті і привела до швидкого пампу ціни CKB на 30% протягом одного дня. Головна причина сильної реакції на новину полягає в тому, що Lighting Network має потужний наративний потенціал, а Fiber CKB модифікував традиційну Lighting Network, зробивши багато покращень щодо останнього.

Наприклад, Fiber може нативно підтримувати різні типи активів, такі як CKB, BTC, стабільні монети тощо, при цьому комісії за CKB набагато нижчі, а швидкість реакції вища, що дозволяє Fiber зробити прорив у сфері UX. У плані приватності та безпеки, Fiber також внесла багато покращень.

Крім того, Fiber та BTCLighting Network можуть взаємодіяти між собою, утворюючи більшу мережу P2P, на попередніх офлайн заходах навіть заявлялося, що офіційний CKB навіть планує встановити 100 000 фізичних Нода в Fiber та Lighting Network для сприяння вдосконаленню та просуванню P2P Платіжної мережі. Це безсумнівно найбільша історія в усі часи.

Якщо в майбутньому вдасться реалізувати офіційне бачення CKB, це буде велика Сприятлива інформація як для Lightning Network, так і для екосистеми CKB та BTC. За даними мемпула, в Lightning Network наразі розміщено понад 300 мільйонів доларів, кількість Нод становить приблизно 12 тисяч, і між ними створено майже 50 тисяч платіжних каналів.

А на spendmybtc.com ми також можемо побачити, як все більше та більше торговців підтримують оплату та отримання за допомогою мережі Lighting, якщо привертання BTC стає все сильнішим, енергія підйому платіжних рішень поза блокчейном, таких як Lighting Network та Fiber, обов’язково зростатиме з кожним днем.

З метою систематичного розгляду технічного рішення Fiber, GeekWeb3 написав дослідну звіт про загальну концепцію Fiber. Як реалізація мережі Lighting на базі CKB, принцип Fiber в цілому співпадає з принципом BTCLighting Network, але з багатьма оптимізаціями в деталях.

Загальна архітектура Fiber включає чотири основні частини: платіжний канал, WatchTower, багатоперехідний маршрут та міждоменові платежі. Далі ми розглянемо найважливіший “платіжний канал”.

Основа для мережі Lighting та Fiber: платіжні канали

Платіжний канал суттєво переміщує перекази/операції поза блокчейном, а потім через певний час вони передаються до у блокчейні для ‘Розрахунку’ в кінцевому стані Оскільки операції виконуються миттєво поза блокчейном, часто можна уникнути обмежень по продуктивності основного блокчейну, такого як BTC.

Припустимо, що Еліс та Боб відкрили спільний канал, вони спочатку створюють багатопідписовий рахунок у блокчейні та вкладають у нього гроші, наприклад, Еліс та Боб кожен вкладають по 100 одиниць, як свої баланси в поза блокчейні каналі. Потім сторони можуть проводити кілька переказів у межах каналу, і при виході з каналу синхронізувати кінцевий баланс у блокчейні, шляхом переказу коштів від багатопідписового рахунку до обох сторін, тобто «Розрахунок».

Наприклад, на початку кожна сторона має 100 блоків, потім Еліс переказує Бобу 50, потім Еліс знову переказує Бобу 10 блоків, після чого Боб переказує Еліс 30 блоків, і, нарешті, залишок становить: Еліс—70, Боб—130. Не важко помітити, що загальний залишок двох сторін не змінюється, і приклад з рухомиців відповідно до зображення відображає це ясно.

Якщо одна сторона виходить з каналу, то поточний баланс Alice: 70/Bob: 130 синхронізується у блокчейні, 200 гривень зі спільного рахунку перераховуються кожному залежно від його балансу, завершуючи Розрахунок. Описаний вище процес виглядає просто, але на практиці потрібно враховувати багато складних ситуацій.

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

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

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

Але тут є одна важлива сцена з порушенням: Боб може подати прострочений залишок та обіцянку угоди на у блокчейні, наприклад, якщо було створено Commit Tx3 на зображенні вище, залишок Боба становить 130, але Боб, щоб заробити на собі, подає прострочений Commit Tx2 на у блокчейні, декларуючи, що його залишок становить 160, проте цей стан рахунку не є в режимі реального часу, це типові “Подвійні витрати”.

Для того чтобы уникнути таких ситуацій подвійні витрати, необхідно мати відповідні покарання. Саме проектування покарань є основою всього каналу 1 до 1, розуміння цієї частини є ключовим для розуміння суті платіжного каналу. У дизайні каналу, якщо будь-яка сторона намагається викласти застарілий стан та Commit Tx на у блокчейні, це не тільки не призведе до бажаного результату, але й замість цього може призвести до того, що інша сторона забере всі кошти.

Тут застосовується «несиметрична угода про зобов’язання» та «скасувати Секретний ключ», ці два поняття дуже важливі. Спершу ми пояснимо «несиметричну угоду про зобов’язання». Наприклад, за допомогою Commit Tx3 наступне зображення є схемою угоди про зобов’язання:

Ця обіцяна угода була сконструйована Бобом і надіслана Еліс, щоб вона самостійно зайнялася цим. Як показано на малюнку, це переказ BTC, заява про те, що 70 грошей з рахунку з багаторазовим підписом передаються Еліс, а 130 грошей - Бобу, але умови розблокування грошей “асиметричні”, обмеження, з якими стикається Еліс, більш суворі, що вигідніше для Боба.

Після отримання Алісою обіцянки, побудованої Бобом, вона може додати свій підпис, щоб задовольнити 2/2 багатопідписну умову. Після цього Аліса може активно подати ‘обіцянку’ на ланцюжок, що дозволить їй вийти з каналу. Якщо вона цього не зробить, вона може продовжувати здійснювати перекази у каналі.

Тут потрібно зауважити: ** Ця угода була укладена Бобом за його власною ініціативою, в якій умови невигідні для Аліси, Аліса може тільки прийняти/відхилити, і ми повинні знайти спосіб залишити Алісі деяку автономію. **У дизайні платіжного каналу тільки сама Аліса може поставити транзакцію зобов’язання «невигідна для себе» в блокчейні тригер, тому що транзакція зобов’язання повинна складати мультипідпис 2/2, а у Боба є тільки власний підпис після локальної побудови транзакції, а не підпис Аліси.

Аліса може «лише приймати підпис Боба, але не надсилати йому свій власний підпис», це схоже на угоду, яка не вигідна для вас, потребує підпису вас і іншої сторони, перш ніж ваш підпише документ і передасть його вам, ви можете не допустити іншу сторону до підпису. Якщо ви хочете, щоб угода набрала чинності, підпишіться, а потім опублікуйте, якщо не хочете, щоб угода набрала чинності, не підписуйте або не публікуйте. Очевидно, в даному випадку Аліса має можливість обмежити Боба.

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

Цікаво, що сума отриманих при виході в обох вищезазначених угодах про зобов’язання однакова, але умови видачі різні, це саме те, про що йшлося у попередньому розділі “асиметричних угод про зобов’язання”.

Раніше ми пояснювали, що кожна угода про зобов’язання потребує багато-підпису 2/2, щоб набути чинності. Угода про зобов’язання, підготовлена Бобом на місці, яка йому вигідна, не відповідає вимозі багато-підпису 2/2, а угода про зобов’язання, яка відповідає вимозі багато-підпису 2/2, залишається в руках Аліси, Боб не може її надіслати, його може надіслати лише Аліса, це створює рівновагу. Зворотний процес також має схожий принцип.

Отже, Alice та Bob можуть лише активно подавати угоди про зобов’язання, які не вигідні для них, лише одна сторона подасть Commit Tx на ланцюг та вона набуде чинності, канал буде закритий. Повернемося до сценарію “Подвійні витрати”, про який ми говорили спочатку – що станеться, якщо хтось подасть на ланцюг угоду про зобов’язання, яка вже застаріла?

Тут потрібно згадати щось, що називається “Секретний ключ відклику”. ** Якщо Боб надав стару обіцянку транзакцію на ланцюжок, Аліса може забрати гроші, які належать Бобу, використовуючи Секретний ключ відклику.**

Ми розглянемо цю картину, припустимо, що остання обіцянка транзакції - Commit Tx3, Commit Tx2 прострочені, якщо Боб подасть прострочену Tx2 до у блокчейні, Аліса може забрати гроші Боба за допомогою Секретний ключ відкликання Tx2 (Аліса повинна діяти в межах часового замка).

**Щодо останнього Tx3, Аліса не має секретного ключа для скасування, ** тільки після появи майбутнього Tx4 Аліса зможе отримати секретний ключ для скасування Tx3. Це обумовлено властивостями криптографії з відкритим ключем та UTXO і не буде детально пояснюватися в цій статті через обмежений обсяг.

Ми можемо запам’ятати висновок: якщо Боб сміливо подасть угоди, які закінчилися, на ланцюжок, Аліса зможе взяти гроші у Боба, використовуючи відкликання секретного ключа, як покарання. Зворотньо, якщо Аліса порушить, Боб також може покарати її таким чином. Таким чином, 1 до 1 платіжний канал може ефективно уникнути подвійні витрати, якщо всі учасники є раціональними людьми, то вони не сміють злочинити.

Щодо цього питання платіжних каналів, на основі CKB Fiber в порівнянні з BTCLighting Network має значне вдосконалення, може нативно підтримувати передачу/торгівлю різними типами активів, такими як CKB, BTC та RGB++стейблкоїн, тоді як Lighting Network може нативно підтримувати лише BTC. Після введення в експлуатацію активу TAPROOT BTCLighting Network все ще не зможе нативно підтримувати не-BTC активи, воно зможе підтримувати стейблкоїн тільки опосередковано.

(Джерело зображення: Dapangdun)

Крім того, через те, що Layer1 основний блокчейн, від якого залежить Fiber, є CKB, витрати на відкриття та закриття каналу набагато нижчі, ніж у BTCLighting Network, це не зміцнює велику кількість комісій користувачів, це очевидна перевага у сфері UX.

Цілодобова безпека: Вежа спостереження WatchTower

Проблема з видаленням Секретний ключ, яку було згадано вище: Учасникам каналу потрібно постійно стежити за один одним, щоб запобігти підозрілій поведінці з боку іншої сторони, коли вони намагаються включити прострочену обіцянку транзакцію в ланцюжок. Але ніхто не може гарантувати наявність онлайн протягом 24 годин. Якщо ваш партнер діє зловмисно, коли ви не в мережі, що робити?

Обидва Fiber та BTCLighting Network мають конструкцію вежі спостереження WatchTower, яка допоможе користувачам цілодобово контролювати діяльність у блокчейні. Якщо хтось у каналі надіслав застарілу обіцянку про транзакцію, WatchTower негайно обробить її, щоб забезпечити безпеку каналу та коштів.

Конкретне пояснення наведено нижче: для кожної простроченої обіцянки транзакції Аліси або Боба можна заздалегідь побудувати відповідну покарання транзакцію (використовуючи переривання Секретного ключа, що оброблює прострочену обіцянку транзакції, заявника як вигодоотримувача), а потім надіслати відкритий текст покарання транзакції WatchTower. Як тільки WatchTower виявить, що хтось подав прострочену обіцянку транзакції до ланцюжка, він також подасть покарання транзакції до ланцюжка для цілеспрямованого покарання.

Fiber, для захисту конфіденційності учасників каналу, дозволяє лише користувачам надсилати до WatchTower хеш «закінченої обіцянки угоди + покарання угоди Відкритий текст», тому спочатку WatchTower не знає Відкритий текст обіцяної угоди, але знає його хеш. WatchTower побачить Відкритий текст лише тоді, коли хтось дійсно подасть закінчену обіцяну угоду у блокчейн, після чого він негайно надсилає покарання угоди на ланцюг. Таким чином, крім випадку, коли хтось дійсно злочинно діє, WatchTower не буде бачити записи угод учасників каналу (навіть якщо він бачить, то лише одну угоду).

Тут ми повинні згадати про оптимізацію Fiber у порівнянні з BTCLighting Network. Вищезазначений механізм покарання, пов’язаний з відкликанням Секретного ключа, називається “LN-Penalty”, але LN-Penalty BTCLighting Network має помітні недоліки: WatchTower повинен зберігати всі застарілі хеші угод про обіцянку та відповідні відклики Секретного ключа, що створює значний обсяг зберігання.

Уже в 2018 році спільнота BTC запропонувала рішення для вищезазначеної проблеми, відоме як “eltoo”, але для його підтримки потрібна підтримка форків BTC для операційного коду SIGHASH_ANYPREVOUT. Суть полягає в тому, що після того, як прострочена обіцянка про транзакцію стане частиною ланцюжка, найновіша обіцянка про транзакцію може покарати її, тому користувачам потрібно лише зберігати найновішу обіцянку про транзакцію. Проте операційний код SIGHASH_ANYPREVOUT досі не активований, тому ця концепція не може бути реалізована.

Тим часом ** Fiber реалізував протокол Daric, змінивши дизайн скасування секретного ключа, щоб один і той же скасувальний секретний ключ відповідав кільком простроченим обіцяним угодам. Це значно зменшує обсяг зберігання для WatchTower та клієнтів користувачів.**

Система транспортних мереж: багатоскокова маршрутизація та HTLC/PTLC ****

Наприклад, у Аліси і Кена немає каналу, але є канал між Кеном і Бобом, а у Боба і Аліси є канал, Боб може виступати в ролі проміжної Нода між Алісою і Кеном, так що між Алісою і Кеном може бути передача. «Маршрут мульти-хопу» означає встановлення шляху передачі через кількох посередників. **

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

Проте тут потрібно вирішити проблему надійності посередника: як забезпечити, що він є чесним, наприклад, якщо між Алісою і Кеном є посередник Боб, Аліса зараз хоче переказати Кену 100 гривень, Боб може в будь-який момент утримати ці гроші. Для цього потрібно мати засоби, щоб запобігти поганому вчинку посередника. HTLC і PTLC використовуються для вирішення таких проблем.

Уявімо, що Аліса хоче переказати 100 одиниць Даніелеві, але між ними немає прямого каналу. Однак Аліса виявляє, що може здійснити переказ через посередників Боба та Керол. Для цього потрібно використати HTLC як канал оплати. Спочатку Аліса надсилає запит Даніелеві, після чого Даніель надсилає Алісі хеш r, але Аліса не знає відкритий текст R, що відповідає r.

Пізніше, Еліс складає умови оплати через HTLC у каналі з Бобом: Еліс готова заплатити Бобу 102 блоки, але Боб повинен назвати ключ R протягом 30 хвилин, інакше Еліс відкликає гроші. Так само Боб знову створює HTLC з Керол: Боб заплатить Керол 101 блок, але Керол повинна назвати ключ R протягом 25 хвилин, інакше Боб відкликає гроші.

Керол робить те ж саме і створює HTLC на каналі з Деніелом: Керол готова заплатити 100 юанів, але Деніел повинен повідомити їй Відкритий текст протягом 20 хвилин, інакше гроші будуть повернуті Керол.

Daniel розуміє, що ключ R, який хоче отримати Carol, насправді те, що хоче Аліса, оскільки окрім Аліси ніхто не цікавиться вмістом R. Тому Даніель підтримає Carol, розкаже їй вміст R і отримає від Carol 100 доларів, таким чином, Аліса досягає своєї мети: дати Carol 100 доларів.

Після цього легко уявити: Керол передає ключ R Бобу, отримуючи 101 долар; Боб знову передає ключ R Елісі, отримуючи 102 долари. Ми спостерігаємо за доходами та витратами всіх, і бачимо, що Еліса втрачає 102 долари, Боб і Керол заробляють чистий дохід в 1 долар, а Даніель отримує 100 доларів. Отже, 1 долар, який заробили Боб і Керол, - це комісія, яку вони взяли у Еліси.

Навіть якщо хтось зупиниться на шляху платежу вище, наприклад, Керол не повідомить нижчестоячого Боба про ключ R, це не завдасть шкоди Бобу: через певний час Боб може відкликати побудований HTLC. Те ж саме стосується і Еліс.

Проте мережа Lighting також має проблеми: шлях не повинен бути занадто довгим, якщо шлях занадто довгий, занадто багато посередників, то буде Падіння надійності платежу: деякі посередники можуть бути в автономному режимі, або ж не мати достатнього балансу для побудови конкретного HTLC (наприклад, у кожному посереднику в попередньому прикладі повинно бути щонайменше 100 доларів). Тому з кожним додатковим вузлом середнього Нода в шляху збільшується ймовірність помилки.

Крім того, HTLC може витікати приватну інформацію. Хоча цибуля маршрутизації може деяким чином захистити приватність, наприклад, шифрувати кожен крок маршруту, окрім початкового ініціатора Еліс, кожен знає лише свого безпосереднього сусіда, але не знає повного маршруту, насправді HTLC все ще легко визначити зв’язки. Ми дивимося на цей шлях з точки зору Бога: 01928374656574839201

Припустимо, що Bob та Daniel є двома Нода, які контролюються тією ж самою сутністю, і щодня вони отримують багато HTLC від різних людей. Вони помітили, що кожного разу, коли Alice та Carol надсилають HTLC, вони завжди отримують однаковий Секретний ключ, а наступник Daniel, який пов’язаний з Eve, завжди знає, що міститься в Секретний ключі R. Тому Daniel та Bob можуть вважати, що між Alice та Eve існує шлях оплати, оскільки вони завжди пов’язані з однаковими Секретний ключами, і вони можуть вивести їх відносини та почати нагляд.

Натомість, Fiber використовує PTLC, який покращує конфіденційність на основі HTLC, кожен PTLC у шляху оплати розблоковується за допомогою різних Секретний ключ, спостереження лише за Секретний ключ, потрібним до PTLC, не дозволить визначити взаємозв’язок між ними. Поєднуючи PTLC з маршрутизацією через цибулю, Fiber може стати ідеальним варіантом приватних платежів.

Крім того, традиційна мережа Lighting має сценарій “атаки циклічної заміни операцій”, який може призвести до крадіжки активів посередника в платіжному шляху. Це відкриття навіть змусило розробника Антуана Ріара покинути роботу над мережею Lighting. До цього часу в BTCLighting Network ще не було прийнято жодних фундаментальних заходів щодо вирішення цієї проблеми, що вже стало болючою темою.

Наразі офіційний CKB вдосконалився на рівні пулу транзакцій, щоб вирішити вищезазначені атаки за допомогою Fiber. Оскільки альтернативні атаки на цикл транзакцій та їх рішення можуть бути досить складними, цей текст не намагається давати пояснення на цю тему, але ви можете прочитати статті BTCStudy та відповідну інформацію від офіційного CKB, якщо вас цікавить.

Загалом, незалежно від приватності чи безпеки, Fiber вдосконалився значно більше, ніж традиційна мережа Lighting.

Крос-ланцюжкові атомні платежі між Fiber та BTCLighting Network

З використанням HTLC та PTLC, Fiber може здійснювати транскордонні платежі з BTCLighting Network, забезпечуючи ‘атомарність транскордонної дії’, тобто всі етапи транскордонної операції або успішні, або невдачні, і не можуть бути частково успішними або частково невдалими.

Після забезпечення міжланцюгової атомарності можна гарантувати відсутність збитків від перетину межі ланцюгів, що дозволяє Fiber і BTCLighting Network зв’язатися між собою, наприклад, можна створити шлях платежів у гібридній мережі, що складається з Fiber та Lighting Network, і безпосередньо переводити кошти з Fiber на користувачів у BTCLighting Network (приймальником є тільки BTC), а також обмінювати активи CKB та RGB++ на еквівалентний BTC в BTCLighting Network через Fiber.

Ми коротко пояснимо принцип: припустимо, що Аліса працює як вузол в мережі Fiber, а Боб працює як вузол в мережі BTCLighting Network. Аліса хоче переказати гроші Бобу, і вона може зробити це за допомогою посередника Ingrid, який працює в обох мережах - Fiber та BTCLighting Network, і виступає як посередник у шляху переказу.

Якщо Боб хоче отримати 1 BTC, Еліс може домовитися з Інгрід про обмінний курс, наприклад, обміняти 1 CKB на 1 BTC. Еліс може відправити Інгрід 1,1 CKB в Fiber, після чого Інгрід може відправити 1 BTC Бобу в мережі BTCLighting, залишивши 0,1 CKB як комісію.

Конкретний спосіб дії тут насправді полягає в установленні шляху оплати між Еліс та Бобом через Інгрід, тобто Еліс—>Інгрід—>Боб, а потім використовуватиметься HTLC. Схоже, що раніше вже говорилося про те, що Боб, щоб отримати гроші, повинен розповісти Інгрід вміст ключа R. Як тільки Інгрід отримає ключ R, вона зможе розблокувати гроші, які Еліс заблокувала в HTLC.

Важливо зауважити, що ці дві транзакції, які відбуваються в BTCLighting Network та Fiber, є атомарними міжланковими операціями, що означає, що або обидва HTLC розблоковані, і перекриття платежів успішно виконуються, або ж жоден з них не розблоковано, і перекриття платежів невдаються, тому Боб не отримає грошей від Еліс.

(Фактично, посередник Ingrid може не розблоковувати HTLC для Alice після того, як знає ключ R, але це завдасть шкоди саме посереднику Ingrid, а не користувачеві Alice, тому дизайн Fiber є безпечним для користувача)

Цей метод не потребує довіри до третьої сторони, щоб здійснювати операції з переказу між різними P2P мережами, майже не потребує жодних змін.

Інші переваги Fiber порівняно з BTCLighting Network

Раніше ми зазначили, що Fiber підтримує місцеві активи CKB, а також активи RGB++ (особливо стабільні монети), що робить його дуже потужним в миттєвих платіжних сценаріях, що більш підходить для щоденних потреб у невеликих платежах.

Крім того, у BTCLighting Network є одна основна проблема управління Ліквідність. Можливо, ви пам’ятаєте, що ми на початку сказали, що загальний залишок в платіжному каналі є фіксованим, якщо залишок однієї зі сторін вичерпається, вона не може переказувати гроші іншій стороні, якщо тільки інша сторона не перекаже їй гроші, тоді потрібно знову внести гроші або відкрити новий канал.

Крім того, якщо в складній мережі з багатьма переходами деякі проміжні Нода мають недостатньо коштів для здійснення зовнішніх платежів, це може призвести до невдачі всього шляху платежу. Це одна з проблем Lighting Network, розв’язанням якої є ніщо інше, як надання ефективних схем впровадження Ліквідності, щоб забезпечити можливість внесення коштів в більшості Нода в будь-який час.

Проте, у BTCLighting Network процеси впровадження Ліквідності, відкриття та закриття каналів відбуваються на ланцюгу BTC. Якщо комісії у мережі BTC надто високі, це негативно вплине на користувацький досвід платіжних каналів. Наприклад, якщо ви хочете відкрити канал на суму 100 доларів, а операція відкриття каналу коштує 10 доларів комісії, то на початковому етапі ви витратите 10% своїх коштів на відкриття каналу, що є неприйнятним для більшості людей; те саме стосується впровадження Ліквідності.

Fiber має значну перевагу в цьому відношенні. По-перше, TPS CKB набагато вище, ніж у BTC, комісія може бути на рівні центів; по-друге, для вирішення проблеми недостатньої Ліквідність, Fiber планує співпрацювати з Mercury layer для впровадження нового рішення, щоб внесення Ліквідність могло уникнути операцій у блокчейні, вирішуючи проблеми UX та вартості.

До цього моменту ми систематично узагальнили загальну технічну архітектуру Fiber, яка в порівнянні з BTCLighting Network можна побачити на зазначеній вище діаграмі. Оскільки Fiber і Lighting Network включають в себе багато різних знань та аспектів, є ймовірність, що одна стаття не охопить все, тому ми плануємо випускати серію статей на тему Lighting Network і Fiber, слідкуйте за новинами.