Lightning Routing

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

Gossip — спосіб поширення інформації між вузлами. BOLT #7 описує оголошення каналів і напрямлені оновлення: базову та пропорційну комісію, різницю строків CLTV, мінімальну й максимальну суми та ознаку доступності. Оголошені умови не доводять, що сусідній вузол зараз онлайн або має достатньо коштів. Тут CLTV означає строк, заданий висотою блоку Bitcoin, тобто його порядковим номером у ланцюжку, а не точною годиною. Різниця між строками дає посередникові час відреагувати, якщо передавання платежу зупиниться. [2]

Загальна місткість каналу не показує, скільки зараз може відправити кожна сторона. Відправник знає власні канали, а для інших використовує оцінки та історію успіхів і невдач. Програма враховує і комісію, і ймовірність проходження. Інший платіж тим часом може змінити ліквідність — кошти, які можна відправити в потрібному напрямку. [4] [5]

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

Onion routing за BOLT #4 використовує конструкцію Sphinx: кожен крок отримує окремо зашифровані інструкції. Посередник знає попереднього й наступного партнера та власні вказівки. Сам пакет не відкриває весь маршрут, його довжину або точну позицію вузла. Аналіз трафіку чи співпраця вузлів усе ж можуть послабити приватність. [1]

Канал може тимчасово відмовити, комісія бути замалою, CLTV неправильним, а наступний партнер недоступним або невідомим. Відправник отримує лише обмежені відомості про помилку. Його програма може знизити оцінку маршруту, перерахувати його й повторити платіж. Це не грошовий штраф вузлу, а один результат не є постійною оцінкою надійності. [1] [4]

Самих з’єднань недостатньо: кожен крок має прийняти HTLC і мати достатньо доступних коштів у потрібному напрямку. Частину балансу може бути відкладено в резерв або заблоковано в незавершених платежах. Технічні поля htlc_minimum_msat і htlc_maximum_msat також задають нижню та верхню межі суми одного HTLC у цьому напрямку. Одиниця msat — це тисячна частина сатоші; сатоші є найменшою одиницею суми в ланцюжку Bitcoin. Навіть висока оголошена межа не доводить, що потрібна ліквідність доступна саме зараз. Тому один непридатний канал може зупинити весь маршрут. [2]

Якщо одержувач підтримує basic MPP, тобто платіж, поділений на кілька частин, відправник може розділити загальну суму, позначену в протоколі як total_msat, між кількома маршрутами. Одержувач чекає на потрібні частини й завершує їх разом. Це використовує ліквідність у різних каналах, але MPP не створює нової. Додаються HTLC, спроби та, можливо, комісії. [1]

Route hints у BOLT #11 можуть дати відправнику відомості про останні неоголошені кроки. Route blinding, використаний у BOLT #12, натомість надає зашифрований кінець шляху через вхідний вузол — introduction point. Відправник усе одно має знайти придатний шлях до нього й виконати сукупні умови комісій і CLTV. Краща приватність не гарантує доставки. [3] [6] [1]

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