El XRP Ledger se ha acercado a la activación de un paquete de correcciones de software el 23 de octubre tras asegurar los 29 votos de validadores requeridos para su aprobación, aunque su sistema de préstamos planificado sigue por debajo del umbral de votación de la red.
Resumen
- El último paquete de corrección de errores del XRP Ledger ha asegurado 29 votos de validadores, cumpliendo con el umbral de aprobación de la red.
- La actualización podría activarse el 23 de octubre si los validadores mantienen su apoyo durante el período de votación requerido de dos semanas.
- El sistema de préstamos planificado sigue 10 votos por debajo, mientras que su función de bóveda de soporte necesita ocho más.
- Las correcciones abordan cálculos de préstamos, contabilidad de bóvedas, manejo de tokens y otros problemas de procesamiento de transacciones en todo XRPL.
- La propuesta de préstamos respaldaría préstamos a plazo fijo sin garantía, utilizando corredores para evaluar la solvencia crediticia de los prestatarios fuera de la cadena.
Según el XRPL Dashboard, la enmienda conocida como fixCleanup3_4_0 había recibido el apoyo de 29 de los 35 validadores en la lista de confianza predeterminada de la red a partir del 19 de octubre. La propuesta está atravesando su período de aprobación requerido de dos semanas, con activación proyectada para el viernes si ese apoyo continúa.
La actualización contiene correcciones que afectan transacciones de tokens, contabilidad de bóvedas, creadores de mercado automatizados y procesos relacionados con préstamos. Su activación no habilitaría los préstamos en la red porque las propuestas principales de préstamos y bóvedas están atravesando votaciones separadas.
La enmienda LendingProtocol tenía 19 validadores de apoyo, quedándole 10 votos por debajo de los 29 requeridos. SingleAssetVault, que mantendría los fondos utilizados para préstamos, tenía 21 votos y necesitaba ocho más.
La corrección de errores del XRP Ledger apunta a su activación el 23 de octubre
La enmienda fixCleanup3_4_0 alcanzó la mayoría de validadores requerida el 9 de octubre, iniciando un período de 14 días durante el cual el apoyo debe mantenerse por encima del 80%.
En el punto de control del 19 de octubre, la propuesta había completado aproximadamente nueve días de ese período de espera. El panel proyectó el 23 de octubre alrededor de las 09:34 UTC como el momento en que finalizaría el período de aprobación requerido.
La activación real podría ocurrir poco después, ya que el XRP Ledger procesa las decisiones de enmienda en intervalos designados conocidos como ledgers de bandera.
Según la documentación de enmiendas de la red, estas comprobaciones ocurren cada 256 ledgers. Una vez transcurrido el período de espera requerido, la red registra la decisión de la enmienda y aplica las reglas actualizadas en los ledgers posteriores.
En la instantánea del 19 de octubre del panel, la corrección tenía exactamente 29 votos, sin validadores de apoyo adicionales más allá del mínimo requerido. Si uno de esos validadores retirara su apoyo antes de que finalizara el período de espera, la propuesta caería por debajo de la mayoría necesaria.
Según las reglas de XRPL, perder esa mayoría reinicia el período de aprobación de dos semanas cuando se restablece el apoyo suficiente. Por lo tanto, la hora de activación del 23 de octubre es una proyección, no una confirmación de que la actualización ya haya entrado en vigor.
Los operadores de servidores deben ejecutar software que reconozca las enmiendas aprobadas. Según la documentación de XRPL, los servidores que utilicen versiones anteriores sin el código necesario pueden quedar bloqueados por enmiendas una vez que la red comience a aplicar las nuevas reglas.
Los desarrolladores de XRPL lanzaron la versión 3.4.0 del software del servidor xrpld el 16 de septiembre y aconsejaron a los operadores actualizar para mantener la compatibilidad.
Los préstamos del XRP Ledger siguen 10 votos por debajo de la aprobación
Aunque partes de la corrección pendiente se relacionan con préstamos, el servicio de préstamos de la red no ha recibido suficiente apoyo de validadores para activarse.
La propuesta LendingProtocol, conocida como XLS-66, obtuvo 19 de los 35 votos de validadores de confianza en la instantánea del 19 de octubre. Su propuesta complementaria SingleAssetVault, XLS-65, obtuvo 21 votos. Ambas requieren el apoyo de al menos 29 validadores durante dos semanas continuas antes de entrar en vigor.
Las propuestas deben activarse antes de que el sistema de préstamos planificado pueda operar en la red principal de XRP Ledger. Incluso si ambas alcanzaran el recuento de votos requerido de inmediato, la regla de espera de dos semanas significa que no podrían activarse junto con el paquete de corrección de errores del 23 de octubre.
Una enmienda separada, LendingProtocolV1_1, obtuvo 19 votos de apoyo. Introducida en la versión 3.4.0, propone cambios en el diseño de las bóvedas de préstamos y la contabilización de los intereses de los préstamos.
La enmienda adicional requeriría que los corredores de préstamos recién creados utilicen bóvedas de plazo cerrado, donde los depósitos, los préstamos y los retiros siguen etapas definidas.
La propuesta divide ese proceso en períodos de suscripción, inversión y reembolso.
Cambiaría la contabilización de intereses para que los ingresos se reconozcan cuando los prestatarios realicen realmente los pagos, en lugar de registrar todos los intereses programados cuando comienza un préstamo.
Esos cambios propuestos siguen sujetos a la aprobación de los validadores.
En septiembre, crypto.news informó sobre el lanzamiento del software y sus dos nuevas enmiendas, señalando que el lanzamiento del código funcional no activaba por sí mismo las nuevas reglas de préstamos.
El último recuento de validadores muestra que la actualización de mantenimiento agrupada avanza por delante de las funciones financieras que respalda en parte.
El diseño de préstamos depende de los corredores para las verificaciones de los prestatarios
Según el sistema de préstamos de XRPL propuesto, los depositantes aportarían activos a una bóveda compartida, y un corredor de préstamos organizaría préstamos a plazo fijo utilizando esos fondos mancomunados.
El ledger registraría las obligaciones de los préstamos, los reembolsos y otras transacciones asociadas.
Los prestatarios no tendrían que proporcionar garantías directamente a través del protocolo.
En su lugar, los corredores de préstamos evaluarían la situación financiera de los prestatarios y su capacidad de reembolso mediante verificaciones realizadas fuera de la cadena de bloques. Este acuerdo daría a los corredores la responsabilidad de decidir qué prestatarios califican y qué condiciones de préstamo reciben.
El diseño publicado incluye un mecanismo de protección opcional llamado capital de primera pérdida. Un corredor podría depositar activos adicionales en una cuenta separada para ayudar a cubrir las pérdidas cuando los prestatarios no reembolsen sus préstamos.
La protección dependería de la cantidad disponible. No garantizaría que los depositantes pudieran recuperar todos sus fondos tras un incumplimiento. La documentación de XRPL explica que el protocolo no proporciona actualmente gestión automática de garantías en la cadena ni liquidación.
Los corredores de préstamos tendrían la opción de declarar un préstamo en incumplimiento después de que un prestatario no realice un pago y expire el período de gracia correspondiente.
El protocolo está destinado a respaldar actividades de préstamo institucional utilizando XRP y otros activos elegibles emitidos en el ledger. Ripple ha respaldado el desarrollo de las propuestas de préstamos como parte de su trabajo con instituciones financieras.
En agosto, Ripple respaldó ambas enmiendas a través de su validador mientras estas permanecían por debajo del umbral de activación.
Una reauditoría de seguridad de préstamos separada en junio no informó de hallazgos críticos ni de alto riesgo en los cambios revisados por la empresa de ciberseguridad Halborn.
La ausencia de hallazgos críticos en esa revisión no equivalía a una aprobación de la red ni a una garantía contra futuros problemas de software.
La última actualización de software aborda errores de bóvedas y transacciones
Las notas de la versión xrpld 3.4.0 del 16 de septiembre describen varias correcciones incluidas en fixCleanup3_4_0.
Una corrección evita que ciertas transacciones de recuperación de creadores de mercado automatizados destruyan los tokens de proveedor de liquidez de un usuario cuando el redondeo daría como resultado que no se recupere ningún activo subyacente.
Otros cambios abordan los cálculos utilizados cuando las personas depositan o retiran fondos de las bóvedas. Las correcciones están diseñadas para mantener consistentes los saldos de activos de las bóvedas y el número de participaciones emitidas a los depositantes durante las transacciones.
En cuanto a los préstamos, los desarrolladores actualizaron las reglas que abarcan la autorización, los activos congelados, las credenciales y los destinos de pago. Las notas de la versión especifican cambios relacionados con cómo los incumplimientos de préstamos interactúan con las congelaciones de activos y cómo el protocolo verifica los retiros de las bóvedas con permisos.
Ajustes separados abordan las transacciones de intercambio descentralizado con permisos, las ofertas de NFT y el procesamiento de depósitos en garantía. Una corrección relacionada con la firma introduce prefijos criptográficos distintos para diferentes roles de firma. El cambio evita que una firma destinada a un rol se reutilice en otro.
La versión también refuerza las restricciones sobre ciertas transacciones de tokens e impone verificaciones que antes solo se registraban en los registros de software. Estas correcciones se incluyen en la versión del software, pero requieren que la enmienda correspondiente se active antes de que sus nuevas reglas de transacción sean exigibles en la red principal.
La versión 3.4.0 además cambia cómo se distribuyen los paquetes de servidor compatibles, con paquetes de instalación de Linux firmados proporcionados a través de la Fundación XRPL.
El aviso de lanzamiento de la fundación indica a los operadores que actualicen sus servidores a la versión 3.4.0 para mantener el servicio mientras la red adopta las nuevas enmiendas.
