Аудит Sherlock выявил 96 ошибок в коде XRP Ledger до релиза
Ключевые выводы
- •Конкурсный аудит Sherlock выявил 96 ошибок в кодовой базе XRP Ledger до выпуска релиза пользователям.
- •Проверка была направлена на rippled — серверное программное обеспечение с открытым исходным кодом, лежащее в основе сети XRP Ledger.
- •Проверенный релиз был связан с обновлением rippled 3.3.0, задокументированным в журнале изменений сети.
- •Операционная команда XRP Ledger упомянула аудит в X как часть процесса релиза, а не как реакцию на инцидент.
- •В доступных сообщениях не указаны уровни серьёзности и способы решения каждой проблемы.

Аудит безопасности Sherlock выявил 96 ошибок в коде XRP Ledger до того, как релиз дошёл до пользователей, — это одна из наиболее масштабных предрелизных проверок, о которых сообщалось для программного обеспечения этой сети.
Что выявил аудит Sherlock
Аудит был проведён через конкурсную платформу проверки Sherlock, на которой проводился конкурс по кодовой базе XRP Ledger. В рамках этой модели независимые исследователи безопасности анализируют кодовую базу в течение определённого окна проверки, а проблемы фиксируются до выпуска кода. Проверка была направлена на базовое программное обеспечение реестра, а не на отдельное приложение. Этим ядром является rippled — серверная реализация с открытым исходным кодом, написанная в основном на C++, которую запускают валидаторы и другие серверы для работы сети; это делает выявленные проблемы более близкими к основанию реестра, чем ошибки, ограниченные одним приложением или кошельком.
Конкурсные проверки такого типа, при которых независимые исследователи соревнуются за вознаграждение за подтверждённые находки, стали неотъемлемой частью безопасности смарт-контрактов благодаря таким платформам, как Sherlock и Code4rena. Проведение подобной проверки программного обеспечения узлов крупного реестра распространяет ту же модель глубже в стек — от контрактов уровня приложений к коду, обрабатывающему каждую транзакцию.
Согласно сообщениям, в ходе процесса было выявлено 96 ошибок до того, как код попал хотя бы в один кошелёк. Эта цифра относится к проблемам, зафиксированным в течение окна проверки, а не к подтверждённым эксплойтам в продакшне.
Релиз, связанный с этим циклом, задокументирован в собственном журнале изменений сети для обновления rippled 3.3.0 — версии, которая находится в центре проверенной работы.
Почему важно находить ошибки до релиза
Обнаружение дефектов до развёртывания означает, что их можно устранить, пока код ещё находится на проверке, а не после того, как он уже работает в реальном времени на валидаторах и в кошельках пользователей. Именно этот момент является основной ценностью предрелизного аудита.
Для реестра, ориентированного на расчёты, обнаружение проблем до релиза снижает риск попадания дефекта в продакшн, где могут быть затронуты средства, обработка транзакций или поведение консенсуса. Аудит выполняет роль фильтра между разработкой и реальным использованием. Для инфраструктуры такого рода ставки особенно высоки: XRP Ledger подтверждает платежи через процесс согласования среди своего набора валидаторов, а не через майнинг proof-of-work, поэтому дефекты, затрагивающие обработку транзакций или консенсус, находятся в слое, от которого зависит каждый пользователь сети.
Операционная команда XRP Ledger указала на проверку через свой официальный канал в X, подчеркнув, что аудит был частью процесса релиза, а не реакцией на инцидент.
Что это означает для дальнейшего контроля XRP Ledger
Привлечение внешней сторонней проверки добавляет уровень контроля сверх внутреннего тестирования, а заявленное количество ошибок показывает, что такие проверки по-прежнему выявляют значительный объём проблем даже на устоявшейся инфраструктуре.
Внешние аудиты стали обычным сигналом доверия в криптоиндустрии — подобно тому, как подтверждения резервов сформировали дискуссию об обеспечении стейблкоинов, когда аудит Tether от «Большой четвёрки» показал, что резервы превышают обязательства. Проверка кода и финансовая аттестация преследуют одну и ту же цель: проверяемые гарантии для пользователей.
Вопрос таких гарантий распространяется и на меры защиты на уровне кошельков — эту область недавно подчеркнул случай, когда пользователи CyberWallet и Passkey столкнулись с приостановкой вывода средств. Готовность релиза на уровне протокола и надёжность на уровне кошелька вместе определяют, насколько пользователи могут полагаться на сеть.
Детали уровней серьёзности и того, как была решена каждая проблема, в доступных сообщениях не установлены, поэтому значимость здесь основывается на масштабе проверки и её предрелизном характере, а не на конкретной природе отдельных ошибок. Сигналы, за которыми стоит следить далее, — появятся ли в документации релиза разбивка по уровням серьёзности и заметки об устранении, а также станут ли сторонние конкурсы постоянной частью циклов релизов XRPL.
Отказ от ответственности: эта статья носит исключительно информационный характер и не является финансовой или инвестиционной рекомендацией. Рынки криптовалют и цифровых активов несут значительные риски. Всегда проводите собственное исследование перед принятием решений.