Извлекаем уроки из ошибки LND, которая могла ограбить Lightning Network

Извлекаем уроки из ошибки LND, которая могла ограбить Lightning Network

Ошибка, которая привела к остановке узлов LND и btcd, оказала минимальное влияние, но могло быть намного хуже.

9 октября 2022 года Бурак из Bitmatrix (инструмент обмена, построенный на основе Liquid Network) создал и транслировал транзакцию в основную сеть Биткоина, потратив UTXO с мультиподписью Tapscript с порогом 998 из 999. Эта транзакция имела 998 индивидуальных подписей в поле свидетеля и была размером почти 0,1 МБ, и, как ни странно, повторно использовала один и тот же открытый ключ для каждого из 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 для потенциальной кражи средств в каналах, если только они не использовали внешний дозор. Поскольку узел был остановлен на этом блоке, у него не было представления о цепочке блоков в реальном времени, и в случае, если контрагент канала отправил бы старое состояние канала в блокчейн, он бы совершенно не знал об этом и не мог ответить соответствующей штрафной транзакцией для защиты средств пользователя. Это была очень серьезная ошибка, из-за которой огромный процент биткоинов в Lightning Network подвергался риску кражи, если только пользователи сами не обновляли свои узлы или лично не отслеживали свои каналы, чтобы иметь возможность реагировать вручную в случае закрытия с устаревшим состоянием. Я должен сказать, что подавляющее большинство нетехнических операторов узлов, вероятно, не смогли бы этого сделать.

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

Эта ошибка пролила свет на две важные проблемы, которые следует учитывать. Во-первых, множественные независимые реализации узлов Биткоина могут быть очень опасны. К счастью, почти никто не использует btcd в качестве узла для чего-то серьезного, поэтому эффект, который это оказало на базовую сеть Биткоина, можно было полностью игнорировать, за исключением очень небольшой горстки людей, чьи узлы просто остановились. Если бы майнеры использовали btcd, это могло бы очень легко привести к разделению цепи в сети Биткоина, что привело бы к отключению всех операторов btcd в цепочке меньшинства и потребовало бы ручного вмешательства. Следующая проблема заключается в том, что в случае вторых уровней над основной сетью проверки консенсуса должны выполняться очень осторожно. Это сложная задача, потому что не все узлы Lightning используют свой собственный доверенный полный узел, хотя любой узел Lightning, работающий поверх полного узла Биткоин, теоретически может просто передать 100% проверки этому узлу. Это вряд ли изменится – многие пользователи, по всей вероятности, продолжат управлять узлами таким образом, поэтому в некоторых реализациях Lightning также должны поддерживаться проверки некоторых или всех правил консенсуса Биткоина.

Смотря в будущее, хочу сказать, что это серьезное напоминание о том, насколько важно обеспечить синхронизацию всех проверок консенсуса в программном обеспечении в этом пространстве, поскольку без этой общей синхронности на самом деле не существует единственного связной сети Биткоина. Мы должны радоваться, что это не привело к массовому эксплойту по всей сети, и осознавать, насколько серьезной могла быть эта проблема, случись все иначе.

Это гостевой пост Шиноби, преподавателя-самоучки в Биткоин-сфере и ориентированного на технологии ведущего Биткоин-подкастов. Точки зрения, высказанные в этой статье, принадлежат автору и не обязательно отражают взгляды BTC Inc. или Bitcoin Magazine.

Рекордный рост BTC: что это значит для вашего инвестиционного будущего Рекордный рост BTC: что это значит для вашего инвестиционного будущего На какие факторы следует обратить внимание сейчас, когда биткоин снова демонстрирует бычий тренд, чтобы не принимать эмоциональные или неправильные решения в разгар рыночной лихорадки. Майлз Оливер 24 марта 2024
Восемь причин использовать аппаратный биткоин-кошелек Восемь причин использовать аппаратный биткоин-кошелек Защита приватных биткоин-ключей – непростая задача, и пользователям приходится выбирать между программными кошельками, бумажными кошельками, аппаратными кошельками и даже «мозговыми кошельками». Наведем восемь причин использовать аппаратные кошельки для хранения. Unchained Capital 24 марта 2024
KYC, Биткоин и неоправдавшиеся надежды на политику AML KYC, Биткоин и неоправдавшиеся надежды на политику AML Зачем создавать препятствия и подталкивать злоумышленников к переходу с криптовалюты на трудно отслеживаемые наличные деньги, если их средства можно отследить с помощью ончейн-аналитики? Мария Потеряева 23 марта 2024