XRP News : Les développeurs de XRP Ledger s'attaquent à quatre failles de sécurité des tokens

Correctifs de Sécurité pour XRP Ledger

Les développeurs de XRP Ledger travaillent actuellement sur quatre correctifs de sécurité visant à empêcher les actifs numériques restreints d'atteindre des comptes non autorisés. Ces modifications répondent à des faiblesses potentielles dans une infrastructure de plus en plus utilisée pour la tokenisation institutionnelle. Les correctifs sont regroupés sous un amendement proposé, nommé fixCleanup3_5_0, dont la proposition de code sur GitHub a été mise à jour le 27 octobre.

Renforcement des Permissions des Tokens

Ces correctifs visent à renforcer les permissions des tokens contrôlés par les émetteurs lors des paiements, des transactions avec des teneurs de marché automatisés et d'autres opérations. La proposition se concentre sur les tokens nécessitant une autorisation explicite de l'émetteur avant qu'un compte puisse les détenir. Ces restrictions sont particulièrement pertinentes pour les stablecoins réglementés et les titres tokenisés, où les émetteurs doivent souvent vérifier l'identité des investisseurs ou appliquer des exigences d'éligibilité.

Problèmes Identifiés et Solutions Proposées

Dans l'architecture actuelle, l'approbation est enregistrée par une ligne de confiance reliant un compte à un émetteur de token. Cependant, les développeurs ont identifié plusieurs situations où les transactions pouvaient contourner les vérifications d'autorisation prévues. Un problème concerne les tokens de liquidité des teneurs de marché automatisés, qui représentent des droits sur des actifs déposés dans des pools de trading. La correction proposée exigerait que les destinataires aient une autorisation pour les deux actifs sous-jacents avant d'acquérir un token de pool.

Un autre problème concerne une exemption affectant les lignes de confiance avec des soldes existants. Auparavant, certaines vérifications ne s'appliquaient que lorsqu'une ligne de confiance ne détenait aucun token, permettant ainsi à un solde non autorisé d'augmenter par le biais de transactions ultérieures. L'ensemble du paquet vise également à empêcher les soldes de tokens non autorisés d'être utilisés dans des transferts autres que le rachat auprès de l'émetteur et à introduire des vérifications de cohérence supplémentaires.

Contexte et Importance des Changements

Ces changements font suite à des travaux antérieurs sur des pools de liquidité autorisés, où les développeurs ont exploré la restriction de la participation à des contreparties institutionnelles vérifiées. Les modifications proposées interviennent alors que les institutions financières traditionnelles élargissent leur utilisation de XRP Ledger pour les actifs numériques. Par exemple, BNY a récemment élargi ses capacités de garde pour XRP et RLUSD, tandis que Ripple a poursuivi des relations impliquant le règlement de stablecoins, les titres tokenisés et le financement institutionnel.

Pour les institutions réglementées, la capacité de contrôler quels comptes peuvent légalement recevoir ou détenir des actifs spécifiques est essentielle. Un émetteur distribuant des parts de fonds tokenisés, par exemple, doit s'assurer que ces tokens restent avec des investisseurs éligibles. Si une transaction sur le marché secondaire ou un mécanisme de pool de liquidité contourne les vérifications d'autorisation, les contrôles de conformité du système deviennent moins fiables.

Conclusion et Prochaines Étapes

Les correctifs proposés renforceraient ces protections sans modifier le modèle de propriété natif de XRP ni exiger que les détenteurs ordinaires de XRP obtiennent l'autorisation de l'émetteur. Ce travail fait également suite à une précédente publication de sécurité sur XRPL, qui a introduit des protections distinctes pour la fonctionnalité de transaction par lots du réseau. Les quatre changements n'ont pas encore été fusionnés dans le logiciel principal de XRP Ledger ni activés sur le mainnet. Une fois l'implémentation et l'examen terminés, l'amendement devra encore obtenir le soutien de plus de 80 % des validateurs de confiance pendant deux semaines consécutives avant son activation. Ce processus est distinct de la fenêtre de mise à niveau précédente du 4 novembre, qui concerne fixCleanup3_4_0 plutôt que le nouveau fixCleanup3_5_0 proposé.