Estos acontecimientos se producen mientras XRPL amplía su papel en los pagos institucionales, las stablecoins y los activos tokenizados, lo que aumenta la importancia de una infraestructura de liquidación fiable y de las salvaguardas que rigen las transacciones financieras.

$XRP La ralentización del libro mayor pone de manifiesto los desafíos del procesamiento de transacciones

El problema operativo surgió el 21 de octubre, cuando algunos libros mayores comenzaron a tardar más de lo habitual en cerrarse, alterando el ritmo habitual de liquidación de la blockchain, de entre 3 y 5 segundos.

XRPL Operations dijo que la mayoría de los libros mayores seguían cerrándose con normalidad, pero los retrasos intermitentes llevaron a los desarrolladores a investigar el comportamiento de la red y preparar una corrección de software.

A medida que persistían los retrasos, el equipo distribuyó un cambio de configuración recomendado de xrpld a los operadores de hubs, validadores y nodos.

Según el equipo de operaciones, el ajuste restableció los tiempos normales de cierre el 22 de octubre, aunque los desarrolladores siguieron probando una versión puntual destinada a abordar la causa subyacente.

David Schwartz, uno de los arquitectos originales de XRPL y exdirector de tecnología de Ripple, ofreció más información sobre lo que podría haber contribuido al incidente.

Dijo que su propio hub había seguido funcionando con normalidad tras un incidente anterior que consideraba no relacionado, pero que lo reinició con el cambio de configuración recomendado.

Schwartz dijo:

«Entiendo que el problema estaba relacionado con servidores que se esforzaban demasiado por incluir demasiadas transacciones en cada libro mayor».

Al preguntársele si eso sugería que XRPL había alcanzado un límite práctico en su capacidad de procesamiento de transacciones, Schwartz reconoció que existe una relación entre el volumen de transacciones y la frecuencia de cierre.

Añadió:

«Sí y no. No podemos cerrar un libro mayor con una frecuencia superior a una vez cada 4 segundos. Por lo tanto, limitar el número de transacciones por libro mayor no impone necesariamente un límite de TPS».

Sus comentarios apuntan a una posible disyuntiva entre procesar más transacciones en cada libro mayor y mantener tiempos de liquidación constantes.

Sin embargo, los desarrolladores no han determinado si el incidente reflejó una limitación más amplia de la capacidad de la red o un comportamiento del software que pueda corregirse sin afectar el rendimiento.

Esta distinción tiene implicaciones comerciales, ya que XRPL atrae aplicaciones que requieren una liquidación predecible, incluidas las transferencias de la stablecoin RLUSD, los valores tokenizados y los servicios de pago institucionales.

Más interrupciones podrían complicar el procesamiento de transacciones para los servicios que dependen del movimiento rápido de fondos o garantías.

Por lo tanto, la próxima versión del software será importante para determinar si el cambio de configuración ofrece una solución duradera o si hacen falta ajustes adicionales para mantener el rendimiento con cargas de transacciones más elevadas.

Un revés en la votación de validadores retrasa las salvaguardas financieras

Por separado, la enmienda fixCleanup3_4_0 de XRPL ha sufrido un revés de gobernanza que prolongará la activación de varias correcciones para su infraestructura financiera.

La enmienda, presentada en la versión xrpld 3.4.0 de septiembre, aborda problemas técnicos relacionados con los permisos de tokens, los creadores de mercado automatizados, las bóvedas de activos, las operaciones de préstamo y las transacciones de depósito en garantía.

Entre los cambios se incluye una corrección para un fallo en la delegación de permisos que, en determinadas circunstancias, podría permitir que una cuenta autorizada a destruir ciertos tokens fungibles creara tokens adicionales.

La documentación de la red recomienda a los emisores no delegar el permiso afectado PaymentBurn hasta que la corrección se active.

Otros cambios mejoran la precisión de la contabilidad de las bóvedas, hacen cumplir las salvaguardas de los saldos de tokens y corrigen el procesamiento de transacciones en las funciones de negociación descentralizada y préstamos.

Las protecciones propuestas avanzaban hacia su activación el 23 de octubre, antes de que el respaldo de los validadores cayera brevemente por debajo de la supermayoría necesaria para cambiar las reglas del protocolo de XRPL.

XRPL requiere el apoyo de más del 80% de los validadores de confianza durante 14 días consecutivos antes de que pueda activarse una enmienda.

La pérdida temporal de apoyo el 21 de octubre borró el período de aprobación acumulado de la enmienda, aunque posteriormente el respaldo volvió a superar el umbral requerido.

El rastreador de enmiendas de XRPLWin sitúa ahora la activación más temprana el 4 de noviembre, siempre que la mayoría renovada se mantenga.

El colaborador de XRPL Vet confirmó que los votos adicionales de los validadores habían restablecido la cuenta regresiva para la activación de la enmienda. También aclaró que fixCleanup3_4_0 aborda problemas más antiguos del protocolo y no está relacionado con los últimos retrasos en el cierre de los libros mayores.

El aplazamiento prolonga el período antes de que puedan hacerse cumplir las salvaguardas afectadas sobre permisos de tokens. También retrasa correcciones destinadas a mejorar la contabilidad y el procesamiento de transacciones en la infraestructura de préstamos de XRPL, aún en desarrollo.

Esa infraestructura todavía necesita aprobaciones adicionales del protocolo antes de que puedan ponerse en marcha los servicios de préstamos nativos.

Una nueva caída del apoyo de los validadores volvería a reiniciar el período de espera de la enmienda, lo que podría aplazar la activación más allá del 4 de noviembre.