На странице известных поправок XRPL указано, что исправление fixCleanup3_1__3
будет активировано 27 мая, и по замыслу это событие является обновлением для технического обслуживания.
Версия 3.1.3 rippled
содержит исправления для NFT, разрешенных доменов (Permissioned Domains), хранилищ (Vaults) и протокола кредитования (Lending Protocol), а в блоге XRPL по умолчанию был установлен голос «Да» из-за важности этих исправлений.
Процесс внесения поправок требует поддержки более 80% доверенных валидаторов, сохраняющейся в течение двух недель, прежде чем новые правила станут постоянными.
Что делает этот эпизод достойным изучения за пределами крайнего срока, так это слова сооснователя XRPL Дэвида Шварца о том, что на самом деле потребовалось бы для настоящего форка, поскольку его ответ раскрывает, как работает легитимность протокола на любом блокчейне.
Основной тезис Шварца заключается в том, что простое количество узлов является плохим показателем консенсусной мощности. Система, в которой узлы голосуют пропорционально их числу, создает поверхность атаки, где любой может запустить тысячи машин с низкими затратами.
В модели XRPL каждый оператор сервера поддерживает курируемый набор валидаторов, которым сервер доверяет, что они не вступают в сговор, — Список уникальных узлов (Unique Node List, UNL), — и именно UNL определяет, какие голоса валидаторов учитываются сервером во время консенсуса.
Сервер получает сообщения о валидации от множества узлов по всей сети, и валидаторы из его UNL определяют, какие из этих сообщений формируют представление сервера о реестре.
Шварц пояснил, что легитимность консенсуса на XRPL проходит через списки доверия и координацию валидаторов, создавая систему, в которой согласованность UNL и экономическое принятие определяют, какой реестр переживет раскол.
Почему настоящий форк требует полноценной кампании по координации
При голосовании по XRPL 27 мая серверы, которые оказываются заблокированными поправкой (amendment-blocked), теряют способность определять действительность реестра, отправлять или обрабатывать транзакции, участвовать в консенсусе или голосовать по будущим поправкам.
Это делает крайний срок операционно важным для любой биржи, кошелька, обозревателя или оператора инфраструктуры, все еще использующего программное обеспечение до версии 3.1.3, поскольку эти серверы становятся не-участниками канонического реестра до тех пор, пока оператор не обновится.
Инфраструктура, заблокированная поправкой, теряет доступ к обновленной цепи и не имеет координационной инфраструктуры для поддержки функционального конкурента.
Чтобы создать достоверный форк, оппозиционной группе потребуются валидаторы, готовые продолжать создавать реестры по старым правилам, а без валидаторов нет потока реестра, за которым можно следовать.
Затем им потребуется конкурирующий Список уникальных узлов, который серверы смогут настроить или который будет установлен по умолчанию в программном обеспечении, поскольку без доверенного списка валидаторов у узлов нет механизма для координации вокруг старых правил.
Вдобавок им потребуется дистрибутив кода, сохраняющий старые правила и поставляемый с настройками по умолчанию, указывающими на конкурирующий UNL, а также поддержка инфраструктуры со стороны кошельков, бирж, обозревателей и приложений, достаточная для того, чтобы сделать реестр со старыми правилами доступным и торгуемым.
Документация XRPL ссылается на исследования, показывающие, что конкурирующие UNL могут потребовать 90% совпадения в худшем случае для предотвращения форка, что означает, что любой конкурирующий UNL должен будет разделять почти весь набор доверенных валидаторов с каноническим для поддержания внутренней согласованности.
Форк, формирующийся вокруг радикально отличающегося набора валидаторов, рискует создать реестр, который не сможет поддерживать собственный консенсус, не говоря уже о привлечении рыночного принятия.
Процесс внесения поправок на самом деле отслеживает поддержку валидаторов, а порог в 80% в течение двух недель гарантирует, что структуры, которым доверяет сеть, достигли прочного соглашения, прежде чем новые правила станут постоянными.
Большая доля необновленных невалидаторных узлов может отражать отставание инфраструктуры, не подразумевая ничего о траектории канонического реестра.
Разница между отставанием инфраструктуры и конкурирующей цепью
В худшем случае биржи, кошельки или операторы инфраструктуры, которые отстанут от активации 27 мая, будут заблокированы поправкой и перестанут функционировать как участники реестра.
Пользователи, использующие маршрутизацию через этих провайдеров, столкнутся с перебоями в обслуживании, такими как невозможность отправки транзакций, обозреватели, неспособные подтвердить действительность реестра, и приложения, неспособные обрабатывать платежи.
Эти операционные издержки ложатся на операторов, которые понизили приоритет обновления, и за этим стоит следить, особенно в отношении любой крупной биржи или кастодиана, все еще использующего узлы до версии 3.1.3 на момент активации.
Устойчивое отставание инфраструктуры среди достаточного числа провайдеров создаст реальное трение для пользователей, даже если канонический реестр продолжит работу по новым правилам.
В лучшем случае fixCleanup3_1_3
активируется по расписанию при сохранении супербольшинства валидаторов, операторы инфраструктуры обновятся без серьезных инцидентов, и этот эпизод станет рутинной активацией поправки.
Исправления для NFT, разрешенных доменов, хранилищ и протокола кредитования вступят в силу, и сеть продолжит работу. Дебаты об управлении, которые выявит обновление, сохранятся независимо от исхода, поскольку объяснение Шварца о том, что потребуется для реального раскола, применимо к любой будущей поправке.
Поддержание старых правил требует, чтобы оппозиционная группа использовала старое программное обеспечение, набирала валидаторов вокруг конкурирующего UNL и убеждала кошельки, биржи и маркет-мейкеров признать свой реестр каноническим XRP Ledger, в противовес конфигурации по умолчанию, направляющей всех остальных к обновленной цепи.
У каждого блокчейна есть уровень управления
Шварц провел сравнение со Stellar, чье обновление Протокола 24 само по себе является исправлением стабильности для бага архивации состояния в Stellar Core, что было событием технического обслуживания, требующим такого же скоординированного принятия валидаторами.
Эквивалентный уровень легитимности Биткоина проходит через майнеров, экономические узлы, клиентские реализации и листинги на биржах. У Ethereum он проходит через валидаторов, стейкинговую инфраструктуру, разнообразие клиентов, основных разработчиков и принятие на уровне приложений.
То, что XRPL делает явным через UNL, другие сети встраивают в распределение майнинговой мощности, экономику стейкинга или социальный консенсус относительно того, каким клиентским программным обеспечением доверяют разработчики.
Механизмы различаются у Биткоина, Ethereum и XRPL, в то время как зависимость от скоординированных человеческих решений для закрепления изменений правил проходит через все три.
Активация 27 мая иллюстрирует, как уровень управления XRPL преобразует согласие валидаторов в постоянство реестра, при этом конфигурация UNL определяет, какие соглашения имеют значение.
Оператор, не согласный с fixCleanup3_1_3
, имеет техническую свободу запустить старое программное обеспечение и настроить конкурирующий UNL.
Будет ли биржа листить полученный токен, будет ли его поддерживать кошелек или маркет-мейкер предоставлять ликвидность — это вопрос, на который протокол не может ответить за них.
Этот разрыв в координации является причиной того, почему обновления протоколов в сетях с широким принятием редко приводят к устойчивым форкам: экономика следования канонической цепи почти всегда перевешивает экономику создания параллельной цепи с нуля, а канонической цепью становится та, которую рынок определяет как реальную.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Gino Matos
