XRP Ledger (XRPL) приближается к активации обновления, которое позволит организациям разделить управление одним аккаунтом между несколькими делегированными аккаунтами, ограничив возможности любого отдельного операционного ключа.

PermissionDelegationV1_1 предназначена для организаций, которые обрабатывают транзакции часто, но не хотят, чтобы в повседневных операционных системах использовались ключи, способные управлять целым аккаунтом. Например, эмитенту стейблкоина может понадобиться одна система для одобрения trust line клиентов (механизма реестра для хранения выпущенных активов), другая — для обработки платежей, и более защищенная конфигурация — для управления безопасностью аккаунта. Поправка позволит разделить эти обязанности между отдельными аккаунтами XRPL.

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

XRPL будет обеспечивать исполнение каждого разрешения на уровне блокчейна

Согласно спецификации XLS-75, аккаунт, передающий полномочия, является делегатором. Он отправляет транзакцию DelegateSet, называя второй аккаунт и действия, которые тот может выполнять. Эта связь хранится в записи Delegate в реестре.

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

В официальной документации перечислены разрешения по типам транзакций и более узкие гранулярные разрешения; каждый делегат может получить не более десяти. Доступные гранулярные управления предопределены, поэтому организации не могут создавать любые ограничения по своему усению. Делегаты также должны поддерживать аккаунты с балансом, а каждая делегация создает объект в блокчейне, увеличивающий требование owner-reserve делегатора — минимальный объем XRP, который аккаунт должен удерживать за каждый принадлежащий ему объект реестра.

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

Двадцать девять голосов запустили условный обратный отсчет

PermissionDelegationV1_1 вступила в 14-дневный период активации 21 сентября с поддержкой 29 из 35 доверенных валидаторов XRP Ledger, согласно онлайн-трекеру поправок. Поправки — это встроенный механизм реестра для изменения его правил, и именно устойчивая поддержка валидаторов переносит новый код протокола в mainnet. Не менее 28 валидаторов должны продолжать поддержку; падение ниже этого уровня сбросит таймер. Сообщается со ссылкой на CoinDesk, что ожидаемое время активации — 5 октября в 11:18 UTC, при условии непрерывности поддержки.

Код уже существует в серверном программном обеспечении XRPL, но его нельзя использовать в mainnet до активации. Отдельная поправка Batch V1.1 проходит тот же двухнедельный процесс, хотя она касается связанных транзакций, а не полномочий на аккаунт.

Делегирование не заменяет мультисигнатуру

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

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

Первая версия не прошла до выхода в mainnet

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

Уязвимость была обнаружена во время тестирования, и поправка никогда не активировалась в mainnet. В официальном раскрытии информации об уязвимости сообщается об отсутствии потерь средств реальных пользователей.

Coindoo ранее разбирал, почему Permission Delegation вернулась в переработанном виде среди поправок xrpld 3.3.0. Новое голосование показывает, что валидаторы теперь готовы рассмотреть активацию замены.

Активация не будет означать институциональное принятие

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

Решения по комплаенсу также останутся за пределами реестра. Компания по-прежнему будет проводить проверку личности, санкционный скрининг и оценку рисков через собственные системы. XRPL обеспечит контроль того, какой делегат может отправить итоговую авторизацию; он не будет определять, следовало ли одобрить клиента.

Использование функции будет видно через публичные записи Delegate, хотя привязка адреса к компании может потребовать добровольного раскрытия информации. Делегированным аккаунтам также нужен XRP для резервов и комиссий, но активация не создает объема использования или автоматического спроса на токен.

Следующим тестом станет производственное использование

Если поддержка валидаторов сохранится, доказательства придут из интеграций с кошельками, новых записей Delegate и именованных развертываний. Эти сигналы покажут, нуждаются ли организации в разделении на уровне протокола между владением аккаунтом и повседневными операциями.

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

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