В децентрализованной сети, такой как XRP Ledger (XRPL), нет единого органа, который мог бы принимать решения за всю сеть. Скорее, это участники сети принимают решения по большим и малым вопросам, используя любые механизмы и инструменты, которые предоставляет сеть.
В XRP Ledger основным механизмом выбора являются поправки: изменения в порядке применения транзакций, будь то введение новых функций, расширение существующей функциональности или исправление ошибок, за которые голосуют участники сети. Серверы независимо друг от друга подсчитывают голоса и решают, имеет ли конкретная поправка достаточную поддержку, чтобы стать активированной. Если достаточное количество серверов в сети голосует в поддержку поправки в течение двух недель подряд, она активируется, и функциональность, которую она закрывала, становится доступной.
В более ранних версиях программного обеспечения XRP Ledger серверы автоматически голосовали в поддержку любых поправок, которые они понимали, если операторы серверов не предпринимали дополнительных действий по настройке их на вето поправки.
Новые версии, включая последнюю версию 1.9.2, по умолчанию голосуют против новых функций, за исключением поправок «fix», которые направлены на исправление ошибок в существующей функциональности.
Независимо от того, голосуют ли по умолчанию «да» или «нет», важно, чтобы операторы валидатора самостоятельно оценивали влияние отдельных поправок и решали, как голосовать, используя свои собственные суждения и критерии, которые они считают важными. В этом посте мы хотим дать собственную оценку двум новым поправкам и объяснить, как мы решили, что валидаторы Ripple должны голосовать.
ExpandedSignerList.
XRP Ledger поддерживает мультиподпись, что позволяет настраивать счета таким образом, что для того, чтобы транзакции считались правильно подписанными, требуется одна или несколько подписей. Текущая реализация ограничивает количество возможных подписантов до 8.
Поправка ExpandedSignerList, представленная Ричардом Холландом, увеличивает количество подписывающих лиц с 8 до 32 и позволяет прикреплять некоторые дополнительные метаданные к отдельным записям подписывающих лиц, что может быть полезно для инструментов управления подписями и ключами.
Как правило, количество учетных записей, настроенных на многократную подпись, составляет небольшой процент от общего числа учетных записей, и еще меньшее их количество, скорее всего, будет нуждаться в нескольких подписантах или использовать их. В результате, увеличение размера состояния бухгалтерской книги, даже с учетом дополнительных метаданных, введенных этой поправкой, ожидается минимальным.
Проверка подписей требует больших затрат, и транзакции, подписанные несколькими подписантами, не только больше по размеру, но и требуют больших вычислительных затрат для проверки, причем эти затраты распределяются между всеми серверами в сети. Данная поправка вряд ли приведет к увеличению числа счетов, использующих многократную подпись, и, как объяснялось ранее, ожидается, что число счетов, которые будут иметь более нескольких подписантов, останется очень низким. В результате увеличение вычислительных затрат будет минимальным.
Увеличение числа подписантов может облегчить поддержку некоторых случаев использования, когда требуется большое число подписантов; к ним, вероятно, будут относиться случаи использования корпоративных сокровищ, бирж и кастодиальных услуг.
Оценив код и взвесив все за и против этой поправки, Ripple решила настроить свои валидаторы на голосование в поддержку ExpandedSignerList. Хотя мы признаем, что увеличение вычислительных затрат для нескольких транзакций вполне вероятно, мы считаем, что это не должно стать проблемой для сети.
NonFungibleTokensV1_1
NonFungibleTokensV1_1 — это последняя поправка, связанная с XLS-20: Предложение компании Ripple по внедрению в XRPL поддержки NFT (непередаваемых токенов). Мы уже писали о XLS-20 ранее и даже опубликовали результаты собственных тестов производительности.
В целом, внедрение XLS-20 расширит возможности XRP Ledger, сделав возможным разработку сценариев использования на основе NFT. Ожидается, что новая функциональность приведет к росту состояния бухгалтерской книги, поскольку придется отслеживать больше элементов и выполнять больше транзакций. Хотя авторы спецификации XLS-20 постарались минимизировать накладные расходы на каждый отдельный NFT, они все равно остаются значительными. Кроме того, встроенный NFT DEX вносит дополнительные накладные расходы.
Наши ранее опубликованные результаты тестирования показывают, что обработка транзакций на основе NFT менее эффективна, чем обработка прямых платежей XRP (что неудивительно, поскольку прямые платежи XRP являются простейшими операциями по своей конструкции), но наше тестирование и опыт показывают, что код способен обрабатывать транзакции, значительно превышающие те, которые в настоящее время наблюдаются в XRP Ledger.
Тем не менее, активация поправки NonFungibleTokensV1_1, вероятно, приведет к увеличению пропускной способности транзакций и росту состояния бухгалтерской книги, потенциально значительному. Некоторые серверы (особенно те, которые работают на системах, не отвечающих рекомендованным требованиям) могут почувствовать эффект от активации сильнее. Как правило, серверы должны быть сконфигурированы с очень быстрым твердотельным накопителем и большим количеством оперативной памяти.
Еще одно дополнительное соображение, касающееся поправки NonFungibleTokensV1_1 — это ажиотаж вокруг введения этой функциональности. Несколько проектов, некоторые из которых сотрудничают с Ripple, публично заявили о готовности выпускать NFT на XRP Ledger. Большинство из них в первую очередь нацелены на развлекательные или коллекционные сценарии использования, но другие рассматривают НФТ для поддержки таких полезных сценариев использования, как углеродные кредиты, проверка происхождения товаров, игры и многое другое.
Оценив код и взвесив все за и против потенциального влияния этой поправки на XRP Ledger, Ripple решила настроить свои валидаторы на голосование в поддержку NonFungibleTokensV1_1. Мы уверены в готовности сети к XLS-20 и в потенциальных новых сценариях использования, которые она может вдохновить в результате работы, проделанной большей частью сообщества, и их публичной приверженности XRPL-родным НФТ. Мы понимаем, что у некоторых операторов могут возникнуть сомнения, и ценим их консервативный, взвешенный и осторожный подход.
Ripple также продолжит проводить тесты производительности, чтобы помочь нам и сообществу лучше понять потенциальное влияние этой поправки. Мы также продолжим выделять инженерные ресурсы для разработки и внесения улучшений производительности, направленных на компенсацию дополнительного роста состояния бухгалтерской книги, пропускной способности транзакций и нагрузки, которые, как ожидается, будут сопровождать активацию поддержки NFT.
Заключительные мысли
Хотя эта заметка призвана пролить свет на решения Ripple по голосованию, мы не занимаем никакой позиции относительно того, как должны голосовать другие операторы валидаторов, когда речь идет о принятии какой-либо поправки.
Однако мы считаем, что процесс принятия поправок очень важен и играет решающую роль в руководстве дальнейшим развитием XRP Ledger. Поэтому мы считаем, что операторы валидаторов должны быть активными и вовлеченными участниками процесса принятия поправок, и призываем их оценивать предлагаемые поправки, используя критерии, которые они считают важными.
Голосование
Чтобы проголосовать за определенную поправку, необходимо выполнить следующую команду:
/opt/ripple/bin/rippled feature NAME accept
Чтобы проголосовать против конкретной поправки, нужно выполнить следующую команду:
/opt/ripple/bin/rippled feature NAME reject
Вопросы, комментарии и здоровые дебаты приветствуются в комментариях ниже.
Следите за @RippleXDev в Twitter.