Les développeurs du XRP Ledger ont proposé une nouvelle mise à jour du protocole de prêt qui corrigerait l'arrondi des remboursements de prêts, empêchant de petites différences de calcul de s'accumuler au fil des échéances programmées.
Résumé
- Les développeurs du XRP Ledger ont proposé des modifications de l'arrondi des remboursements dans le cadre de l'amendement LendingProtocolV1_2 prévu pour le prêt natif.
- La correction empêcherait les différences d'arrondi accumulées de faire dépasser aux dernières échéances du prêt les montants programmés.
- Les développeurs ont testé les calculs de remboursement sur les coffres Legacy, CashBasis et FixedPrecision sous plusieurs configurations d'amendement différentes.
- Les prêts existants comportant des différences d'arrondi peuvent les conserver, sauf si les emprunteurs effectuent des trop-payés éligibles lors du remboursement.
- LendingProtocolV1_2 reste en cours de développement, son activation sur le mainnet nécessitant un soutien soutenu des validateurs de confiance du XRP Ledger.
La proposition GitHub du 6 novembre introduit des changements dans le cadre de l'amendement LendingProtocolV1_2 prévu, qui alignerait les soldes de prêts impayés sur leurs échéanciers de remboursement. La correction traite les cas où les différences d'arrondi peuvent laisser la dernière échéance légèrement supérieure au montant que les emprunteurs étaient initialement censés payer.
La proposition reste en cours d'examen et n'a pas été activée sur le mainnet du XRP Ledger. Les développeurs ont inclus des tests couvrant différentes méthodes de comptabilité des coffres, les prêts existants et les situations où les emprunteurs paient plus que leurs échéances programmées.
La correction du prêt du XRP Ledger cible l'arrondi des remboursements
Au cœur de la proposition se trouve la manière dont le XRP Ledger calcule le montant restant dû après que les emprunteurs ont effectué des paiements sur un prêt.
Selon le calcul existant décrit par le développeur, la valeur de chaque échéance est calculée séparément. De petites différences d'arrondi peuvent s'accumuler au fur et à mesure des paiements, laissant occasionnellement la dernière échéance une unité plus élevée que le paiement périodique arrondi.
La correction proposée introduit une méthode de calcul connue sous le nom de télescopage, qui utilise l'échéancier de remboursement restant pour déterminer le solde impayé après chaque échéance.
Plutôt que de permettre aux calculs individuels de produire des différences cumulatives, le système ramènerait la valeur impayée en conformité avec les paiements programmés restants.
Sous LendingProtocolV1_2, chaque transaction LoanPay effectuée à temps réduirait TotalValueOutstanding au montant programmé avec un paiement de moins restant. L'ajustement resterait plafonné au PeriodicPayment arrondi.
La description du développeur indique que le changement rendrait la partie valeur de chaque échéance programmée égale soit au paiement périodique arrondi à l'inférieur, soit à celui arrondi au supérieur, tout en le maintenant à au moins une unité.
La dernière échéance correspondrait alors exactement au PeriodicPayment arrondi pour les prêts suivant l'échéancier corrigé.
Les développeurs ajustent les calculs de LoanSet et LoanPay
Les modifications de code proposées concernent LoanSet, qui établit les conditions du prêt, et LoanPay, qui traite les remboursements sur le registre.
Le premier commit déplace le calcul de la valeur programmée d'un prêt hors de computeLoanProperties vers une fonction distincte appelée scheduledValue.
Les développeurs ont indiqué que cet ajustement initial ne modifie pas le comportement existant. Son objectif est de garantir que la création de prêt et le traitement des remboursements utilisent la même méthode d'arrondi.
Un second commit introduit la correction du remboursement sous LendingProtocolV1_2, incluant des ajustements du solde restant chaque fois qu'un emprunteur effectue un trop-payé accepté.
Après un tel paiement, TotalValueOutstanding serait réinitialisé à la valeur programmée calculée à l'aide du PeriodicPayment révisé, permettant aux échéances suivantes de suivre l'échéancier mis à jour.
La proposition inclut des garde-fous pour la partie principal de chaque échéance, empêchant les calculs de laisser un montant négatif d'intérêts impayés.
Les prêts à intérêt zéro nécessitent un traitement séparé car la valeur totale du prêt utilise un arrondi à l'unité la plus proche, tandis que le montant du principal est arrondi au supérieur.
Les développeurs ont testé les modifications sur les modèles de comptabilité de coffre Legacy, CashBasis et FixedPrecision, avec et sans l'amendement proposé activé.
Les prêts existants sur le XRP Ledger conserveraient certaines différences d'arrondi
Bien que les modifications proposées corrigeraient les calculs de remboursement à l'avenir, elles n'élimineraient pas automatiquement toutes les différences d'arrondi liées aux prêts existants.
La proposition GitHub explique que les prêts plus anciens portant déjà une unité au-dessus de leur solde prévu conserveraient cette différence jusqu'à ce que l'emprunteur effectue un paiement excédentaire.
Ces prêts pourraient donc encore nécessiter un versement final égal au PeriodicPayment arrondi plus une unité supplémentaire.
Les petits paiements excédentaires peuvent être ignorés lorsqu'ils se situent dans les limites d'arrondi existantes. Dans ces cas, la transaction peut renvoyer un résultat réussi sans facturer un paiement de prêt supplémentaire.
Le développeur a inclus des tests couvrant l'activation de l'amendement pendant qu'un prêt reste en cours, permettant de vérifier les calculs révisés par rapport aux enregistrements de remboursement existants.
Ces ajustements concernent la comptabilité des prêts au sein du protocole de prêt proposé. Ils ne modifient pas les transferts ordinaires de XRP ni n'établissent un nouveau produit d'emprunt disponible pour tous les détenteurs de XRP.
LendingProtocolV1_2 nécessite toujours l'approbation des validateurs
La proposition de remboursement fait partie des travaux en cours du XRP Ledger sur le prêt natif, qui permettrait des prêts à terme fixe financés par des Single Asset Vaults.
En septembre, crypto.news a couvert les modifications de prêt introduites dans la version 3.4.0 du XRP Ledger, y compris les coffres à échéance fermée et la comptabilité de trésorerie sous LendingProtocolV1_1.
Le cadre de prêt proposé utiliserait des actifs mis en commun pour financer les prêts, tandis que les courtiers évalueraient les emprunteurs et géreraient le risque de crédit en dehors de la blockchain.
Un examen du vote des validateurs en octobre a révélé que les amendements sur le prêt et les coffres n'avaient pas obtenu le soutien requis pour être activés.
Pendant ce temps, un amendement de maintenance distinct a été activé le 4 novembre, traitant plusieurs problèmes de traitement des transactions sans activer le protocole de prêt.
Selon le processus d'amendement du XRP Ledger, une modification proposée doit recevoir le soutien de plus de 80 % des validateurs de confiance pendant deux semaines consécutives avant son activation.
La pull request #8698 reste ouverte, et aucune date d'activation sur le mainnet n'a été annoncée pour LendingProtocolV1_2.
