Валидаторы XRP Ledger (XRPL) установили условную дату активации BatchV1_1 на 14:06:41 UTC 29 сентября, превратив почти случившуюся уязвимость в реальное испытание процесса внесения изменений в сеть и сопутствующего программного обеспечения.
22 сентября, согласно данным xrpldashboard, 30 из 35 доверенных валидаторов поддержали изменение, что превышает отображаемый порог в 28 голосов. Большинство впервые появилось в реестре 15 сентября.
Согласно правилам внесения изменений в XRPL, поддержка должна оставаться выше 80% в течение двух недель. Снижение до 80% или ниже прекращает период большинства, поэтому дата активации остается условной.
29 сентября станет первым производственным испытанием того, сможет ли процесс валидации XRPL, эталонная реализация и экосистема клиентов превратить опасный недостаток, обнаруженный до запуска основной сети, в работоспособную инфраструктуру атомарных транзакций.
Брандмауэр валидаторов сработал до запуска основной сети
Исходное изменение Batch никогда не активировалось в основной сети XRP Ledger. В феврале исследователи обнаружили критическую уязвимость авторизации, когда изменение еще находилось на стадии голосования, и валидаторам было рекомендовано проголосовать против него.
Официальное сообщение об уязвимости от XRPL Labs гласит, что средства не подвергались риску.
Уязвимость заключалась в цикле проверки учетных записей, авторизующих пакет. Если код встречал подписанта для недавно созданной учетной записи, ключ которой совпадал с ключом этой учетной записи, он немедленно возвращал успех, вместо того чтобы продолжать проверку остальных подписантов.
Злоумышленник мог разместить действительного подписанта первым, а затем добавить поддельную запись, якобы авторизующую учетную запись жертвы. Если бы изменение вступило в силу, непроверенная транзакция жертвы могла бы быть выполнена без ключей жертвы.
Реакция XRPL последовала в два этапа. Версия 3.1.1 отметила исходные изменения Batch и fixBatchInnerSigs как неподдерживаемые, заблокировав их активацию. Позже BatchV1_1 заменил их переписанным путем авторизации и дополнительными средствами защиты.
Этот инцидент стал неудачей, пойманной на границе между выпуском программного обеспечения и активацией протокола.
Окончательная спецификация XLS-56 от XRPL Foundation теперь требует, чтобы многоаккаунтный пакет содержал точный, полный набор BatchSigners, авторизация которых обычно требуется для внутренних транзакций, за исключением учетной записи, чья обычная подпись авторизует внешнюю транзакцию.
Отсутствующие, лишние, дублирующиеся или неправильно упорядоченные записи приводят к отклонению.
Каждый BatchSigner также подписывает не просто свободную коллекцию внутренних транзакций. Полезная нагрузка связывает подпись с внешней учетной записью, ее порядковым номером или билетом, выбранным режимом пакета, упорядоченными хэшами каждой внутренней транзакции и учетной записью BatchSigner.
Многоподписанный элемент также связывает каждую вложенную учетную запись подписанта. Это предотвращает перенос действительной подписи в другую внешнюю транзакцию или ее передачу другому участнику.
Объединенная эталонная реализация добавляет принудительное применение этих правил, включая проверки порядка и уникальности подписантов, ограничения по количеству транзакций, отклонение напрямую отправленных внутренних транзакций и защиту от повторного воспроизведения реестра.
В совокупности эти изменения устраняют как раскрытый баг преждевременного успеха, так и смежные способы, которыми некорректные или повторно воспроизведенные данные пакета могли пересекать границы авторизации.
Пакет содержит от двух до восьми внутренних транзакций. Каждая внутренняя транзакция не имеет подписи или комиссии и помечена так, что ее нельзя отправить отдельно. Внешний пакет выбирает ровно один из четырех режимов:
- ALLORNOTHING: каждая внутренняя транзакция должна быть успешной, иначе изменения состояния ни одной из них не будут зафиксированы.
- ONLYONE: применяется только первая успешная внутренняя транзакция.
- UNTILFAILURE: транзакции применяются по порядку до тех пор, пока одна из них не завершится неудачей.
- INDEPENDENT: предпринимаются попытки выполнения каждой внутренней транзакции независимо от результатов других.
BatchV1_1 может поддерживать атомарные потоки “все или ничего”, но не каждый пакет является атомарным в этом узком смысле. Разработчики также могут использовать его для упорядоченных резервных копий или независимых пакетов.
Активация переносит риск на реализацию
Наиболее непосредственная ловушка интеграции заключается в том, что внешний пакет может вернуть tesSUCCESS, даже если одна или несколько внутренних транзакций завершились неудачей. Клиенты должны проверять метаданные и код результата каждой внутренней транзакции, чтобы определить, что произошло.
Это различие важно за пределами режима ALLORNOTHING, где частичное или независимое выполнение является преднамеренным.
Поддержка BatchV1_1 была выпущена в xrpld 3.3.0 6 августа. После активации изменения сервер, который не понимает новых правил, станет заблокированным для изменений. Он больше не сможет надежно проверять реестр или участвовать в консенсусе до обновления.
Проблема, зарегистрированная для xrpl.js, документировала, что версия 5.0.0 создавала подписи Batch, используя старую полезную нагрузку, опуская внешнюю учетную запись, последовательность и привязку участника. Узлы с поддержкой BatchV1_1 отклоняли эти подписи с ошибкой temBAD_SIGNATURE.
История выпусков xrpl.js фиксирует совместимую поддержку в версии 5.1.0.
| Компонент | Точка готовности | Риск при устаревании |
|---|---|---|
| xrpld | Поддержка BatchV1_1 выпущена в 3.3.0 | Несовместимый сервер может быть заблокирован для изменений после активации |
| xrpl.js | Версия 5.1.0 добавила пересмотренный формат подписи | Версия 5.0.0 может создавать подписи, отклоняемые узлами BatchV1_1 |
| Кошельки | Отображать каждое внутреннее действие и выбранный режим | Пользователь может одобрить пакет, не понимая его полного эффекта |
| Эксплореры и индексаторы | Сохранять связь между внешними и внутренними транзакциями | Интерфейсы могут некорректно сообщать или фрагментировать результат пакета |
Строки “Кошельки” и “Индексаторы” отражают рекомендации по интеграции в подробных правилах XLS-56. Протокол может отклонить некорректную подпись, но он не может заставить кошелек четко объяснить сложный пакет или эксплорер представить каждый внутренний результат в контексте.
Спецификация также отмечает фронтраннинг как область, которая все еще находится под следствием. Более сильная авторизация предотвращает подделку одобрения другой учетной записи, но не устраняет все риски, связанные с объединением нескольких рыночных действий в одну упорядоченную отправку.
Что докажет 29 сентября
Если большинство сохранится, активация покажет, что процесс валидации XRPL может остановить опасное изменение, направить операторов к отключенному выпуску, а затем провести отремонтированную замену через тот же механизм управления.
Это также начнет реальное испытание того, согласуются ли серверы, библиотеки подписей, кошельки и инфраструктура данных по новому формату транзакций и его результатам.
Это не докажет, что приложения приняли BatchV1_1, что пользователи хотят эту функцию или что спрос на сетевые транзакции увеличится. Голосование по изменениям и выпуск программного обеспечения устанавливают доступность протокола, но не предоставляют доказательств дополнительного спроса на XRP.
Полезные сигналы появятся после активации: станут ли устаревшие узлы заблокированы, будут ли сбои подписей концентрироваться вокруг старых версий клиентов, будут ли кошельки понятно представлять многоаккаунтные пакеты и будут ли эксплореры сообщать о внутренних результатах, не принимая внешний успех за полное выполнение.
Валидаторы XRPL прошли первое испытание, предотвратив попадание исходной уязвимости Batch в основную сеть. Условная активация 29 сентября ставит вопрос о том, достаточно ли экосистема усвоила уроки этого почти случившегося инцидента, чтобы безопасно использовать замену.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Liam 'Akiba' Wright
