Le XRP Ledger s'est rapproché de l'activation d'un ensemble de correctifs logiciels le 23 octobre après avoir obtenu les 29 votes de validateurs requis pour l'approbation, bien que son système de prêt prévu reste en dessous du seuil de vote du réseau.
Résumé
- Le dernier ensemble de correctifs de bugs du XRP Ledger a obtenu 29 votes de validateurs, atteignant le seuil d'approbation du réseau.
- La mise à jour pourrait être activée le 23 octobre si les validateurs maintiennent leur soutien tout au long de la période de vote requise de deux semaines.
- Le système de prêt prévu reste à 10 votes du seuil, tandis que sa fonctionnalité de coffre-fort de soutien nécessite huit votes supplémentaires.
- Les correctifs traitent des calculs de prêt, de la comptabilité des coffres-forts, de la gestion des jetons et d'autres problèmes de traitement des transactions sur l'ensemble du XRPL.
- La proposition de prêt soutiendrait des prêts à terme fixe sans garantie, en utilisant des courtiers pour évaluer la solvabilité des emprunteurs hors chaîne.
Selon le XRPL Dashboard, l'amendement connu sous le nom de fixCleanup3_4_0 avait reçu le soutien de 29 des 35 validateurs de la liste de confiance par défaut du réseau au 19 octobre. La proposition est en cours de sa période d'approbation requise de deux semaines, avec une activation prévue pour vendredi si ce soutien se maintient.
La mise à jour contient des correctifs affectant les transactions de jetons, la comptabilité des coffres-forts, les teneurs de marché automatisés et les processus liés au prêt. Son activation n'activerait pas le prêt sur le réseau car les principales propositions de prêt et de coffre-fort font l'objet de votes séparés.
L'amendement LendingProtocol avait 19 validateurs favorables, ce qui lui laisse 10 votes de moins que les 29 requis. SingleAssetVault, qui détiendrait les fonds utilisés pour les prêts, avait 21 votes et en nécessitait huit de plus.
Le correctif de bugs du XRP Ledger vise une activation le 23 octobre
L'amendement fixCleanup3_4_0 a atteint la majorité requise de validateurs le 9 octobre, entamant une période de 14 jours durant laquelle le soutien doit rester supérieur à 80 %.
Au point de contrôle du 19 octobre, la proposition avait accompli environ neuf jours de cette période d'attente. Le tableau de bord projetait le 23 octobre vers 09h34 UTC comme le moment où la période d'approbation requise prendrait fin.
L'activation réelle pourrait survenir peu après, car le XRP Ledger traite les décisions d'amendement à des intervalles désignés appelés registres de drapeau.
Selon la documentation sur les amendements du réseau, ces vérifications ont lieu tous les 256 registres. Une fois la période d'attente requise écoulée, le réseau enregistre la décision d'amendement et applique les règles mises à jour dans les registres suivants.
Sur l'instantané du 19 octobre du tableau de bord, le correctif avait exactement 29 votes, ne laissant aucun validateur de soutien supplémentaire au-delà du minimum requis. Si l'un de ces validateurs retirait son soutien avant la fin de la période d'attente, la proposition tomberait en dessous de la majorité nécessaire.
Selon les règles du XRPL, la perte de cette majorité redémarre la période d'approbation de deux semaines lorsque le soutien suffisant est rétabli. L'heure d'activation du 23 octobre est donc une projection, et non la confirmation que la mise à jour a déjà pris effet.
Les opérateurs de serveurs doivent exécuter un logiciel qui reconnaît les amendements approuvés. Selon la documentation du XRPL, les serveurs utilisant des versions plus anciennes sans le code nécessaire peuvent devenir bloqués par les amendements une fois que le réseau commence à appliquer les nouvelles règles.
Les développeurs du XRPL ont publié la version 3.4.0 du logiciel serveur xrpld le 16 septembre et ont conseillé aux opérateurs de mettre à niveau pour maintenir la compatibilité.
Le prêt du XRP Ledger reste à 10 votes de l'approbation
Bien que certaines parties du correctif en attente concernent le prêt, le service de prêt du réseau n'a pas reçu suffisamment de soutien des validateurs pour s'activer.
La proposition LendingProtocol, connue sous le nom de XLS-66, a obtenu 19 des 35 votes de validateurs de confiance lors de l'instantané du 19 octobre. Sa proposition complémentaire SingleAssetVault, XLS-65, a obtenu 21 votes. Les deux nécessitent le soutien d'au moins 29 validateurs pendant deux semaines consécutives avant d'entrer en vigueur.
Les propositions doivent être activées avant que le système de prêt prévu puisse fonctionner sur le mainnet du XRP Ledger. Même si les deux atteignaient immédiatement le nombre de votes requis, la règle d'attente de deux semaines signifie qu'elles ne pourraient pas être activées en même temps que le correctif du 23 octobre.
Un amendement distinct, LendingProtocolV1_1, a obtenu 19 votes de soutien. Introduit dans la version 3.4.0, il propose des modifications à la conception des coffres de prêt et à la comptabilisation des intérêts des prêts.
L'amendement supplémentaire exigerait que les nouveaux courtiers en prêts utilisent des coffres à durée déterminée, où les dépôts, les prêts et les retraits suivent des étapes définies.
La proposition divise ce processus en périodes de souscription, d'investissement et de remboursement.
Il modifierait la comptabilisation des intérêts afin que les revenus soient reconnus lorsque les emprunteurs effectuent réellement des paiements, au lieu d'enregistrer tous les intérêts prévus au début d'un prêt.
Ces modifications proposées restent soumises à l'approbation des validateurs.
En septembre, crypto.news a rapporté la publication du logiciel et de ses deux nouveaux amendements, en notant que la publication du code fonctionnel n'activait pas en soi les nouvelles règles de prêt.
Le dernier décompte des validateurs montre que la mise à jour de maintenance groupée progresse avant les fonctionnalités financières qu'elle soutient en partie.
La conception du prêt repose sur les courtiers pour la vérification des emprunteurs
Selon le système de prêt XRPL proposé, les déposants apporteraient des actifs à un coffre commun, et un courtier en prêts organiserait des prêts à terme fixe en utilisant ces fonds mis en commun.
Le registre enregistrerait les obligations de prêt, les remboursements et autres transactions associées.
Les emprunteurs n'auraient pas à fournir de garantie directement via le protocole.
Au lieu de cela, les courtiers en prêts évalueraient la situation financière des emprunteurs et leur capacité de remboursement à l'aide de vérifications effectuées en dehors de la blockchain. Cet arrangement confierait aux courtiers la responsabilité de décider quels emprunteurs sont admissibles et quelles conditions de prêt ils obtiennent.
La conception publiée comprend un mécanisme de protection optionnel appelé capital de première perte. Un courtier pourrait placer des actifs supplémentaires dans un compte séparé pour aider à couvrir les pertes lorsque les emprunteurs ne remboursent pas leurs prêts.
La protection dépendrait du montant mis à disposition. Elle ne garantirait pas que les déposants puissent récupérer tous leurs fonds après un défaut. La documentation de XRPL explique que le protocole ne fournit actuellement pas de gestion automatique des garanties sur la chaîne ni de liquidation.
Les courtiers en prêts auraient la possibilité de déclarer un prêt en défaut après qu'un emprunteur manque un paiement et que le délai de grâce pertinent expire.
Le protocole est destiné à soutenir les activités de prêt institutionnel utilisant XRP et d'autres actifs éligibles émis sur le registre. Ripple a soutenu le développement des propositions de prêt dans le cadre de son travail avec les institutions financières.
En août, Ripple a soutenu les deux amendements via son validateur alors qu'ils restaient en dessous du seuil d'activation.
Un ré-audit de sécurité du prêt distinct en juin n'a signalé aucun problème critique ou à haut risque dans les modifications examinées par la société de cybersécurité Halborn.
L'absence de constats critiques dans cet examen ne constituait pas une approbation du réseau ni une garantie contre de futurs problèmes logiciels.
La dernière mise à jour logicielle corrige les erreurs de coffre et de transaction
Les notes de version xrpld 3.4.0 du 16 septembre décrivent plusieurs corrections incluses dans fixCleanup3_4_0.
Une correction empêche certaines transactions de récupération de teneur de marché automatisée de détruire les jetons de fournisseur de liquidité d'un utilisateur lorsque l'arrondi entraînerait la récupération d'aucun actif sous-jacent.
D'autres modifications concernent les calculs utilisés lorsque les utilisateurs déposent ou retirent des fonds des coffres. Les correctifs sont conçus pour maintenir la cohérence entre les soldes d'actifs des coffres et le nombre de parts émises aux déposants lors des transactions.
Pour le prêt, les développeurs ont mis à jour les règles couvrant l'autorisation, les actifs gelés, les identifiants et les destinations de paiement. Les notes de version précisent des changements concernant la manière dont les défauts de prêt interagissent avec les gels d'actifs et la manière dont le protocole vérifie les retraits des coffres soumis à autorisation.
Des ajustements distincts concernent les transactions sur les échanges décentralisés soumis à autorisation, les offres de NFT et le traitement des séquestres. Une correction liée à la signature introduit des préfixes cryptographiques distincts pour différents rôles de signature. Ce changement empêche qu'une signature destinée à un rôle soit réutilisée dans un autre.
La version resserre également les restrictions sur certaines transactions de jetons et applique des contrôles qui étaient auparavant consignés uniquement dans les journaux logiciels. Ces corrections sont incluses dans la version logicielle mais nécessitent l'activation de l'amendement pertinent avant que ses nouvelles règles de transaction ne deviennent applicables sur le mainnet.
La version 3.4.0 modifie en outre la manière dont les paquets serveur compatibles sont distribués, avec des paquets d'installation Linux signés fournis par la XRPL Foundation.
L'avis de version de la fondation demande aux opérateurs de mettre à niveau leurs serveurs vers la version 3.4.0 afin de maintenir le service tandis que le réseau adopte les nouveaux amendements.
