XRP Ledger ha publicado la versión 3.2.1 de xrpld, un hotfix de producción diseñado para detener la inundación de manifiestos de validadores que afectó partes de la infraestructura peer-to-peer de la red el 31 de julio de 2026. xrpld es el software de servidor de referencia que los participantes ejecutan para operar nodos y validadores en el XRPL. La blockchain continuó cerrando libros contables sin interrupción, lo que confirmó que el consenso se mantuvo completamente operativo a pesar de que los nodos individuales experimentaron cargas de datos anormales.

XRP Ledger Operations anunció el lanzamiento a través de su cuenta oficial de X:

XRP Ledger 3.2.1 is now available. This fixes the manifest flood observed on Friday, July 31. The XRPL continued closing ledgers normally throughout. A post-mortem will follow soon for the community. Nodes previously accepted, stored and re-broadcast an unlimited number of… pic.twitter.com/ZOdT8REQCw — XRP Ledger Operations (@XRPLOperations) August 1, 2026

Se instruyó a los administradores de nodos a instalar el hotfix sin demora y a realizar un segundo reinicio poco después de la instalación inicial. La versión actualizada introduce controles que evitan que los datos de validadores no confiables consuman cantidades desproporcionadas de memoria, ancho de banda, almacenamiento y capacidad de procesamiento.

Cómo la Inundación de Manifiestos Afectó la Infraestructura de Pares del XRPL

El XRPL depende de un conjunto de validadores que cada operador designa como confiables a través de una Lista de Nodos Únicos (UNL, por sus siglas en inglés). Solo los validadores en la UNL de un nodo participan directamente en la toma de decisiones de consenso de ese nodo. Los manifiestos de validadores vinculan la identidad maestra permanente de un validador con la clave de firma temporal utilizada durante las rondas de consenso. Esta arquitectura permite a los operadores rotar las claves de trabajo periódicamente mientras mantienen las credenciales maestras fuera de línea y conservan la identidad de red establecida del validador.

Las versiones anteriores de xrpld no tenían un límite en la cantidad de manifiestos asociados con claves de validadores desconocidos que un nodo podía aceptar, almacenar y retransmitir. Dado que cada nodo retransmite los datos de manifiestos a sus pares conectados independientemente del estado de confianza, los datos excesivos no confiables se propagaron por la red y se acumularon en las cachés locales.

El incidente afectó la propagación de mensajes en la capa de pares en lugar de los saldos de cuentas, las transacciones individuales o las reglas de validación del libro contable. Esta distinción es significativa para la arquitectura blockchain en general: las fallas en la capa de consenso pueden detener una cadena, mientras que las fallas en la capa de pares degradan la conectividad sin comprometer la integridad del libro contable. Aunque el XRPL siguió procesando transacciones y finalizando libros contables según lo programado, la tensión en las conexiones de pares degradó la conectividad y ralentizó la distribución de información en la red.

Cuatro Medidas de Seguridad en la Versión 3.2.1

La versión 3.2.1 introduce seis commits que abarcan 13 archivos. Los cambios implementan controles en cuatro puntos críticos donde el tráfico de manifiestos de tamaño excesivo o repetido podría sobrecargar a un nodo:

1. Rechazo de tamaño antes de la decodificación. xrpld ahora rechaza los manifiestos individuales que exceden el tamaño codificado esperado antes de que comience el proceso de decodificación, evitando que las entradas de tamaño excesivo generen trabajo computacional innecesario.

2. Descarte de lotes no confiables. Los nodos ahora descartan los lotes entrantes que contienen cantidades excesivas de manifiestos no confiables. Es importante destacar que el software evita desconectar automáticamente a los pares antiguos que transmiten lotes de tamaño excesivo, lo que reduce el riesgo de fragmentación de la red durante el periodo de actualización.

3. Límites en los saludos entre pares. El hotfix restringe el saludo de manifiestos masivos que se intercambia cuando dos nodos establecen una nueva conexión de pares. Los registros confiables permanecen completamente disponibles, mientras que la difusión de información no confiable se reduce tanto en las rutas de envío como de recepción.

4. Límite de almacenamiento para claves desconocidas. Cada nodo puede almacenar un máximo de 100 manifiestos vinculados a claves de validadores desconocidos. Una vez que se alcanza ese límite, se rechazan las entradas adicionales y los manifiestos no confiables dejan de persistirse en el disco.

Segundo Reinicio Obligatorio y Verificación de Clave de Firma

Después de instalar la actualización, se instruyó a los administradores a esperar aproximadamente uno o dos minutos y confirmar que xrpld permaneciera operativo. No se requiere una sincronización completa antes de proceder al siguiente paso.

Una vez confirmado que el servicio actualizado está en ejecución, los operadores deben reiniciar xrpld por segunda vez. El equipo de operaciones describió este segundo reinicio como un paso final esencial en el procedimiento de actualización.

Los administradores que utilizan instalaciones empaquetadas también deben verificar la clave de firma de software actual de Ripple. Ripple rotó la clave GPG utilizada para firmar los paquetes de xrpld en febrero de 2026, lo que significa que los sistemas que aún no han agregado la clave de reemplazo a su lista de confianza podrían no recibir actualizaciones automáticas.

El hotfix no introduce ninguna enmienda de red ni altera las reglas de procesamiento de transacciones. En su lugar, establece límites firmes sobre los datos no confiables de pares en cada etapa — antes de la decodificación, retransmisión, almacenamiento en caché o persistencia permanente. Al restringir el tamaño de los manifiestos, el volumen de lotes, los saludos de conexión y el almacenamiento de claves desconocidas, el XRP Ledger ha cerrado las cuatro rutas de explotación utilizadas durante la inundación del 31 de julio. El incidente demostró que el abuso de la capa de pares puede afectar a servidores individuales incluso mientras el consenso continúa funcionando con normalidad, una clase de vulnerabilidad que otras redes blockchain también han abordado mediante el endurecimiento del protocolo de pares.

Se espera que se comparta con la comunidad un análisis post-mortem completo.