💬 Изучение ошибки LND, которая могла ограбить сеть освещения

Изучение ошибки LND, которая могла ограбить сеть освещения

Это редакционная статья Шиноби, преподавателя-самоучки в области биткойнов и ведущего подкастов о биткойнах, ориентированных на технологии.

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, который правильно проверил бы соответствующий блок и не остановился, ваш экземпляр LND отказался бы принять этот блок и остановился бы, даже если ваш узел основной цепи продолжал нормально работать.

Эта ошибка была очень быстро исправлена, и, насколько мне известно, она не использовалась активно таким образом, чтобы причинить какой-либо вред, но это оставило открытым каждый узел LND в сети Lightning Network для потенциальной кражи средств в каналах, если только они не использовали внешняя сторожевая башня. Поскольку узел был остановлен на этом блоке, он не имел представления о цепочке блоков в реальном времени, и в случае, если бы контрагент по каналу отправил старое состояние канала в цепочку блоков, он бы совершенно не знал об этом и не мог ответить. с соответствующей штрафной транзакцией для защиты средств пользователя. Это была очень серьезная ошибка, из-за которой огромный процент биткойнов в сети Lightning Network подвергался риску кражи, если только пользователи сами не устанавливали патчи и не обновляли свои узлы или лично не отслеживали свои каналы, чтобы иметь возможность реагировать вручную в случае закрытия. с устаревшим состоянием. Я должен сказать, что подавляющее большинство нетехнических операторов узлов, вероятно, не смогли бы этого сделать.

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

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

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

Это гостевой пост Шиноби. Высказанные мнения являются полностью их собственными и не обязательно отражают точку зрения BTC Inc или Bitcoin Magazine.