НовостиКриптовалютыMantle выпустила исправление Reth в op-reth v1.6.3 после бага 5 ноября — активы в безопасности

Mantle выпустила исправление Reth в op-reth v1.6.3 после бага 5 ноября — активы в безопасности

Автор: Tron Weekly·

Ключевые выводы

  • •Mantle выпустила op-reth mantle-v1.6.3 — релиз на собственной производственной линии версий с backport-исправлением из апстрима Reth вместо перехода на новейшую апстрим-версию.
  • •5 ноября компания Blockaid сообщила, что необновлённые узлы могли формировать некорректные корни состояния и возвращать неисправные доказательства состояния через eth_getProof — RPC-метод, который приложения и мосты используют для проверки состояния в блокчейне.
  • •Исправление в апстриме появилось в Reth 3 ноября, за два дня до публичного раскрытия информации, в исправленных релизах, включая Reth v2.10.0 и op-reth v2.8.1.
  • •Blockaid классифицировала проблему как баг корректности, а не эксплойт, и не выявила потерь средств, а Mantle подтвердила, что активы в безопасности, действия от пользователей не требуются и миграция базы данных не нужна.
  • •Поскольку большинство цепочек OP Stack используют общий клиент op-reth, баг создал коррелированный риск для в остальном независимых сетей, что вызвало реакцию вроде релиза node-reth v1.5.3 от Base и backport-исправления от Celo.
Mantle выпустила исправление Reth в op-reth v1.6.3 после бага 5 ноября — активы в безопасности

Сеть Mantle оставалась онлайн на протяжении бага состояния (state root) в Reth — апстрим-клиенте исполнения, лежащем в основе её стека op-reth, который затрагивал более широкий круг совместимых с Ethereum сетей. Команда выпустила op-reth mantle-v1.6.3 — релиз на собственной производственной линии версий Mantle, в котором исправление из апстрима перенесено (backport), вместо перехода на новейшую апстрим-версию. В объявлении в X Mantle сообщила, что активы в безопасности, действия от пользователей не требуются и миграция базы данных не нужна, при этом попросив операторов узлов обновиться (пост).

Короткий инцидент с высокими ставками

Эпизод был коротким и незаметным для конечных пользователей, что может создать впечатление его незначительности. Это не так: корни состояния — это криптографические обязательства, используемые для подтверждения корректности балансов аккаунтов и хранилищ контрактов, и их ошибочный расчёт может привести к остановке узлов, возврату некорректных доказательств или отклонению от канонической цепочки. «Чтобы Layer 2 осуществлял расчеты в Ethereum, корректность на этом уровне имеет основополагающее значение», — подчеркнула Mantle в объявлении.

Что произошло и кого это затронуло

Уязвимость находилась в Reth — реализации клиента исполнения Ethereum на Rust — и в op-reth, его варианте для OP Stack, развёрнутом несколькими сетями Layer 2. 5 ноября компания Blockaid сообщила, что необновлённые узлы могли формировать некорректные корни состояния и возвращать неверные доказательства состояния через eth_getProof — RPC-метод, который приложения и мосты используют для проверки состояния в блокчейне. Blockaid классифицировала проблему как баг корректности, а не эксплойт, и не выявила потерь средств. Исправление в апстриме появилось в Reth 3 ноября — за два дня до публичного раскрытия информации — в исправленных релизах, включая Reth v2.10.0 и op-reth v2.8.1.

Реакция распространилась по всей экосистеме. Base выпустила node-reth v1.5.3 и сообщила, что повторно проверила корректность своего узла, а Celo добавила backport-исправление. Mantle выбрала другой путь — исправив свою производственную линию напрямую, вместо обновления до последнего релиза. Это путь backport: целевое исправление доставляется в существующую линию релизов без включения несвязанных изменений из более новых апстрим-версий.

Почему это важно для широкой криптоэкосистемы

Клиенты исполнения — одни из наименее заметных, но самых значимых компонентов блокчейн-инфраструктуры. Разработчики расширяют их API и запускают поверх индексаторы. Институты полагаются на кастодианов, биржи и поставщиков данных. Каждый из этих уровней зависит от консенсуса узлов по состоянию. Некорректный корень состояния не обязательно означает кражу средств — он может означать неточные доказательства, остановленную синхронизацию или получение приложениями несогласованных данных.

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

Событие также подчёркивает важность разнообразия клиентов — и его ограничения. Уровень исполнения Ethereum выигрывает от работы нескольких клиентов, снижая системный риск при отказе одного из них. Однако большинство цепочек OP Stack используют общий op-reth. Поэтому баг в этом общем компоненте создаёт коррелированный риск для в остальном независимых сетей.

Что дальше для Mantle и сетей OP Stack

Немедленный шаг — внедрение обновления операторами. Патч снижает риск только после того, как операторы узлов, RPC-провайдеры, валидаторы и инфраструктурные команды его развернут; от операторов ожидается планирование обновлений и тестирование узлов. Blockaid рекомендовала протоколам и мостам убедиться, что их провайдеры обновлены.

В долгосрочной перспективе инцидент подчёркивает три тенденции: более быстрое раскрытие информации и backport-исправления для производственных линий, которые не могут обновиться немедленно; больше мер на случай клиентских багов, включая проверку доказательств для межчейновых сообщений, когда доказательствам нельзя доверять; и продолжение анализа общих зависимостей между цепочками OP Stack.

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