Los desarrolladores de XRP Ledger han lanzado la versión xrpld 3.4.0 el 16 de septiembre, añadiendo dos paquetes de enmiendas que revisan las funciones de préstamo nativas propuestas y refuerzan varias rutas de transacción mientras piden a los operadores de servidores que actualicen.
Resumen
- La versión 3.4.0 de XRPL introduce dos enmiendas que cubren cambios en préstamos más un paquete de corrección de protocolo ahora.
- LendingProtocolV1_1 añade bóvedas cerradas y contabilidad de base de efectivo, pero la activación en la red principal aún requiere consenso sostenido de los validadores.
- Se insta a los operadores de servidores a actualizar rápidamente, ya que la Fundación XRPL ahora distribuye paquetes firmados para Linux.
- fixCleanup3_4_0 refuerza bóvedas, AMM, MPT, escrow, firma, credenciales y comportamiento de comercio con permisos en todas las rutas de transacción.
- La nueva enmienda de préstamos depende de XLS-65 y XLS-66, que permanecen por debajo de los umbrales de activación.
El lanzamiento oficial de XRPL dice que la versión 3.4.0 introduce LendingProtocolV1_1 y fixCleanup3_4_0, mientras retira fixAMMOverflowOffer después de que su comportamiento posterior a la enmienda se convirtiera en parte permanente del protocolo.
El lanzamiento del software no significa que ninguna de las nuevas enmiendas esté activa en la red principal. El proceso de enmiendas de XRPL requiere que una propuesta reciba más del 80% de apoyo de validadores de confianza de forma continua durante dos semanas antes de que sus reglas se activen.
Lending V1.1 añade bóvedas cerradas y contabilidad de efectivo
El lanzamiento 3.4.0 de XRPL dice que LendingProtocolV1_1 cambia el diseño de las Bóvedas de Activo Único y el Protocolo de Préstamos al introducir bóvedas cerradas con períodos definidos de suscripción, inversión y redención.
La documentación técnica de Ripple dice que los depositantes pueden añadir o retirar activos durante la fase de suscripción. Durante el período de inversión, los depósitos y retiros se detienen mientras los activos pueden financiar préstamos. La redención comienza una vez que termina el período de inversión, permitiendo a los depositantes recuperar su parte después de que maduren los préstamos.
Una vez que LendingProtocolV1_1 se active, la documentación de XRPL dice que los nuevos corredores de préstamos solo pueden adjuntarse a bóvedas cerradas. Las relaciones de préstamo existentes creadas bajo reglas anteriores reciben un manejo separado para que las posiciones pendientes puedan seguir gestionándose.
El modelo contable cambia al mismo tiempo. La documentación de Ripple dice que las nuevas bóvedas reconocerían intereses solo cuando los prestatarios realmente realicen pagos.
Bajo el modelo anterior, todos los intereses programados se reconocían cuando se originaba un préstamo. La contabilidad de base de efectivo deja los intereses futuros impagos fuera de los ingresos de la bóveda hasta que llegue el pago, afectando AssetsTotal, los cálculos de deuda de préstamos y el tratamiento contable de los incumplimientos.
Las reglas de V1.1 no convertirían retroactivamente bóvedas más antiguas. La documentación de Ripple dice que las bóvedas creadas bajo el método contable anterior conservan ese modelo después de la activación de V1.1.
Como informó anteriormente la cobertura de enmiendas, el validador de Ripple ya había votado por las propuestas subyacentes SingleAssetVault y LendingProtocol en agosto, pero la aprobación de los validadores permaneció muy por debajo del nivel requerido para la activación en la red principal.
XRPL 3.4.0 incluye un gran conjunto de correcciones de transacciones
La segunda enmienda, fixCleanup3_4_0, contiene correcciones que abarcan préstamos, bóvedas, creadores de mercado automatizados, tokens multipropósito, NFT, depósito en garantía, comercio con permisos y autorización de cuentas.
La versión oficial dice que un cambio evita que AMMClawback queme los tokens de proveedor de liquidez de un titular mientras recupera cero activos subyacentes cuando el redondeo de MPT reduce el monto de recuperación calculado a cero.
Otra corrección refuerza las invariantes de MPT. Los desarrolladores de XRPL dijeron que las comprobaciones ValidMPTBalanceChanges y ValidMPTTransfer, que anteriormente generaban registros, se aplican bajo la enmienda y continúan aplicándose cuando las transacciones fallan.
Para las bóvedas de activo único, la versión enumera cambios de precisión y redondeo en depósitos, retiros y recuperaciones. Las reglas están diseñadas para mantener alineados los activos registrados, los activos disponibles y la oferta de participaciones en circulación cuando las conversiones alcanzan los límites de precisión.
El comercio con permisos recibe varias correcciones. El paquete excluye las ofertas de dominio eliminadas de una invariante del DEX con permisos, refuerza las comprobaciones de dominio y corrige cómo se eliminan las credenciales caducadas cuando se ejecutan transacciones OfferCreate o Payment.
El comportamiento de firma recibe una salvaguarda separada. La versión dice que la versión 3.4.0 asigna diferentes prefijos de hash de firma a las firmas de contraparte y patrocinador para que una firma creada para un rol no pueda reproducirse como el otro.
La versión contiene endurecimiento de nodos de nivel inferior fuera del paquete de enmiendas. Los desarrolladores corrigieron una búsqueda ilimitada en la base de datos a través de TMGetLedger, limitaron el tamaño de las listas entrantes de TMTransactions e introdujeron una tarifa para las transacciones que no se pueden deserializar.
Los desarrolladores de XRPL dijeron que la versión 3.4.0 incorpora correcciones de la primera fase derivadas de los hallazgos de auditoría y attackathon de MPT y DEX. La versión no identifica esas correcciones como evidencia de un exploit activo en la red principal.
En cobertura de actualización anterior, la versión 3.3.0 ya había introducido código para varias propuestas separadas, incluida la funcionalidad Batch corregida, tarifas patrocinadas y transferencias MPT confidenciales, con la aprobación de los validadores aún requerida antes de la activación.
La aprobación de los validadores aún separa la versión de la activación
Las reglas oficiales de enmiendas de XRPL establecen que instalar software que contiene una enmienda solo le da a un servidor el código necesario para comprender las reglas propuestas. Los validadores eligen por separado si votan por la activación.
El código actual de características de XRPLF enumera tanto LendingProtocolV1_1 como fixCleanup3_4_0 como compatibles mientras mantiene el comportamiento de voto DefaultNo. Una configuración predeterminada en no significa que ejecutar el software no emita por sí mismo un voto afirmativo de enmienda cuando un operador no ha configurado otra opción.
Los componentes subyacentes de préstamos aún no alcanzan la activación. Una instantánea del 17 de septiembre basada en datos del historial de validadores de la Fundación XRPL mostró que 16 de 35 validadores de confianza apoyaban SingleAssetVault y 13 de 35 apoyaban LendingProtocol.
Esos recuentos son sensibles al tiempo y provienen de un rastreador de red independiente, no de una cifra fija publicada en las notas de la versión. La regla oficial sigue siendo más del 80% de apoyo mantenido durante dos semanas continuas.
La nueva enmienda V1.1 depende de la arquitectura subyacente de préstamos. La especificación actual de XLS-66 describe préstamos a plazo fijo y sin garantía utilizando fondos agrupados a través de bóvedas de activo único, mientras que la suscripción de prestatarios y la evaluación del riesgo crediticio permanecen fuera de la cadena.
La misma especificación sigue clasificada como Borrador. Ninguna fuente revisada para esta actualización mostró un préstamo en la red principal ejecutado a través del protocolo nativo propuesto ni una fecha de activación para LendingProtocolV1_1.
Los operadores de nodos ahora reciben paquetes de la Fundación XRPL
La versión 3.4.0 cambia la ruta de distribución para los paquetes de servidor Linux. La versión oficial dice que los paquetes Debian y RPM ahora se alojan a través de packages.xrplf.org y se firman con una clave de la Fundación XRPL.
Los desarrolladores de XRPL instaron a los operadores de servidores a instalar la versión 3.4.0 "lo antes posible" para mantener la continuidad del servicio. Los archivos DEB y RPM publicados incluyen sumas de verificación SHA-256 para que los operadores puedan verificar los paquetes descargados antes de la instalación.
GitHub ahora enumera la versión 3.4.0 como la última versión inmutable de xrpld, vinculada al commit 4a4fded2eba11427c48ce3f24d9c1aea5e7a9d17. El repositorio indica que la etiqueta de la versión y el commit de la versión llevan firmas verificadas.
La misma versión retira fixAMMOverflowOffer. Según el modelo de enmiendas de XRPL, la retirada no revierte la corrección. Elimina el comportamiento obsoleto previo a la enmienda una vez que las nuevas reglas se han establecido como comportamiento permanente del protocolo.
El soporte al cliente y la revisión de seguridad aún están en desarrollo
Las bibliotecas de aplicaciones avanzan junto con la versión del servidor. El historial del cliente JavaScript de XRPLF enumera el soporte de LendingProtocolV1_1 en la sección no publicada después de xrpl.js 5.2.0, que se lanzó el 11 de septiembre.
El historial de binary-codec muestra que la versión 2.11.0 ya contiene los prefijos de firma de patrocinador y contraparte específicos del rol utilizados por fixCleanup3_4_0, junto con definiciones de protocolo generadas a partir de xrpld 3.4.0.
Las pruebas de seguridad del trabajo de préstamos han continuado por separado de la votación de validadores. Sherlock dijo en una revisión del 27 de agosto que Ripple había iniciado un examen exclusivamente con IA del Lending Protocol V1.1 a través de su Audit Engine.
Sherlock dijo que publicaría más información después de que finalizara la revisión, pero no se localizaron hallazgos finales de V1.1 en sus materiales públicos consultados para este informe. Las pruebas anteriores cubrieron una versión previa del sistema de préstamos; la cobertura de auditoría independiente previa informó que la reauditoría anterior de Halborn no encontró problemas críticos ni de alto riesgo, mientras identificaba un hallazgo medio, dos bajos y dos informativos.
