Ошибка в Liquid Network могла привести к потере BTC на $320 млн

Исследователи, разбирающие инцидент в Liquid Network на сумму около $320 млн, указывают на предполагаемый сбой в кэше проверки транзакций. По их версии, именно он мог позволить погашать необеспеченные токены на реальные биткоины. В обсуждениях также звучит вопрос о том, какой именно код был развернут в сети. По словам Mononaut, уязвимость попала в основную ветку разработки Elements на предыдущей неделе, но не входила ни в один помеченный релиз. Тем не менее, как утверждается, операторы федерации Liquid запускали именно этот код, тогда как другие узлы отклоняли некорректные транзакции. Blockstream в доступных заявлениях эту версию развертывания не подтверждал. Если она подтвердится, ключевым фактором инцидента станет выпуск обновления: корректные подписные учетные данные могли санкционировать выдачу BTC под LBTC, якобы созданные из-за ошибки. Liquid — это сайдчейн Bitcoin, где токены LBTC должны быть обеспечены BTC в пропорции один к одному за счет резервов федерации. Как ранее сообщал CryptoSlate, SideSwap заявила, что 6 сентября клиент направил 4 000 LBTC через ее сервис peg-out, после чего было выпущено примерно 3 996 BTC. Liquid отмечала, что ключ авторизации peg-out у SideSwap и другие ключи федерации не были скомпрометированы. Текущие технические объяснения концентрируются на том, каким образом токены вообще дошли до стадии вывода. Calle описал уязвимость, связанную с range proofs — доказательствами диапазона, позволяющими узлам проверять, что скрытые суммы транзакций находятся в допустимых пределах, не раскрывая сами значения. В конфиденциальных транзакциях Liquid недостаточно лишь совпадения сумм входов и выходов: скрытый отрицательный выход мог бы компенсировать больший положительный, и математически баланс сошелся бы даже при эмиссии новых токенов. Range proofs должны предотвращать такой сценарий. Поскольку проверка range proofs вычислительно затратна, узлы кэшируют результаты успешной верификации для повторного использования. По версии Calle, атакующий мог сформировать некорректный выход и доказательство так, чтобы они совпали по ключу кэша с ранее валидной проверкой. Узел, обнаруживший запись в кэше, пропускал бы проверку, которая должна была отклонить инфляционный выход. Charles Guillemet поддержал эту интерпретацию, назвав ее примером специально созданной коллизии ключа кэша, позволившей некорректной конфиденциальной транзакции пройти range-проверку. Calle подчеркнул, что описание упрощает механику и может содержать неточности. Отдельная реконструкция транзакций от Stu указывает на подготовительные операции, за которыми последовала предположительно некорректная транзакция в блоке Liquid 4 050 336. По словам Stu, она создала около 3 996.0183 LBTC, после чего последовал вывод через SideSwap. Версия Mononaut добавляет важное различие между узлами, которые приняли транзакцию, и теми, кто ее отклонил. Он утверждает, что операторы федерации приняли эксплойт-транзакции, одобрили вывод средств и продолжили строить блоки. Другие узлы, включая те, на которых работает Liquid-обозреватель mempool, отклонили проблемный блок. Это может объяснить, почему эксплорер, следующий за отвергающими узлами, не показывал транзакции, которые были видны в других источниках. Сообщаемая дивергенция делает вопрос о версиях ПО принципиальным для понимания причин сбоя. В постмортеме потребуется установить, какие функции кода выполнялись, почему они были развернуты и чем логика валидации отличалась от узлов, отвергших блок. Лица, контролирующие выведенный биткоин, называют себя "whitehat" и связывают возврат большей части средств с устранением уязвимости на затронутых узлах. В доступных материалах нет подтверждения, что возврат завершен или что обновление с исправлением уже развернуто. Возврат BTC устранил бы дефицит резервов. Доказательство того, почему федеративные узлы приняли транзакции, и демонстрация, что исправленное ПО их отклоняет, должны закрыть вопрос о механизме, который позволил резервам покинуть сеть.