Експертна оцінка вразливості у Lightning Network

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

Отже, спочатку спробуємо розібратися у самій вразливості. Коли платіж Lightning маршрутизується через мережу, важливо розуміти, як працюють часові блокування для повернення коштів за невдалий платіж. Вузол, найближчий до одержувача, має часове блокування «x», а кожен вузол на шляху повернення до відправника має один з «x+1», «x+2» і т.д. Часові блокування поступово стають довшими, коли ви проходите кожен вузол від отримувача назад до відправника. Причина цього в тому, що якщо платіж доходить до одержувача, але якась проблема перешкоджає поширенню прообразу назад до відправника, вузол, на якому він зупинився, має час примусово застосувати його в ланцюжку і помістити туди прообраз, з необхідністю підтвердження платежу всіма попередніми вузлами. В іншому випадку хтось посередині, де відбувається збій, може вимагати, щоб їхній вихідний вузол запросив кошти за допомогою прообразу, а вузол, який переслав їм їх, запросити їх за допомогою свого шляху повернення, залишивши цю людину, якій не пощастило, з втраченими засобами.

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

Атака вимагає дуже цілеспрямованих та складних дій щодо маніпулювання мемпулом жертви. Розгляньмо фактичну структуру транзакції. У вас є основна транзакція, яка відображає стан каналу Lightning. Вона має вихідні дані для кожної сторони каналу, які представляють кошти, які повністю знаходяться під контролем того чи іншого учасника, а також вихідні дані для кожного HTLC, які знаходиться в процесі маршрутизації. Саме ці результати нас цікавлять. Кожен вивід HTLC можна витратити або відразу в будь-який момент разом з прообразом від приймача або після закінчення блокування на відшкодування.

Для здійснення атаки необхідно, щоб зловмисник або дві сторони, які змовилися, мали канал по обидві сторони від вузла жертви, що направляє платіж. Таким чином, у Боба, жертви, є канал з Еліс і Керол, зловмисниками, і платіж направляється від Керол до Боба та Еліс. Пам'ятайте, що термін дії часового блокування між Еліс та Бобом закінчиться та стане чинним до моменту повернення коштів між Керол та Бобом.

Зловмисники направляють платіж через Боба, і тоді Еліс відмовляється надіслати Бобу прообраз для завершення платежу, коли вона його отримає. Тепер Боб чекатиме, поки закінчиться час часового блокування між ним та Еліс, і перейде до трансляції транзакції фіксації каналу та транзакції повернення, щоб отримати її підтвердження до закінчення терміну часового блокування. Потім Еліс витратить транзакцію прообразу, щоб запросити кошти з виходом, не пов'язаним з каналом, і відразу після цього двічі витратить другий вхід успішної транзакції прообразу. Мета тут – унеможливити появу timeout-транзакції Боба в мемпулі, а також виключити успішну транзакцію прообразу, щоб Боб її не побачив. Якщо він її побачить, він дізнається прообраз і зможе просто запросити кошти у своєму каналі з Керол до того, як її timeout-транзакція стане дійсною для витрачання.

Еліс і Керол доведеться робити це постійно, щоразу, коли Боб ретранслюватиме свою timeout-транзакцію Еліс, поки висота блоку не досягне рівня, за якого timeout-транзакція Керол дійсна. Потім вони можуть надіслати успішну транзакцію на стороні Еліс і timeout-транзакцію на стороні Керол, і залишити Боба без вартості платежу, який він спрямував.

Проблема тут подвійна. По-перше, повинно бути спеціальне таргетування вузла Bitcoin Core жертви, щоб гарантувати, що успішна транзакція прообразу ніколи не пошириться на мемпул, де вузол Lightning зможе отримати прообраз. По-друге, якщо друга транзакція, яку Еліс використовує для виключення транзакції прообразу, підтверджується, Еліс понесе витрати (пам'ятайте, ідея полягає в тому, щоб замінити транзакцію тайм-ауту прообразом, щоб вона була виключена з мемпула, а потім замінити транзакцію прообразу, двічі витрачаючи додаткові дані в транзакції прообразу). Це означає, що кожного разу, коли Боб повторно транслює свою транзакцію тайм-ауту, Еліс доводиться платити вищу комісію за її повторне витіснення, і коли це підтверджується, вона фактично несе витрати.

Таким чином, Боб може змусити Еліс понести великі витрати, просто регулярно ретранслюючи свою транзакцію тайм-ауту з вищою комісією, а це означає, що якщо платежний вихід HTLC не коштує значно більше, ніж комісії, які може понести Еліс, атаку економічно недоцільно проводити. Також можна було повністю запобігти атаці, змінивши спосіб побудови HTLC-транзакцій успіху та тайм-ауту. Використання SIGHASH_ALL означає, що підпис фіксує всю транзакцію і стає недійсним, якщо змінюється найменша деталь (наприклад, додавання нових вхідних даних у транзакцію прообразу, необхідну для цієї атаки). Це не спрацює в поточній версії каналів Lightning, які використовують якірні виходи, але розв'яже проблему. Пітер Тодд також запропонував нову функцію консенсусу, яка повністю проблемі: по суті, це зворотний таймлок, коли транзакція стає недійсною через певний час або висоту блоку, а не стає дійсною після цього. Проте, як на мене, заходити так далеко не обов'язково.

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

Загалом це проблема, яка цілком заслуговує на увагу, але її можна вирішити як з точки зору наявності прямих заходів для пом'якшення наслідків, так і того, як на проведенні атак відобразиться поява інших рішень у довгостроковій перспективі. Відкидати цю проблему як простий FUD – неправильна реакція, але стверджувати, що це кінець та мережа Lightning як протокол приречена – це сильне перебільшення.

Час іде, ми стикаємося з проблемами, і ми будемо розв'язувати ці проблеми в міру їхнього надходження. Як і завжди.