Les développeurs du XRP Ledger ont publié la version 3.4.0 de xrpld le 16 septembre, ajoutant deux packages d'amendements qui révisent les fonctions de prêt natif proposées et renforcent plusieurs chemins de transaction tout en demandant aux opérateurs de serveurs de mettre à niveau.
Résumé
- La version 3.4.0 de XRPL introduit deux amendements couvrant les modifications de prêt ainsi qu'un package groupé de correctifs de protocole désormais.
- LendingProtocolV1_1 ajoute des coffres fermés et une comptabilité de trésorerie, mais l'activation sur le mainnet nécessite toujours un consensus soutenu des validateurs.
- Les opérateurs de serveurs sont invités à mettre à niveau rapidement, car la Fondation XRPL distribue désormais des packages Linux signés.
- fixCleanup3_4_0 renforce les coffres, les AMM, les MPT, les séquestres, la signature, les identifiants et le comportement de trading permissionné sur tous les chemins de transaction.
- Le nouvel amendement de prêt dépend de XLS-65 et XLS-66, qui restent en dessous des seuils d'activation.
La publication officielle de XRPL indique que la version 3.4.0 introduit LendingProtocolV1_1 et fixCleanup3_4_0, tout en retirant fixAMMOverflowOffer après que son comportement post-amendement soit devenu une partie permanente du protocole.
La publication du logiciel ne signifie pas que l'un ou l'autre des nouveaux amendements est actif sur le mainnet. Le processus d'amendement de XRPL exige qu'une proposition reçoive plus de 80 % de soutien de la part des validateurs de confiance de manière continue pendant deux semaines avant que ses règles ne deviennent actives.
Lending V1.1 ajoute des coffres fermés et une comptabilité de trésorerie
La publication de la version 3.4.0 de XRPL indique que LendingProtocolV1_1 modifie la conception des coffres à actif unique et du protocole de prêt en introduisant des coffres fermés avec des périodes de souscription, d'investissement et de rachat définies.
La documentation technique de Ripple indique que les déposants peuvent ajouter ou retirer des actifs pendant la phase de souscription. Pendant la période d'investissement, les dépôts et les retraits s'arrêtent tandis que les actifs peuvent financer des prêts. Le rachat commence une fois la période d'investissement terminée, permettant aux déposants de récupérer leur part après l'échéance des prêts.
Une fois LendingProtocolV1_1 actif, la documentation de XRPL indique que les nouveaux courtiers en prêts ne peuvent être attachés qu'à des coffres fermés. Les relations de prêt existantes créées selon les règles antérieures bénéficient d'un traitement distinct afin que les positions en cours puissent continuer à être gérées.
Le modèle comptable change en même temps. La documentation de Ripple indique que les nouveaux coffres ne reconnaîtraient les intérêts que lorsque les emprunteurs effectuent réellement des paiements.
Selon le modèle précédent, tous les intérêts prévus étaient reconnus à l'origination du prêt. La comptabilité de trésorerie laisse les intérêts futurs impayés en dehors des revenus du coffre jusqu'à réception du paiement, ce qui affecte AssetsTotal, les calculs de dette de prêt et le traitement comptable des défauts.
Les règles V1.1 ne convertiraient pas rétroactivement les anciens coffres. La documentation de Ripple indique que les coffres créés selon la méthode comptable précédente conservent ce modèle après l'activation de V1.1.
Comme l'a rapporté une précédente couverture des amendements, le validateur de Ripple avait déjà voté pour les propositions sous-jacentes SingleAssetVault et LendingProtocol en août, mais l'approbation des validateurs restait bien en dessous du niveau requis pour l'activation sur le mainnet.
XRPL 3.4.0 regroupe un large ensemble de correctifs de transactions
Le deuxième amendement, fixCleanup3_4_0, contient des correctifs couvrant le prêt, les coffres-forts, les teneurs de marché automatisés, les jetons polyvalents, les NFT, le séquestre, le trading avec autorisation et l'autorisation de compte.
La version officielle indique qu'un changement empêche AMMClawback de brûler les jetons de fournisseur de liquidité d'un détenteur tout en récupérant zéro actif sous-jacent lorsque l'arrondi MPT réduit à zéro le montant de récupération calculé.
Un autre correctif renforce les invariants MPT. Les développeurs de XRPL ont déclaré que les vérifications ValidMPTBalanceChanges et ValidMPTTransfer, qui généraient auparavant des journaux, sont appliquées dans le cadre de l'amendement et continuent de s'appliquer lorsque les transactions échouent.
Pour les coffres-forts à actif unique, la version répertorie des changements de précision et d'arrondi pour les dépôts, les retraits et les récupérations. Les règles sont conçues pour maintenir l'alignement entre les actifs enregistrés, les actifs disponibles et l'offre de parts en circulation lorsque les conversions atteignent les limites de précision.
Le trading avec autorisation reçoit plusieurs corrections. Le paquet exclut les offres de domaine supprimées d'un invariant du DEX avec autorisation, resserre les vérifications de domaine et corrige la manière dont les identifiants expirés sont supprimés lorsque les transactions OfferCreate ou Payment s'exécutent.
Le comportement de signature reçoit une sauvegarde distincte. La version indique que la version 3.4.0 attribue des préfixes de hachage de signature différents aux signatures de contrepartie et de parrain afin qu'une signature créée pour un rôle ne puisse pas être rejouée comme l'autre.
La version contient un renforcement des nœuds de niveau inférieur en dehors du paquet d'amendements. Les développeurs ont corrigé une recherche de base de données non bornée via TMGetLedger, plafonné la taille des listes TMTransactions entrantes et introduit des frais pour les transactions qui ne peuvent pas être désérialisées.
Les développeurs de XRPL ont déclaré que la version 3.4.0 intègre les correctifs de la première phase issus des conclusions des audits et de l'attackathon MPT et DEX. La version n'identifie pas ces correctifs comme la preuve d'un exploit actif sur le mainnet.
Dans notre couverture précédente des mises à niveau, la version 3.3.0 avait déjà introduit du code pour plusieurs propositions distinctes, notamment la fonctionnalité Batch corrigée, les frais parrainés et les transferts MPT confidentiels, l'approbation des validateurs étant toujours requise avant l'activation.
L'approbation des validateurs sépare toujours la version de l'activation
Les règles officielles d'amendement de XRPL stipulent que l'installation d'un logiciel contenant un amendement ne donne à un serveur que le code nécessaire pour comprendre les règles proposées. Les validateurs choisissent séparément s'ils votent pour l'activation.
Le code actuel des fonctionnalités de la XRPLF répertorie à la fois LendingProtocolV1_1 et fixCleanup3_4_0 comme pris en charge tout en conservant le comportement de vote DefaultNo. Un paramètre default-no signifie que l'exécution du logiciel ne vote pas en soi en faveur de l'amendement lorsqu'un opérateur n'a pas configuré d'autre choix.
Les composants de prêt sous-jacents restent en deçà de l'activation. Un instantané du 17 septembre basé sur les données d'historique des validateurs de la XRPL Foundation montrait que 16 des 35 validateurs de confiance soutenaient SingleAssetVault et 13 des 35 soutenaient LendingProtocol.
Ces chiffres sont sensibles au temps et proviennent d'un traqueur de réseau indépendant, et non d'un chiffre fixe publié dans les notes de version. La règle officielle reste un soutien supérieur à 80 % maintenu pendant deux semaines consécutives.
Le nouvel amendement V1.1 dépend de l'architecture de prêt sous-jacente. La spécification actuelle XLS-66 décrit un prêt à durée déterminée et non garanti utilisant des fonds mis en commun via des coffres-forts à actif unique, tandis que l'évaluation de l'emprunteur et l'évaluation du risque de crédit restent hors chaîne.
La même spécification reste classée comme brouillon. Aucune source examinée pour cette mise à jour n'a montré de prêt sur mainnet exécuté via le protocole natif proposé ni de date d'activation pour LendingProtocolV1_1.
Les opérateurs de nœuds reçoivent désormais les paquets de la XRPL Foundation
La version 3.4.0 modifie le chemin de distribution des paquets de serveur Linux. La version officielle indique que les paquets Debian et RPM sont désormais hébergés via packages.xrplf.org et signés avec une clé de la XRPL Foundation.
Les développeurs du XRPL ont exhorté les opérateurs de serveurs à installer la version 3.4.0 « dès que possible » afin de maintenir la continuité du service. Les fichiers DEB et RPM publiés incluent des sommes de contrôle SHA-256 afin que les opérateurs puissent vérifier les paquets téléchargés avant l'installation.
GitHub répertorie désormais la version 3.4.0 comme la dernière version immuable de xrpld, liée au commit 4a4fded2eba11427c48ce3f24d9c1aea5e7a9d17. Le dépôt indique que l'étiquette de version et le commit de version portent des signatures vérifiées.
La même version retire fixAMMOverflowOffer. Selon le modèle d'amendement du XRPL, le retrait n'annule pas le correctif. Il supprime le comportement obsolète d'avant l'amendement après que les nouvelles règles sont devenues établies comme comportement permanent du protocole.
Le support client et l'examen de sécurité sont encore en cours de développement
Les bibliothèques d'applications évoluent parallèlement à la version serveur. L'historique du client JavaScript de XRPLF répertorie le support de LendingProtocolV1_1 dans la section non publiée suivant xrpl.js 5.2.0, qui a été livré le 11 septembre.
L'historique de binary-codec montre que la version 2.11.0 contient déjà les préfixes de signature de sponsor et de contrepartie spécifiques au rôle utilisés par fixCleanup3_4_0, ainsi que les définitions de protocole générées à partir de xrpld 3.4.0.
Les tests de sécurité du travail sur le prêt se sont poursuivis indépendamment du vote des validateurs. Sherlock a déclaré dans une analyse du 27 août que Ripple avait commencé un examen uniquement par IA du Lending Protocol V1.1 via son Audit Engine.
Sherlock a déclaré qu'il publierait plus d'informations après la fin de l'examen, mais aucune conclusion finale sur la V1.1 n'a été trouvée dans ses documents publics consultés pour ce rapport. Des tests antérieurs portaient sur une version précédente du système de prêt ; une couverture d'audit indépendante antérieure rapportait que le ré-audit antérieur de Halborn n'avait trouvé aucun problème critique ou à haut risque tout en identifiant un problème moyen, deux faibles et deux constats informatifs.
