Процесс амендментов подробно

Подробный взгляд на то, как могут изменяться протокольные правила XRP Ledger, и на встроенные в этот процесс защитные механизмы.

Каждая нативная функция, описанная на протяжении раздела «Технология» этой вики, — AMM, NFT, эскроу и так далее — попала в XRP Ledger через один и тот же формальный механизм: процесс амендментов. Эта страница идёт дальше, чем краткое упоминание в статье Что такое XRP Ledger?.

Что такое амендмент

Амендмент — это предложенное, дискретное изменение протокольных правил XRP Ledger — что угодно, от добавления совершенно нового типа транзакции (как AMM или NFT) до исправления частного случая в существующем поведении. Амендменты идентифицируются по имени и уникальному хешу и реализуются в кодовой базе rippled заранее, поставляются в составе релиза ПО, но не активируются, пока сама сеть не проголосует за их включение.

Почему активация отделена от поставки кода

Это осознанное решение в целях безопасности. Разработчики ПО могут написать и выпустить код для нового амендмента заблаговременно, давая операторам узлов и валидаторов время обновить своё программное обеспечение, — но новые правила фактически не вступают в силу в действующей сети, пока валидаторы явно не просигнализируют о поддержке. Это отделяет «код существует и доступен» от «сеть согласилась его использовать», не позволяя ни одному отдельному релизу ПО незаметно изменить правила консенсуса.

Механизм голосования

Как только код, поддерживающий амендмент, развёрнут, валидаторы могут включать голос «за» этот амендмент в производимые ими леджеры. Амендмент активируется только при выполнении условий:

как минимум 80% доверенных валидаторов голосуют за него, и
этот уровень поддержки в 80%+ непрерывно сохраняется в течение двух недель.

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

Что это предотвращает

Никаких односторонних изменений. Даже Ripple, несмотря на управление валидаторами и публикацию широко используемого списка по умолчанию (см. Unique Node List and Validators), не может активировать амендмент самостоятельно — требуется широкое согласие в рамках всего доверенного набора валидаторов.
Никаких тихих принудительных обновлений. Операторы узлов, не согласные с предлагаемым изменением, могут просто не обновлять своё ПО для его поддержки, и пока достаточная часть сети согласна с ними, изменение не активируется.
Никаких случайных необратимых ошибок без предупреждения. Требование двухнедельного устойчивого супербольшинства даёт экосистеме — биржам, поставщикам кошельков, разработчикам приложений — реальное заблаговременное уведомление до вступления изменения в силу, а не мгновенное переключение.

Что происходит, если сеть не соглашается

В принципе, если значимое меньшинство валидаторов отказывается поддержать амендмент, которого хочет большинство, и это разногласие непримиримо, сеть теоретически может расколоться на две несовместимые цепочки («хардфорк») — хотя на практике в истории амендментов XRPL подобного конфликтного раскола не наблюдалось: предложенные амендменты, как правило, либо приходят к широкому принятию, либо откладываются после обсуждения в сообществе (о стадии обсуждения, происходящей задолго до того, как функция доходит до голосования валидаторов, см. XLS: How New Features Get Proposed).

Вывод старых амендментов из употребления

Амендменты также можно пометить как «устаревшие», как только функциональность полностью заменена чем-то новым, — это со временем позволяет очищать кодовую базу, не нарушая уже активированное поведение в действующей сети.