Это редакционная статья Шиноби, преподавателя-самоучки в сфере Биткойна и ведущего подкаста по Биткойну, ориентированного на технологии.
9 октября 2022 года Бурак из Bitmatrix (своп-инструмент, построенный на Liquid Network) создал и транслировал в основную сеть Биткойна транзакцию, потратив UTXO с мультисигом Tapscript с порогом 998 из 999. Эта транзакция содержала 998 индивидуальных подписей в поле свидетеля, имела размер почти 0,1 МБ и, что довольно забавно, повторно использовала точно такой же открытый ключ для каждого из 999 участников мультисига. Эта транзакция вызвала масштабный сбой в работе Lightning Network, раскрыв ошибку в LND и btcd (альтернативный клиент для сети Биткойн).
Вся цель проведения этой транзакции заключалась в демонстрации улучшенной масштабируемости скриптов мультиподписи, которую обеспечил Taproot. Даже без использования протоколов MuSig, основанных на Шнорр-подписи, Taproot позволяет использовать гораздо большие наборы участников мультиподписи, чем предыдущие версии Bitcoin Script. Если углубиться во все возможные способы построения мультисиг с помощью 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 подвергался риску кражи, если только пользователи сами вручную не устанавливали исправления и обновления на свои узлы или лично не отслеживали свои каналы, чтобы иметь возможность вручную отреагировать в случае закрытия канала с устаревшим состоянием. Должен сказать, что подавляющее большинство нетехнических операторов узлов, скорее всего, не смогли бы этого сделать.
К счастью, эта проблема не была широко использована, но если бы она была обнаружена в кодовой базе до того, как транзакция Бурака была выведена на блокчейн, это могло бы быть намеренно использовано плохими игроками очень тактическим способом. Человек или группа людей могли бы очень легко открыть большое количество каналов в сети и обменять все деньги в этих каналах обратно на себя в сети с помощью подводного обмена, оставив все средства в канале на другой стороне, а затем подать большую транзакцию Taproot, как это сделал Бурак, немедленно закрыв свои каналы, используя устаревшее состояние. Жертвы даже не знали об этом, а даже если бы и знали, то, учитывая относительно низкую техническую компетентность многих операторов узлов, весьма вероятно, что большинство людей не смогли бы вовремя отреагировать и вручную исправить проблему с помощью штрафной транзакции.
Эта ошибка подчеркивает два важных момента, которые необходимо рассмотреть. Во-первых, несколько независимых реализаций узлов Биткойна могут быть очень опасны. К счастью, почти никто не запускает btcd в качестве узла для чего-либо серьезного, поэтому эффект, который это оказало на базовую сеть Биткойн, можно полностью игнорировать, за исключением очень небольшой горстки людей, чьи узлы просто заглохли. Если бы майнеры управляли btcd, это могло бы легко привести к разрыву цепи в сети Биткойн, в результате чего все операторы btcd оказались бы в меньшинстве, и для исправления ситуации потребовалось бы ручное вмешательство. Вторая проблема заключается в том, что в случае вторых уровней над основной сетью реализация проверок консенсуса должна осуществляться очень осторожно. Это сложный вопрос, поскольку, хотя любой узел Lightning, работающий поверх полного узла Биткойна, теоретически может просто передать 100% этой проверки этому узлу, не все узлы Lightning используют свой собственный доверенный полный узел. Это вряд ли изменится — многие пользователи, по всей вероятности, будут продолжать управлять узлами таким образом, поэтому в какой-то степени проверка некоторых или всех правил консенсуса Биткойна должна поддерживаться и в реализации Lightning.
В дальнейшем я надеюсь, что это станет тревожным сигналом о том, насколько важно обеспечить синхронизацию проверок валидности консенсуса во всем программном обеспечении в этом пространстве, поскольку без этой синхронизации между всеми компонентами не существует единой целостной сети Биткойн. Все должны быть очень рады, что это не привело к масштабной эксплуатации всей сети, но люди должны осознавать, насколько серьезной могла бы быть эта проблема, если бы все не сложилось так, как сложилось.
Это гостевой пост компании Shinobi. Высказанные мнения полностью принадлежат ему и не обязательно совпадают с мнением BTC Inc или Bitcoin Magazine.
Зарабатывайте биткоины бесплатно на лучшем кране Фрибиткоин до 200$ каждый час.