A los operadores de nodos que ejecutan XRP Ledger se les está pidiendo que actúen con rapidez. El director de ingeniería de Ripple, Vijay Khanna, instó el 2 de agosto a los proveedores de infraestructura a completar una actualización de nodo de XRP Ledger a la versión 3.2.1 de xrpld después de que los desarrolladores detectaran una inundación de manifiestos de validadores que golpeó la red el 31 de julio. El libro mayor siguió produciendo bloques durante todo el incidente, pero el episodio dejó al descubierto una debilidad de agotamiento de recursos que Ripple ahora ha procedido a cerrar con un hotfix específico.
Summary
Puntos clave
- Una inundación de manifiestos de validadores el 31 de julio llevó a Ripple a lanzar xrpld 3.2.1 como un hotfix de emergencia publicado el 1 de agosto.
- XRP Ledger siguió cerrando libros mayores con normalidad durante todo el evento, sin pérdida confirmada de fondos, transacciones alteradas ni fallos de consenso.
- Cuatro nuevas salvaguardas ahora limitan el tamaño de los manifiestos, los tamaños de los lotes de mensajes, el crecimiento de la caché para claves de validadores desconocidos y el intercambio saliente de datos no confiables.
- Los operadores deben actualizar, confirmar que xrpld se está ejecutando y luego reiniciar una segunda vez para limpiar cualquier manifiesto que haya persistido antes del parche.
- Ripple rotó su clave GPG de firma de paquetes el 18 de febrero, por lo que los operadores deben confiar en la nueva clave para que la actualización se instale correctamente.
Qué desencadenó la actualización de nodo de XRP Ledger
La inundación se centró en los manifiestos de validadores, los registros firmados criptográficamente que vinculan la identidad maestra permanente de un validador con la clave temporal que utiliza para el tráfico de validación diario. Cuando un validador rota esa clave temporal, transmite un nuevo manifiesto firmado por su clave maestra para que los pares de la red puedan verificar que el cambio es legítimo.
Antes de la corrección, los nodos aceptaban, almacenaban en caché y retransmitían manifiestos vinculados a claves de validadores que nunca habían visto antes, siempre que los datos fueran estructuralmente válidos. Eso creó una oportunidad: alguien podía generar un gran número de identidades desconocidas y obligar a cada nodo conectado a consumir memoria, almacenamiento, ancho de banda y potencia de procesamiento solo para manejar el ruido. El registro de código público vinculado al incidente lo describe como un fallo de propagación de manifiestos más que una violación de cualquier cuenta o clave.
A pesar de la presión sobre los recursos de los nodos, XRP Ledger Operations informó que la red siguió cerrando libros mayores con normalidad todo el tiempo. Esa distinción importa: la inundación tensionó la infraestructura, pero nunca llegó al punto de interrumpir el consenso o corromper el historial de transacciones.
Dentro del hotfix xrpld 3.2.1
La respuesta de Ripple, fechada el 31 de julio y publicada como una versión firmada a primera hora del 1 de agosto, incluye seis commits en 13 archivos modificados, cuatro de los cuales restringen directamente cómo los nodos manejan los manifiestos de validadores no reconocidos. En conjunto, forman cuatro salvaguardas diseñadas para evitar que el mismo tipo de inundación vuelva a agotar los recursos de los nodos.
La primera rechaza un manifiesto de gran tamaño antes de que un nodo termine siquiera de decodificarlo, cortando de raíz el coste de procesamiento de objetos anormalmente grandes. La segunda limita cuántos manifiestos no confiables pueden viajar dentro de un solo mensaje de red, tanto si un nodo está recibiendo datos como si los está preparando para sus pares; los lotes demasiado grandes se descartan sin cortar automáticamente la conexión, lo que permite que nodos parcheados y sin parche sigan comunicándose entre sí durante el despliegue.
Un tercer cambio limita cuántas identidades de validadores desconocidos puede contener la caché de manifiestos de un nodo, con el código final fijando ese techo en 100. Una vez que la caché se llena, las nuevas claves no listadas son rechazadas mientras que los validadores de confianza y previamente reconocidos continúan operando sin interrupción. El cuarto ajuste cambia cómo se propagan los datos de manifiestos no confiables a través de la red, endureciendo el intercambio saliente de rumores de pares no listados mientras deja intactos los datos vinculados a validadores configurados o aprobados. Ese equilibrio es intencional: la rotación normal de claves de validadores sigue funcionando, pero el crecimiento descontrolado de la caché procedente de desconocidos no.
Qué deben hacer ahora los operadores de nodos
Las indicaciones de Khanna son sencillas pero deben seguirse en orden. Los operadores deben instalar la actualización estándar, esperar de uno a dos minutos, confirmar que xrpld realmente se está ejecutando y luego reiniciar el servicio una segunda vez.
Ese segundo reinicio no es una formalidad. Cualquier manifiesto que el nodo de un operador haya absorbido y almacenado antes del parche podría seguir en memoria o en disco. Instalar la 3.2.1 cambia cómo el software maneja los nuevos manifiestos en adelante, pero solo un reinicio limpio elimina los datos que el nodo recogió mientras aún era vulnerable. Saltarse ese paso implica el riesgo de dejar manifiestos obsoletos y no confiables en su lugar incluso después de que el código en sí haya sido corregido.
Hay un segundo matiz que vale la pena señalar: la confianza en los paquetes. Ripple rotó la clave GPG que utiliza para firmar los paquetes de xrpld el pasado 18 de febrero, y las instalaciones que aún no hayan confiado en esa clave de reemplazo pueden no descargar la actualización automáticamente. Cualquiera que gestione infraestructura XRPL debe revisar su configuración de claves de firma antes de asumir que la actualización se aplicará sin problemas.
Es importante destacar que esta actualización de nodo de XRP Ledger está dirigida directamente a la infraestructura, no a los titulares individuales. Los exchanges, custodios, backends de monederos, proveedores de datos y cualquier empresa que ejecute sus propios servidores XRPL deben confirmar la versión de su nodo y el estado de reinicio. Los titulares ordinarios de XRP no necesitan mover fondos, cambiar claves de monedero ni abrir nuevas cuentas por este problema: la corrección vive íntegramente en la capa de servidor.
Por qué la ausencia de daños sigue siendo importante
No se ha publicado ningún identificador CVE ni estimación de pérdidas financieras en relación con la inundación, y las pruebas disponibles apuntan a recursos de nodos y tráfico entre pares tensionados más que a cualquier robo confirmado, transacción alterada o ruptura del consenso. Es un resultado realmente tranquilizador para una red que liquida miles de millones en valor, pero no significa que el incidente no tuviera coste. Los ataques de agotamiento de recursos que no tocan los fondos aún pueden degradar el servicio, ralentizar a los proveedores de infraestructura y crear oportunidades para intentos posteriores si los parches se retrasan.
Esa es la pieza que aún falta en el registro público. XRP Ledger Operations ha dicho que seguirá un análisis técnico pormenorizado, pero hasta el 2 de agosto ese informe no se había publicado. Hasta que llegue, la identidad de quien envió la inundación, el volumen real de manifiestos implicados y la rapidez con la que los operadores de nodos de toda la red adoptaron la 3.2.1 siguen siendo preguntas abiertas. También se espera que el informe aclare cuándo detectaron por primera vez los desarrolladores el tráfico inusual y si algún nodo individual llegó a ser inalcanzable, aunque el libro mayor compartido nunca dejó de producir bloques.
Esta no es la primera transición forzada de software de la red este año. El hotfix 3.2.1 sigue al despliegue mayor de la 3.2.0 el 15 de junio, que renombró el servidor de referencia de rippled a xrpld y requirió su propia ronda de actualizaciones de configuración, la misma versión que llevó al operador de infraestructura de XRPL David Schwartz a migrar su configuración antes de los nuevos cambios de nombre y protocolo. Los operadores de nodos también tuvieron que cumplir con una fecha límite anterior de la 3.1.3 vinculada a la activación de una enmienda. En conjunto, el patrón sugiere que a la capa de infraestructura de XRPL se le está pidiendo que mantenga el ritmo de un ciclo de actualizaciones cada vez más ajustado, y los operadores que se queden atrás en cualquier versión corren el riesgo de arrastrar vulnerabilidades que la red ya ha corregido en otros lugares.
Preguntas frecuentes
¿Qué provocó la necesidad de la actualización de nodo de XRP Ledger?
Se produjo una inundación de manifiestos de validadores el 31 de julio, causando agotamiento de recursos en los nodos, lo que requirió el hotfix xrpld 3.2.1 para mitigar el problema.
¿La inundación de manifiestos causó pérdida de fondos o fallos de consenso en XRP Ledger?
No se observaron pérdidas financieras confirmadas, transacciones alteradas ni fallos de consenso del libro mayor durante la inundación, según XRP Ledger Operations.
¿Cuáles son las principales salvaguardas introducidas en xrpld 3.2.1?
La actualización limita el tamaño de los manifiestos, los tamaños de los lotes de mensajes, el crecimiento de la caché de claves desconocidas (limitado a 100 entradas) y el intercambio saliente de manifiestos no confiables.
¿Quién debe actualizar a xrpld 3.2.1 y cuáles son los pasos operativos?
Los proveedores de infraestructura que ejecutan nodos XRPL —incluidos exchanges, custodios y operadores de monederos— deben actualizar, verificar que el software se esté ejecutando y luego realizar un segundo reinicio para limpiar cualquier manifiesto persistente.
{«@context»:»https://schema.org»,»@type»:»FAQPage»,»mainEntity»:[{«@type»:»Question»,»name»:»¿Qué provocó la necesidad de la actualización de nodo de XRP Ledger?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Se produjo una inundación de manifiestos de validadores el 31 de julio, causando agotamiento de recursos en los nodos, lo que requirió el hotfix xrpld 3.2.1 para mitigar el problema.»}},{«@type»:»Question»,»name»:»¿La inundación de manifiestos causó pérdida de fondos o fallos de consenso en XRP Ledger?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»No se observaron pérdidas financieras confirmadas, transacciones alteradas ni fallos de consenso del libro mayor durante la inundación, según XRP Ledger Operations.»}},{«@type»:»Question»,»name»:»¿Cuáles son las principales salvaguardas introducidas en xrpld 3.2.1?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»La actualización limita el tamaño de los manifiestos, los tamaños de los lotes de mensajes, el crecimiento de la caché de claves desconocidas (limitado a 100 entradas) y el intercambio saliente de manifiestos no confiables.»}},{«@type»:»Question»,»name»:»¿Quién debe actualizar a xrpld 3.2.1 y cuáles son los pasos operativos?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Los proveedores de infraestructura que ejecutan nodos XRPL —incluidos exchanges, custodios y operadores de monederos— deben actualizar, verificar que el software se esté ejecutando y luego realizar un segundo reinicio para limpiar cualquier manifiesto persistente.»}}]}
Artículo producido con la ayuda de inteligencia artificial y revisado por el equipo editorial.
