Le XRP Ledger (XRPL) se rapproche de l'activation d'une mise à niveau qui permettrait aux organisations de répartir le contrôle d'un seul compte entre plusieurs comptes délégués, limitant ainsi le pouvoir d'une clé opérationnelle unique.

PermissionDelegationV1_1 est conçu pour les organisations qui traitent fréquemment des transactions mais ne souhaitent pas que des clés capables de contrôler un compte entier se trouvent dans leurs systèmes opérationnels quotidiens. Un émetteur de stablecoin, par exemple, peut avoir besoin d'un système pour approuver les lignes de confiance des clients (le mécanisme du registre pour détenir des actifs émis), d'un autre pour traiter les paiements, et d'une configuration plus protégée pour gérer la sécurité du compte. L'amendement permettrait de répartir ces tâches entre plusieurs comptes XRPL distincts.

Son élément « à la banque » réside dans la séparation des responsabilités. Cela n'indique pas une approbation réglementaire ni une adoption confirmée par une banque. Un délégué compromis pourrait toujours être exploité dans le cadre de son rôle attribué, mais l'attaquant ne recevrait pas automatiquement tous les pouvoirs détenus par le compte principal, réduisant ainsi les dommages potentiels d'une seule clé opérationnelle exposée.

XRPL ferait respecter chaque autorisation onchain

Selon la spécification XLS-75, le compte qui attribue l'autorité est le délégant. Il soumet une transaction DelegateSet désignant un second compte et les actions que ce compte peut effectuer. La relation est stockée dans une entrée Delegate du registre.

Le délégué signe avec ses propres clés, identifie le compte pour lequel il agit et paie les frais de transaction. XRPL rejette les demandes sortant de l'autorité enregistrée, et le délégant peut ultérieurement mettre à jour ou supprimer cette autorité.

La documentation officielle répertorie les autorisations par type de et des autorisations granulaires plus étroites, et chaque délégué ne peut en recevoir plus de dix. Les contrôles granulaires disponibles sont prédéfinis, de sorte que les organisations ne peuvent pas créer n'importe quelle restriction. Les délégués doivent également maintenir des comptes financés, tandis que chaque délégation crée un objet onchain qui augmente l'exigence de réserve du propriétaire du délégant, c'est-à-dire le minimum de XRP qu'un compte doit détenir pour chaque objet du registre qu'il possède.

Les pouvoirs sensibles, notamment le changement des clés de signature ou la nomination de nouveaux délégués, ne peuvent pas être délégués. Les transactions qui ne peuvent pas entrer immédiatement dans le registre ouvert échouent également au lieu d'entrer dans la file d'attente.

Vingt-neuf votes ont lancé un compte à rebours conditionnel

PermissionDelegationV1_1 est entré dans sa période d'activation de 14 jours le 21 septembre avec le soutien de 29 des 35 validateurs de confiance du XRP Ledger, selon le suivi en direct des amendements. Les amendements sont le mécanisme intégré du registre pour modifier ses règles, et un soutien soutenu des validateurs est ce qui amène le nouveau code de protocole sur le mainnet. Au moins 28 validateurs doivent continuer à le soutenir, et un passage en dessous de ce niveau réinitialiserait le compte à rebours. CoinDesk a rapporté une heure d'activation prévue le 5 octobre à 11h18 UTC, à condition que le soutien reste ininterrompu.

Le code existe déjà dans le logiciel serveur XRPL, mais il ne peut pas être utilisé sur le mainnet avant l'activation. L'amendement distinct Batch V1.1 suit le même processus de deux semaines, bien qu'il concerne les transactions liées plutôt que l'autorité des comptes.

La délégation ne remplace pas la multisignature

La multisignature détermine combien de parties approuvées doivent autoriser une action, tandis que la délégation d'autorisations limite les actions qu'un compte opérationnel peut demander. Une organisation pourrait combiner les deux en restreignant un délégué aux paiements tout en exigeant que plusieurs personnes approuvent chaque paiement.

Après une compromission de clé, la multisignature peut empêcher un signataire volé seul d'atteindre le seuil d'approbation, tandis que la délégation peut restreindre les types de transactions disponibles pour l'attaquant même après la compromission du compte délégué. Aucun de ces contrôles ne vérifie que l'instruction commerciale est légitime.

La version originale a échoué avant d'atteindre le mainnet

Un testeur de la communauté a découvert que la première implémentation de PermissionDelegation pouvait, dans certaines conditions, facturer des frais de transaction à un autre compte même lorsque la transaction déléguée était incorrectement signée. Des soumissions répétées à frais élevés auraient pu réduire le solde XRP de la victime sans révéler sa clé privée.

La faille a été découverte pendant les tests, et l'amendement n'a jamais été activé sur le mainnet. La ulgation officielle de vulnérabilité n'a signalé aucune perte de fonds d'utilisateurs réels.

Coindoo a précédemment examiné pourquoi Permission Delegation est revenu sous une forme révisée avec les amendements xrpld 3.3.0. Le nouveau vote montre que les validateurs sont désormais disposés à envisager l'activation du remplacement.

L'activation n'établira pas l'adoption institutionnelle

Les portefeuilles et les fournisseurs de garde doivent encore créer des interfaces pour créer, examiner et révoquer l'autorité déléguée. Aucun déploiement bancaire nommé n'a été annoncé, et les institutions restent responsables de décider quels comptes reçoivent chaque autorisation.

Les décisions de conformité resteraient également hors du registre. Une entreprise continuerait d'effectuer les vérifications d'identité, le filtrage des sanctions et les examens des risques via ses propres systèmes. XRPL ferait respecter quel délégué peut soumettre l'autorisation résultante ; il ne déterminerait pas si le client aurait dû être approuvé.

L'utilisation de la fonctionnalité serait visible via les entrées Delegate publiques, bien que lier une adresse à une entreprise puisse nécessiter une divulgation volontaire. Les comptes délégués ont également besoin de XRP pour les réserves et les frais, mais l'activation n'établit aucun volume d'utilisation ni aucune demande automatique pour le token.

L'utilisation en production devient le prochain test

Si le soutien des validateurs se maintient, les preuves viendront des intégrations de portefeuilles, des nouvelles entrées Delegate et des déploiements nommés. Ces signaux montreront si les organisations ont besoin d'une séparation au niveau du protocole entre la propriété des comptes et les opérations quotidiennes.

Le vote rend possible l'accès limité aux comptes. Sa valeur dépendra de la précision avec laquelle les organisations configurent ces autorisations et de leur utilisation de la fonctionnalité en dehors des démonstrations.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier, juridique ou de sécurité. Le soutien des validateurs et les délais d'activation peuvent changer.