Ліквідність Lightning

Анна й Павло мають канал місткістю 1 000 000 sat — мільйон сатоші, найменших одиниць у ланцюжку Bitcoin. Уявімо спрощений стан: Анні належать 800 000 sat, Павлу — 200 000 sat. Для наочності поки не враховуватимемо резерви, комісії та незавершені платежі. Анна надсилає гроші Павлу зі свого боку, а отримує від нього з його боку. Тож Павло не може надіслати їй цим каналом 300 000 sat, хоча загальна місткість становить мільйон. Гроші не зникли. Просто їхній розподіл не дозволяє провести цей платіж. [1] [3]

Вихідна ліквідність — це сума, доступна для платежу від тебе. У прикладі вона спирається на баланс Анни у 800 000 sat, але реальний максимум зазвичай нижчий через резерви, комісії та незавершені платежі. Коли Анна платить не Павлу, перший крок усе одно проходить одним із її каналів. Вузол — це програма, яка керує каналами й обробляє платежі Lightning. Наступним вузлам потрібні власні кошти для подальших кроків. Bitcoin поза каналами не збільшує її вихідну ліквідність автоматично: гаманець має відповідним способом перенести цю вартість у Lightning. [1] [3]

Вхідна ліквідність — це сума, яку інший учасник може надіслати тобі. Якщо Анна відкриває канал і майже всі кошти належать їй, надсилати зручно, а можливостей для отримання мало. Новий запит на оплату цього розподілу не змінює. Потрібен канал, де інша сторона має доступний баланс. Деякі гаманці забезпечують це через постачальника послуг, приховуючи складність від користувача, часто за плату. Вхідна місткість не є додатковими грошима Анни: це можливість отримати майбутній платіж. [1] [3] [5]

Тепер Анна платить Павлу 100 000 sat. У нашому спрощеному прикладі баланси стають 700 000 sat в Анни та 300 000 sat у Павла. Місткість залишається 1 000 000 sat. Анна може менше надіслати, зате більше отримати назад; у Павла навпаки. Якщо гаманець має кілька каналів, змінюються ті, якими платіж справді скористався. Отже, напрямок завжди важливий. Ранковий показник ліквідності не обов’язково відповідає тому, що можна надіслати ввечері. [1] [3]

Платіж віддаленому одержувачу проходить послідовністю каналів. Кожен потребує достатньої доступної ліквідності у правильному напрямку, зокрема сум для комісій наступних кроків. Якщо один крок неможливий, цей маршрут не спрацює навіть за великої місткості решти каналів. Гаманець може спробувати інший маршрут або розділити платіж на кілька частин, якщо це підтримується. Однак відсутніх коштів це не створює. Важлива не лише сума, а й строки. HTLC — умовний платіж, який можна завершити, довівши знання певного секретного значення. Правила, пов’язані з CLTV, задають строки в блоках; проміжки між ними дають посередникам час розрахуватися в ланцюжку Bitcoin, якщо передавання платежу зупиниться. [1] [2]

Посередник має отримати платіж одним каналом і надіслати пов’язаний платіж іншим. Великої суми всіх балансів замало. Якщо його кошти лежать на його боці невідповідного каналу, використати їх для обраного маршруту може бути неможливо. Для отримання потрібна вхідна ліквідність у першому каналі, для передачі — вихідна у другому. Ці кроки пов’язують умови HTLC: завершення платежів залежить від знання певного секрету та часових правил. Тому посередник не покладається лише на обіцянку, що попередній учасник заплатить пізніше. [1] [3]

Отримані й надіслані платежі природно змінюють ліквідність. Оператор кількох каналів також може виконати кругове ребалансування: надіслати платіж одним шляхом і отримати його назад іншим, перемістивши баланси між власними каналами. Swap обмінює кошти в ланцюжку на кошти в Lightning або навпаки. Splicing дозволяє змінити фінансування сумісного каналу без звичайного закриття й повторного відкриття. Ще один варіант — відкрити інший канал. Ці способи різняться комісіями, часом, слідом у ланцюжку, вимогами до довіри та ризиком невдачі. Жоден не створює грошей: обирай залежно від того, чи потрібно надсилати, отримувати чи і те, й інше. [1] [4]

Спочатку визнач, чи проблема стосується надсилання або отримання, і чи перебувають гаманець та інший вузол онлайн. На власному вузлі порівняй локальний і віддалений баланси кожного каналу, резерви, незавершені платежі та комісії. У гаманці під управлінням сервісу з’ясуй, що саме означає показана доступна сума. Невдалий платіж сам по собі не доводить втрати грошей: на якомусь кроці може бракувати ліквідності, діяти ліміт або статися тимчасовий збій. Менший пробний платіж перевіряє лише конкретну суму в конкретний момент, а не гарантує проходження всіх наступних платежів. [1] [3] [4]

Операторам вузлів потрібно розрізняти кілька обмежень. Вихід транзакції визначає суму та умови її витрачання. channel_reserve_satoshis позначає кошти, які мають залишатися в резерві. Частина може бути зв’язана в незавершених HTLC — умовних платежах, які ще очікують завершення. Наведені далі обмеження стосуються HTLC, які пропонує інший учасник. max_htlc_value_in_flight_msat обмежує їхню загальну вартість, а max_accepted_htlcs — кількість; msat — тисячна частина сатоші для розрахунків усередині Lightning. Залежно від типу каналу враховуються також комісії commitment transaction, транзакції для його закриття, і можливі anchor outputs — спеціальні виходи, які дозволяють додати наступну транзакцію й підвищити комісію за підтвердження всього пакета. Правила Dust визначають, які виходи замалі для включення до цієї транзакції. Тому точний доступний максимум розраховуй для конкретної реалізації та типу каналу, а не віднімай один універсальний резерв. [1] [6]

BOLT #7 описує оголошення каналів і правила передачі платежів. Для оголошеного каналу можна знайти в ланцюжку вихід фінансування та його місткість. Але це не розкриває поточного розподілу між учасниками. Відправник обирає маршрут за власною інформацією, попередніми результатами та спробами платежу, а не за повним публічним списком поточних балансів. Тому оглядач мережі може показати великий канал, але не підтвердити, що саме зараз твоя сума пройде ним у потрібному напрямку. [2]