Lighting NetworkЛіквідність управління плануванням науки

Автор: RGB++ Fans; Джерело: ByteDance CKB

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

Ми зазначаємо, що для здійснення переказу в мережі Lighting Network, часто потрібно проходити через кілька посередник Нода для побудови шляху, а доступні кошти на проміжній Нода, як правило, обмежені, що в кінцевому підсумку впливає на успішність оплати. Для забезпечення достатньої ліквідності на Нодах у шляху та покращення користувацького досвіду, необхідно використовувати деякі схеми управління Ліквідністью. Але для глибокого розуміння питань управління Ліквідністью, спочатку потрібно ввести декілька основних понять, таких як локальний та віддалений баланс (Local and Remote Balance), вхідна та вихідна місткість (Inbound and Outbound Capacity) тощо.

У минулому ми вже згадували, що основними складовими одиницями Lightning Network є нода і канал, останній є засобом переказу 1 до 1, побудованим на базі мережі Біткойн поза блокчейном. Під час ініціалізації каналу обидві сторони переказують певну кількість грошей як початковий баланс. ** Баланс на вашому боці називається «локальний баланс», а баланс на боці вашого партнера - «віддалений баланс». ** Локальний баланс визначає, скільки грошей ви можете переказати вашому партнеру і обмежує вашу здатність до сплати, тобто «вихідну ємність», а віддалений баланс визначає, скільки грошей ваш партнер може переказати вам і обмежує вашу «вхідну ємність», тобто здатність отримувати платежі.

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

(Це зображення показує ваш баланс та баланс Роберта, ваш локальний баланс - 5, віддалений баланс - 3, загальна ємність каналу - 8)

Після розуміння кількох основних концепцій вище ми знову переглянемо, яким чином управління Ліквідністю в мережі Lighting Network вирішує проблему. На спрощеній діаграмі зв’язку мереж Нода нижче ми можемо побачити, що ви (у лівому нижньому куті) з’єднані лише з однією Нода LNTop, оскільки ваш баланс віддаленої сторони становить 3, ви можете отримати тільки перекази на суму не більше 3 доларів США. Якщо Sophie хоче надіслати вам 1 долар, операція провалиться через недостатність доступного балансу Нода за LNTop (червоний прямокутник, вихідний обсяг цієї Нода до LNTop дорівнює 0).

Можна сказати, що обсяг каналу - одна з серйозних проблем, з якими стикається Lighting Network на початковому етапі. Якщо Ліквідність буде більш рівномірно розподілена по всій мережі, такі проблеми ефективно зменшаться, і це може бути вирішено за допомогою так званого “Управління Ліквідністю”, наприклад, через ринок оренди (Lighting Pool), щоб клієнти могли підключатися до декількох Нода з достатньою Ліквідністю, відкривати / закривати нові канали за потреби, або використовувати методи, які включають з’єднання каналів та балансування (Channel Rebalancing) для регулювання балансу в каналі у блокчейні чи поза блокчейном.

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

Нижче ми докладніше розглянемо типові підходи до управління Ліквідністью в Lighting Network. Спочатку давайте розберемо оренду каналу, ця схема в основному вирішує проблему “вхідного обсягу” Ноди, **тобто коли інші люди хочуть переказати вам кошти, вам потрібно забезпечити успішне створення шляху платежу для вашого партнера, для цього потрібно встановити вимоги для кожної Ноди в шляху, наприклад, достатньої оборотної здатності / вихідного обсягу. Як ми вже зазначали раніше, причина невдачі шляху полягає в недостатній Ліквідності в каналах, які встановлені деякими проміжними Нодами з іншими Нодами.

Побудова каналу має свою ціну, оскільки учасникам часто доводиться блокувати частину коштів, несучи альтернативні витрати. Ідея так званого канального лізингу полягає в тому, щоб дозволити операторам Нода безпосередньо торгувати ринковими засобами, а надлишкові кошти Ноди взяти на себе ініціативу щодо побудови каналів для інших Нода через систему «лізингу». **Наприклад, якщо ви мерчант, якому потрібно отримувати гроші від інших людей у будь-який час, у вас високий попит на ліміт, і ваша «колекторська здатність» за день має перевищувати 200 BTC.

Таким чином ви уклали протокол з Lighting Pool та 4 великими Нода, що мають протоколи, з якими ви уклали договір. Ці 4 Нода створили канали з вами на 24 години, кожен з яких заблокував по 50 BTC і надав вам віддалену балансу на 50 BTC. Таким чином, в кожному каналі ви можете отримати до 50 BTC. Якщо хтось переказує вам кошти, то ви можете використовувати будь-яке з цих 4 Нод як посередника для створення шляху оплати.

(На 1ml.com ми можемо побачити кілька відомих операторів мережі Lighting Network, ці Нода мають достатньо коштів та встановили багато каналів з іншими Нода, щоб отримувати дохід через оренду Ліквідність)

Крім зазначеного вище пулу оренди, також існує Ліквідність广告（Liquidity Advertisement）, Нода, що надає ліквідність, може використовувати громадські повідомлення gossip від швидкодії для оголошення своєї ціни та тривалості каналу, інша Нода, що приймає ціну, може відкрити канал з нею. Такі системи на основі оренди завжди поєднуються з Маржа системою, щоб запобігти раптовому порушенню угоди.

**Наразі розробники мережі Lighting, такі як Lighting Labs, та Fiber, намагаються оптимізувати сценарії оренди Ліквідності для одностороннього фінансування. Наприклад, Fiber планує внести Ліквідність代付 систему на основі функцій смарт-контрактів CKB, де вказані постачальники LSP Нода будуть створювати канали для користувачів та протягом певного часу надавати безкоштовний обсяг вхідних коштів для задоволення їхніх потреб у отриманні коштів. Як тільки користувач отримає певну суму коштів, контракт автоматично вилучить витрати, та також розглядається механізм Ліквідності стейкінгу, пов’язаний з такими сценаріями.

Загалом, оренда каналу часто використовується для вирішення проблем, пов’язаних з встановленням зв’язку між Нодами, отриманням ліквідності та наступним сплайсінгом (Splicing) каналу, який буде фінансуватися / виводитися через дії в блокчейні, прямо змінюючи загальний баланс сторін у каналі. Зазвичай для відкриття та закриття каналу використовується підпис 2/2, здійснюється повторне розподіл спільних активів у блокчейні між сторонами, але в ранньому варіанті протоколу Lighting Network, якщо канал відкритий, то, крім як його закрити та перезапустити, неможливо змінити загальний баланс у каналі.

А відновлення каналу - це нове запропоноване рішення, яке дозволяє не закривати існуючий канал; за участю сторін спільний UTXO з каналу може бути переструктурований і оновлений безпосередньо в у блокчейні, наприклад, додавання нових активів на основі існуючих активів для спільного контролю сторін, що змінює загальний баланс каналу. На приведеному внизу малюнку коротко описана ця ідея: зліва зображені активи у блокчейні, що відповідають старому каналу (UTXO1), які контролюються Алісою та Бобом за допомогою підписування обох сторін; після цього сторони починають відновлення каналу, додаючи інший актив (UTXO2) для спільного управління, в результаті чого загальний обсяг активів (UTXO3), що можуть бути спільно контрольовані сторонами каналу, збільшується, а його потужність зростає.

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

Після того, як ми розглянули з’єднання каналів, ми продовжуємо ознайомлюватися з ідеєю перебалансування каналів (Channel Rebalancing), яка є засобом регулювання балансу у різних каналах без закриття або зміни загального обсягу каналу (за винятком комісій). Припустимо, що ви запустили клієнт Lightning Network і встановили три платіжних канали з іншими Нодами:

• Канал 1: встановлено з’єднання з вузлом X, загальна місткість - 1 BTC
• Канал 2: встановлено з Нода Y, загальна місткість - 0.5 BTC
• Канал 3: встановлено з Нода Z, загальна потужність - 0,5 BTC

Розподіл коштів у кожному каналі наступний:

• Канал 1: ваш локальний баланс: 0,9 BTC віддалений баланс: 0,1 BTC
• Канал 2: Ваш локальний баланс: 0.1 BTC Віддалений баланс: 0.4 BTC
• Канал 3: ваш локальний баланс: 0.1 BTC віддалений баланс: 0.4 BTC

Зараз проблема в тому, що у вас недостатньо вихідного обсягу в каналах 2 та 3, ви можете переказати максимум 0.1 BTC противнику, не забезпечуючи потреби великих переказів. Тим часом обсяг вихідних коштів в каналі 1 занадто великий - 0.9 BTC, а вам цього навіть на короткий термін не потрібно. Очевидно, найкраще вирішення - перемістити зайві кошти з каналу 1 в інші канали. Таким чином, ви плануєте перевести 0.4 BTC з локального балансу каналу 1 в канал 2 та 0.4 BTC в канал 3. Щоб досягти цього результату, вам потрібно здійснити дві операції циркулярного платежу.

Конкретний спосіб дії, як показано на рисунку вище, ви можете безпосередньо перевести 0,8 BTC на вузол X, який потім переводить по 0,4 BTC кожен до Y та Z, а потім Y та Z окремо перекладають по 0,4 BTC на вашу адресу в каналі 2 та каналі 3, збільшуючи ваш локальний баланс, таким чином ви матимете достатньо коштів для майбутніх великих переказів.

Спостерігаючи зображення вище, легко помітити, що сутність обходного платежу полягає в тому, що ви переказуєте гроші самому собі, переміщаючи свої залишки по різних каналах, щоб у кінцевому результаті вони розподілилися так, як ви очікуєте, але цей метод сам по собі не може додати гроші до загального залишку будь-якого каналу з повітряної кулі, крім того, його впровадження потребує певних умов: X має достатньо коштів для переказу Y, Z, іншими словами, для обходного платежу часто потрібно, щоб відповідні Нода мали певний резерв Ліквідності заздалегідь.

Маршрутна оплата - це один з способів реалізації ідеї збалансування каналів, причому схему збалансування можна поєднати з іншими методами, такими як підводні обміни тощо. Давайте розглянемо підводні обміни (Submarine Swaps), які є важливою ідеєю цієї схеми, де за допомогою методів HTLC тощо здійснюється обмін коштів між у блокчейні та поза блокчейном без закриття каналу.

найпростіша сцена обміну підводного човна в у блокчейні полягає в тому, що Alice депозитна укладається в каналі, припустимо, що Alice вже встановила канал 1 до 1 з Bob, але після певного часу локальний баланс Alice майже вичерпано, і вона не може більше здійснювати виплати. На цьому етапі Alice потрібно внести більше коштів, щоб закрити канал та перезапустити його, але цей канал орендований, і раннє закриття не є доцільним. Що робити?

Якщо обмін здійснюється через підводний човен, процес буде досить простим, але потрібна допомога HTLC. Спочатку Еліс може згенерувати випадкове число R і взяти хеш від нього H®. Потім Еліс може надіслати BTC на адресу Боба у блокчейні, заблоковану за умов ХТЛС. Боб повинен розблокувати ці BTC у блокчейні, знаючи прообраз R, який відповідає H®.

Bob взаємодіє з Alice через канал поза блокчейном, використовуючи HTLC, але в зворотньому напрямку: спочатку Alice повинна представити значення R, щоб розблокувати гроші, які заплатив Bob. Як тільки Alice представляє значення R, Bob може використати його для розблокування BTC, які заблоковані на у блокчейні. Після цього локальний баланс Alice в каналі збільшується, а активний баланс на у блокчейні зменшується пропорційно (якщо не брати до уваги комісію). Фактично, це взаємозамінний обмін в пропорції 1:1 (для зручності пояснення принципу, тут не суворо дотримуються звичайного порядку дій при обміні підводної лодки, на практиці часто одна сторона спочатку створює HTLC поза блокчейном, а потім інша сторона створює симетричний HTLC на у блокчейні).

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

Але слід мати на увазі, що в зазначеному вище сценарії, хоча ваш основний капітал не буде викрадений, але одна сторона повинна заблокувати кошти у блокчейні за допомогою HTLC, що, безперечно, призведе до зношення комісій. Якщо ваш партнер не виконає свої обіцянки, це обов’язково вплине на вас. Для вирішення цих проблем часто використовуються додаткові засоби, такі як аванс, система репутації та інші засоби покарання у сфері тендерних обмінів.

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

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