Вчимося на помилці LND, яка могла пограбувати Lightning Network

9 жовтня 2022 року Бурак з Bitmatrix (інструмент обміну на основі Liquid Network) створив і транслював транзакцію в основну мережу Біткоїна, витративши UTXO з мультипідписом Tapscript з порогом 998 з 999. Ця транзакція розміром майже 0,1 МБ мала 998 індивідуальних підписів у полі свідка, і, як не дивно, повторно використовувала один і той самий відкритий ключ для кожного з 999 учасників мультипідпису. Ця транзакція викликала масовий збій у мережі Lightning, виявивши помилку в LND та btcd (альтернативний клієнт для мережі Біткоїна).

Єдина мета здійснення цієї транзакції полягала в тому, щоб продемонструвати покращену масштабованість скриптів з мультипідписом, які підтримує Taproot. Навіть без використання протоколів MuSig, які базуються на підписі Шнорра, Taproot може підтримувати набагато більшу кількість учасників з мультипідписом, ніж попередні версії Bitcoin Script. Тут можна згадати багато нюансів щодо попереднього обмеження розміру для мультипідпису, якщо заглибитися у всі можливі способи створення мультипідпису за допомогою Біткоїн-скрипта, тому для простоти я збираюся просто обговорити попередні обмеження, що застосовуються до багатопідписних конструкцій Pay-to-script-hash (P2SH) та Pay-to-witness-script-hash (P2WSH). Коли йдеться про стандартний спосіб виконання мультипідпису P2SH, максимальна кількість учасників складає всього 15, а у випадку стандартного мультипідпису P2WSH допустимий максимум становить 20. Ці обмеження пов'язані з тим, наскільки великий сценарій можна використовувати за допомогою цих різних операцій, а також обмеженнями кількості операцій обробки, дозволених для виконання в рамках одного сценарію. Порушення будь-якого з цих обмежень робить транзакцію недійсною.

З впровадженням Taproot ці обмеження на розмір скрипта були повністю зняті, а це означає, що єдиними обмеженнями на розмір скрипту Taproot є самі обмеження на розмір блоку. Ось де виникає проблема з LND та btcd. Правила консенсусу, реалізовані в btcd, правильно зняли ці обмеження щодо розміру скрипта, але проблема полягає в тому, що кодова база для однорангового зв'язку також реалізувала перевірки розміру скрипту, щоб додати подвійний рівень захисту операторів вузлів. Блоки та транзакції проходитимуть свого роду «узгоджену» перевірку консенсусу, перш ніж потраплять до основного коду консенсусу, який виконує належну перевірку; логіка полягає в тому, що подвійна перевірка додає додаткові рівні захисту від недійсних блоків чи транзакцій. Цей код не був належним чином оновлений, щоб усунути обмеження на розмір скрипту, продовжуючи застосовувати попередні обмеження скриптів для SegWit проти транзакцій Taproot. Таким чином, у той час, як сам фактичний код консенсусу мав би належним чином перевірити цю дуже велику транзакцію Taproot, блок, що її містить, фактично не було передано з однорангової перевірки до фактичної перевірки консенсусу. Це означає, що всі вузли btcd зупинилися на блоці, у тому числі транзакція Бурака.

Чому це вплинуло на LND з огляду на те, що багато людей запускають Bitcoin Core під своїм екземпляром LND? Це тому, що LND використовує той самий код, що і btcd для отримання та обробки блоків. Таким чином, навіть якщо ваш вузол LND працював поверх Bitcoin Core, який правильно перевірив відповідний блок і не зупинився, ваш екземпляр LND відмовився б прийняти цей блок і зупинився б навіть якщо ваш вузол мейнчейна продовжував нормально працювати.

Ця помилка була дуже швидко виправлена ​​і, наскільки мені відомо, нею не скористалися так активно, щоб заподіяти будь-яку шкоду, але це залишило відкритим кожен вузол LND у мережі Lightning Network для потенційної крадіжки коштів у каналах – хіба що вони використовували зовнішню «сторожову башту» (watchtower). Оскільки вузол зупинився на цьому блоці, він не міг бачити блокчейн у реальному часі, і якби контрагент каналу відправив старий стан каналу в блокчейн, він би не знав про це і не міг відповісти відповідною штрафною транзакцією для захисту засобів користувача. Це була дуже серйозна помилка, через яку величезний відсоток біткоїнів у Lightning Network могло бути вкрадено, якщо тільки користувачі самі не оновлювали свої вузли або особисто не відстежували свої канали, щоб мати можливість реагувати вручну у випадку закриття на основі старого стану. Переважна більшість операторів вузлів без технічних знань, ймовірно, не змогли б цього зробити.

На щастя, ця ситуація не потягнула за собою великих збитків. Але, якби цю проблему було виявлено в кодовій базі до того, як транзакція Бурака була поміщена в блокчейн, зловмисники могли б навмисно скористатися нею. Окрема людина або група людей могли б дуже легко відкрити велику кількість каналів у мережі та обміняти всі гроші в цих каналах назад на себе в мережі за допомогою технології Submarine Swaps, залишивши всі кошти в каналі з іншого боку, а потім відправивши велику транзакцію Taproot, як це зробив Бурак, негайно закривши свої канали, використовуючи старий стан. Жертви навіть не знали б про це, а навіть якби й знали, враховуючи відносно низьку технічну компетентність багатьох операторів вузлів, ймовірно, що більшість людей не змогли б вчасно відреагувати та вручну виправити проблему за допомогою штрафної транзакції.

Ця помилка пролила світло на дві важливі проблеми, які слід владнати. По-перше, численні незалежні реалізації вузлів Біткоїна можуть бути дуже небезпечними. На щастя, майже ніхто не використовує btcd як вузол для якихось серйозних транзакцій, тому ефект, який це мало на базову мережу Біткоїна, можна було повністю ігнорувати, за винятком невеликої жменьки людей, чиї вузли просто зупинилися. Якби майнери використовували btcd, це могло б елементарно призвести до поділу ланцюга в мережі Біткоїна та до відключення всіх операторів btcd у меншому ланцюжку і потребувало б ручного втручання. Наступна проблема полягає в тому, що у випадку другого рівня над основною мережею перевірки консенсусу повинні виконуватися дуже обережно. Це складне завдання, тому що не всі вузли Lightning використовують свій власний довірений повний вузол, хоча будь-який вузол Lightning, який працює поверх повного вузла Біткоїна, теоретично може просто передати 100% перевірки цьому вузлу. Це навряд чи зміниться – багато користувачів, ймовірно, продовжать керувати вузлами таким чином, тому в деяких реалізаціях Lightning також повинні підтримуватися перевірки деяких або всіх правил консенсусу Біткоїна.

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

Це гостьовий пост Шинобі, викладача-самоучки у сфері Біткоїна та орієнтованого на технології ведучого подкастів про Біткоїн. Висловлені погляди є його власними і не обов’язково збігаються з точкою зору BTC Inc. або Bitcoin Magazine.