Inbound Liquidity

Петр керує кав’ярнею та приймає платежі в Lightning Network. Його вузол, програма для обробки платежів, показує кошти, але клієнт не може заплатити. Причиною може бути нестача вхідної ліквідності. Платіжний канал — це домовленість між вузлами про розподіл внесених біткоїнів. Частка Петра називається local balance, частка партнера — remote balance. Під час приймання частина вартості переходить від партнера до Петра. Для цього на боці партнера мають бути кошти. Remote balance і далі належить партнеру: придбати можливість приймати платежі не означає отримати біткоїни в подарунок чи вже зароблену виручку. [1] [6]

Уявімо канал місткістю 1000000 sat. Sat — скорочення від satoshi, малої одиниці біткоїна. Петр має local balance 800000 sat, партнер — remote balance 200000 sat. Отже, загальний запас для приймання становить 200000 sat. Якщо Петр прийме 100000 sat, його частка зросте до 900000 sat, а партнеру залишиться 100000 sat. Петр отримав гроші, але запас для наступних надходжень зменшився. Для наочності приклад не враховує резерви, комісії та незавершені платежі HTLC, пояснені нижче. Якщо Петр сам фінансує новий канал без початкового переказу партнеру, він насамперед отримує можливість надсилати. Підтвердження відкриття каналу не змінює цього напрямку. [1] [2]

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

Коли Петр платить постачальнику через Lightning, local balance використаних каналів зменшується, а remote balance зростає. Так може з’явитися місце для майбутніх надходжень. Подібно працює Loop Out: через swap, обмін між платіжними шарами, Петр надсилає вартість із Lightning і отримує біткоїн на адресі в блокчейні. Закривати канали не потрібно. Loop In діє навпаки: перетворює кошти в блокчейні на доступний для витрат залишок у Lightning. Нових біткоїнів це не створює. Порівнюючи результат, слід врахувати комісії маршрутизації, сервісу обміну й транзакції в блокчейні, а також перевірити завершення операції. [1] [4]

Партнер може профінансувати канал до Петра. Той отримає вхідний запас, але не гроші партнера в подарунок. Документація Lightning Pool описує ринок таких угод: bid — запит на ліквідність, ask — пропозиція її надати. Оренда має строк у блоках, передбачає премію та інші комісії. Блок — група транзакцій, додана до блокчейну, публічної історії транзакцій Bitcoin. Тому строк залежить від появи нових блоків, а не від точної кількості годин. Це не купівля всього віддаленого залишку. Узгоджений строк також не означає, що весь час буде доступна та сама сума: платежі змінюють розподіл коштів. Після завершення угоди не можна розраховувати на постійну доступність каналу. [1] [5]

Петр може мати кілька каналів і потребувати вхідного запасу в іншого партнера. Circular rebalancing, кругове балансування, надсилає його платіж у мережу через один канал і повертає через інший власний. Канал відправлення отримує вхідний запас, а канал приймання його витрачає. Кошти переходять між Петровими сторонами каналів, нового капіталу не виникає, а маршрутизація коштує комісій. Потрібен працездатний шлях. Якщо на віддалених сторонах усіх каналів немає коштів, повернути платіж нізвідки. Саме кругове балансування цього не виправить. [1]

Частина коштів має залишатися резервом для безпечної роботи каналу. Інші кошти можуть тимчасово бути залучені в HTLC, умовні платіжні зобов’язання. Одержувач може забрати їх, розкривши секретне значення, з якого обчислюється погоджений платіжний хеш — значення для перевірки. Якщо платіж не вдається, сторона, що його надіслала, має змогу повернути кошти після спливу строку. BOLT 2, специфікація керування каналами, обмежує також мінімальну суму, кількість одночасних HTLC і їхню загальну вартість. Тому весь remote balance може бути недоступний для нового платежу. Недостатньо скласти віддалені залишки й відняти універсальний резерв: важливі конкретні канали та їхній стан. [2]

Зазвичай платіж проходить кілька вузлів. Навіть якщо Петр має запас для приймання, попередня ділянка може бути недоступною або не мати коштів. BOLT 7 описує повідомлення channel_update, якими вузли оголошують умови маршрутизації для певного напрямку каналу. Вони містять комісії та htlc_maximum_msat — верхню межу окремого умовного платежу в msat, тисячних частках satoshi. Це не обіцянка поточного залишку на всьому шляху. Тому сума вхідного запасу Петра не гарантує приймання такої суми від будь-якого конкретного відправника. Ліквідність одержувача — необхідна частина рішення, але не єдина. [3]