Кратко: Два открытых предложения для XRP Ledger касаются проверок авторизации для токенов пулов ликвидности и существующих остатков на доверительных линиях. Эти изменения находятся на рассмотрении и не являются активными правилами сети.

Разработчики XRP Ledger рассматривают целевые изменения в способе проверки разрешений для выпущенных токенов в операциях по оплате и в пулах ликвидности. Текущая публичная версия кода содержит два соответствующих открытых предложения, оба из которых были предложены 27 октября.

Эта работа связана с запланированной поправкой Cleanup3_5_0. Ее следует рассматривать как разработку протокола, а не как завершенное обновление или доказательство того, что обычные переводы XRP теперь требуют одобрения эмитента.

Токены пулов могут представлять собой доступ к двум активам.

Первое открытое предложение, номер 8648, потребует, чтобы счет, получающий токен поставщика ликвидности, соответствовал требованиям авторизации для обоих активов, представленных в соответствующем автоматизированном маркет-мейкере.

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

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

Существующий остаток не должен создавать исключение.

Второе открытое предложение, номер 8650, касается проверки в платежном движке, которая ранее применялась, когда неавторизованная доверительная линия имела нулевой остаток. Предлагаемое поведение не позволит увеличить существующий неавторизованный остаток путем получения дополнительных средств.

В обсуждении кода проводится различие между получением токенов от эмитента и возвратом обязательства в обратном направлении. Это различие важно: предотвращение создания нового неавторизованного остатка не должно препятствовать законному погашению или восстановлению.

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

Проверка кода предшествует активации.

Документация по поправкам XRP Ledger объясняет, что изменения, влияющие на обработку транзакций, должны сначала быть включены в программное обеспечение, а затем получить устойчивую поддержку от валидаторов. Установленный порог составляет более 80% поддержки в течение двух недель.

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

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

Влияние затрагивает выпущенные активы и логику интеграции.

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

Наиболее полезная подготовка для затронутых интеграций – это определение путей, по которым клиент получает ограниченный актив, а затем выявление того, как приложение отображает ошибки авторизации и варианты погашения. Даже технически правильный отказ может запутать пользователей, если интерфейс представляет его как необъяснимую ошибку транзакции.

Сама по себе история разработки не доказывает, что внешний злоумышленник использовал рассматриваемые пути. Она демонстрирует предлагаемое усиление протокола.

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

Автор: Редакция новостей, отредактировано: Сэмюэл Рэй.