Titular: XRPL solicita actualización urgente de nodo tras una “inundación de manifest” que sobrecarga los recursos de la red Vijay Khanna, Director de Ingeniería de Ripple, instó el 2 de agosto a los operadores de nodos del XRP Ledger a instalar inmediatamente xrpld v3.2.1 tras detectar desarrolladores una “inundación de manifest” de validadores el 31 de julio. Esta corrección rápida limita cómo los nodos procesan, almacenan y comparten datos de manifest de identidades de validadores desconocidas, impidiendo que los atacantes agoten la memoria, el almacenamiento, el ancho de banda y la CPU de los nodos, y preservando el funcionamiento normal del libro mayor mientras se implementa el parche. ¿Qué ocurrió? - El 31 de julio, los desarrolladores observaron un aumento en los manifest de validadores provenientes de identidades desconocidas. Aunque el libro mayor continuó cerrándose normalmente, el evento ejerció presión sobre los recursos del nodo y las comunicaciones punto a punto. - No hay evidencia pública de fondos robados, transacciones alteradas ni fallo en el consenso. Los desarrolladores no han emitido un CVE ni publicado una estimación de pérdidas financieras relacionadas con el incidente. - XRPL Operations indicó que seguirá un post-mortem técnico; al 2 de agosto, el origen de la inundación, el volumen total y el impacto exacto en los recursos siguen sin divulgarse. ¿Por qué importan los manifest de validadores? - Los manifest de validadores son registros firmados criptográficamente que vinculan la identidad maestra estable de un validador con las claves temporales utilizadas para los mensajes de validación diarios. Cuando los operadores rotan las claves temporales, publican un nuevo manifest firmado con la clave maestra para que los pares puedan verificar el cambio. - Antes del parche, xrpld podía aceptar, almacenar en caché y retransmitir manifest correctamente estructurados para claves de validador que no reconocía. Un atacante podría explotar este comportamiento creando muchas identidades desconocidas y obligando a los pares a desperdiciar memoria, almacenamiento, ancho de banda y poder de procesamiento al manejar esos datos. El repositorio de código describe este problema como abuso de propagación de manifest. ¿Qué incluye xrpld 3.2.1? - La versión oficial xrpld 3.2.1 (fechada el 31 de julio; firmada y publicada a principios del 1 de agosto) contiene seis confirmaciones en 13 archivos. Cuatro confirmaciones limitan directamente el manejo de manifest no confiables. Protecciones clave: - Rechazo temprano de manifest excesivamente grandes antes de que los nodos los decodifiquen completamente, reduciendo el trabajo de CPU por objeto malicioso. - Límites en la cantidad de manifest no confiables permitidos en un solo mensaje de red —aplicados tanto en recepción como al preparar mensajes para pares—. Los lotes excesivamente grandes se descartan sin desconectar a pares sin parchear, facilitando la compatibilidad durante la implementación. - Límite por nodo en las identidades de validador desconocidas almacenadas en memoria, limitado a 100. Una vez lleno, se rechazan nuevos manifest no listados, mientras que los validadores confiables y recordados continúan procesándose. - Cambios en cómo se retiene y difunde la información de manifest no confiables, enfocados en la difusión entre pares no listados en lugar de manifest provenientes de validadores configurados o confiables. Esto preserva la rotación legítima de claves de validador mientras bloquea el crecimiento descontrolado de la caché. Orientación para operadores y notas de implementación - Khanna aconsejó a los validadores e operadores de infraestructura que actualicen a la v3.2.1 “lo antes posible”. El proceso recomendado: realizar la actualización normal del software, esperar uno o dos minutos para confirmar que xrpld está funcionando, luego reiniciar nuevamente el servicio. El segundo reinicio ayuda a eliminar cualquier manifest desconocido retenido en memoria antes del parche. - Los operadores también deben confirmar que sus sistemas confían en la clave GPG actual de Ripple para firmar paquetes. Ripple rotó esa clave el 18 de febrero; los nodos que no hayan confiado en la nueva clave podrían no recibir actualizaciones automáticas. - Esta actualización está dirigida a operadores de infraestructura (exchange, custodios, back ends de monederos, proveedores de datos y empresas que ejecutan servidores XRPL). Los titulares ordinarios de XRP no necesitan mover fondos, rotar claves ni tomar ninguna acción. Contexto y próximos pasos - El parche sigue al lanzamiento generalizado de xrpld v3.2.0 (15 de junio), que renombró el servidor de referencia de rippled a xrpld y requirió que los operadores actualizaran sus configuraciones. La adopción de v3.2.0 fue más rápida entre validadores que en la red completa de nodos; la inundación de manifest brinda a los operadores restantes otra razón sólida para migrar a la v3.2.1. - XRPL Operations ha prometido un post-mortem técnico que detallará cuándo se detectó por primera vez la actividad, si algún nodo se volvió inaccesible, el volumen de manifest y qué tan rápido los operadores adoptaron el parche. Hasta que se publique ese informe, los detalles confirmados se limitan a las correcciones de la v3.2.1 y la solicitud para que los operadores actualicen y reinicien. Conclusión Si opera infraestructura XRPL, trate esto como urgente: actualice a xrpld 3.2.1 y siga la recomendación de reinicio en dos pasos para eliminar cualquier manifest no confiable retenido. Para la comunidad XRPL en general, el incidente parece haber sido un intento de agotamiento de recursos más que una vulnerabilidad del protocolo —pero el próximo post-mortem será importante para confirmar el alcance completo.
XRPL solicita a los operadores de nodos que actualicen a xrpld 3.2.1 tras el inundamiento de manifestaciones de validadores
ChainGPTCompartir
Resumen
El equipo de ingeniería de Ripple implementó una actualización de red a xrpld v3.2.1 tras una inundación de manifestaciones de validadores el 31 de julio. La actualización de la cadena de bloques introduce límites en los datos de manifestaciones no confiables para prevenir el agotamiento de recursos. Los operadores deben reiniciar en dos pasos después de aplicar el parche. No se perdieron fondos y el consenso se mantuvo intacto. Actualmente se lleva a cabo una revisión técnica. Los usuarios regulares no necesitan tomar ninguna acción.
Fuente:Mostrar original
Descargo de responsabilidad: La información contenida en esta página puede proceder de terceros y no refleja necesariamente los puntos de vista u opiniones de KuCoin. Este contenido se proporciona solo con fines informativos generales, sin ninguna representación o garantía de ningún tipo, y tampoco debe interpretarse como asesoramiento financiero o de inversión. KuCoin no es responsable de ningún error u omisión, ni de ningún resultado derivado del uso de esta información.
Las inversiones en activos digitales pueden ser arriesgadas. Evalúa con cuidado los riesgos de un producto y tu tolerancia al riesgo en función de tus propias circunstancias financieras. Para más información, consulta nuestras Condiciones de uso y la Declaración de riesgos.