Разработчики XRP Ledger рассматривают два исправления авторизации перед голосованием валидаторов

3 мин

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

Разработчики XRP Ledger изучают изменения в проверках прав для выпускаемых токенов при платежах и в операциях автоматизированного маркет-мейкера. Два открытых предложения были внесены 27 октября и связаны с запланированным amendment fixCleanup3_5_0. Это разработка протокола, а не завершённое обновление, и она не означает, что для обычных переводов XRP требуется одобрение эмитента.

Токены пулов несут экспозицию к двум активам

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

Наличие остатка не должно давать исключение

Второе открытое предложение №8650 пересматривает проверку в платежном движке, которая ранее применялась, когда неавторизованная trust line имела нулевой баланс. Предложенное поведение: блокировать любое увеличение существующего неавторизованного остатка за счёт новых поступлений, при этом разрешая возвраты, уменьшающие обязательства. Два более широких связанных предложения закрыты, поэтому текущие открытые изменения точнее определяют вероятный объём работ, чем более ранние резюме четырёх исправлений.

Перед активацией — код-ревью

Согласно процессу amendments в XRP Ledger: изменения, влияющие на транзакции, должны выйти в составе ПО, а затем получить более 80% поддержки валидаторов на протяжении двух недель. Открытые pull request’ы не удовлетворяют этим условиям. Дизайн может меняться на этапе ревью, релизы могут включать пункты или откладывать их, а решение об активации принимают валидаторы. Разработчикам приложений следует тестировать предлагаемые поведения отдельно от предположений о продакшене, поскольку в сети транзакции пока могут не возвращать ожидаемые ошибки.

Влияние — на выпускаемые активы и интеграционную логику

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

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

Материал подготовлен News Desk, редактор — Samuel Rae.