La enmienda Batch V1.1 del XRP Ledger ha avanzado hasta quedar a un voto de validador de comenzar su proceso de activación de dos semanas, después de que los desarrolladores corrigieran otros 11 problemas de software descubiertos durante las revisiones de seguridad.
Resumen
- Batch V1.1 del XRP Ledger ha asegurado 27 de 35 votos de validadores, quedando a un voto del umbral de activación del 80%.
- Los desarrolladores corrigieron otros 11 problemas relacionados con firmas, verificaciones de autorización y posibles fallos del servidor antes de la última votación.
- Batch permitiría a los usuarios combinar hasta ocho transacciones en una sola operación y requeriría que los pagos vinculados se completen juntos.
- La versión actual reemplazó una propuesta anterior de Batch después de que los investigadores encontraran una falla grave de autorización antes de que llegara a la red principal.
RippleX dijo el lunes que la última revisión de Batch V1.1 identificó problemas relacionados con firmas de transacciones, verificaciones de autorización y fallos del servidor, con las correcciones incorporadas en la versión que ahora están considerando los validadores del XRP Ledger.
El apoyo se situó en 27 de los 35 validadores de confianza el martes, equivalente a aproximadamente el 77%, dejando la propuesta justo por debajo del nivel del 80% requerido para entrar en el período de activación de la red.
La actualización Batch del XRP Ledger se acerca al 80% de apoyo
Batch V1.1 permitiría agrupar hasta ocho transacciones en una sola operación, con reglas de ejecución que pueden requerir que las transacciones vinculadas tengan éxito juntas.
Para un intercambio de tokens entre dos usuarios, la función podría hacer que ambas transferencias dependan una de la otra. Si un lado del intercambio falla, la otra transacción no se completaría de forma independiente.
Los monederos y los mercados podrían utilizar la misma estructura para procesar juntos un pago de cliente y una comisión de plataforma. RippleX dijo que los proyectos comerciales que utilizan Batch ya están bajo contrato o en desarrollo, aunque el equipo de desarrolladores no ha identificado públicamente a las empresas involucradas.
El apoyo de los validadores ha aumentado rápidamente durante la última semana. El 8 de septiembre, Batch V1.1 tenía 24 votos de los 35 validadores en la Lista de Nodos Únicos predeterminada, equivalente al 68,57%, según informó anteriormente crypto.news. Desde entonces, tres validadores más han respaldado la enmienda.
Según las reglas de gobernanza del XRP Ledger, una enmienda debe mantener al menos un 80% de apoyo de los validadores durante 14 días consecutivos antes de poder activarse. Con 35 validadores de confianza contados actualmente, otro voto de apoyo llevaría a Batch V1.1 por encima del umbral y comenzaría ese período.
El resultado no quedaría fijado una vez que comience la cuenta atrás. Los validadores pueden cambiar sus posiciones, y si el apoyo cae por debajo del 80% durante la ventana de 14 días, se interrumpiría el proceso de activación.
Un proceso similar ocurrió en julio cuando la enmienda fixCleanup3_2_0 aseguró un 85,71% de apoyo y entró en su ventana de activación. El paquete posteriormente se activó el 29 de julio después de mantener suficiente respaldo de los validadores durante el período requerido.
Batch V1.1 reemplaza una versión anterior con una falla grave
La votación actual sigue a la retirada del diseño original de Batch después de que los investigadores encontraran una vulnerabilidad antes de que la función llegara a la red principal del XRP Ledger.
En ciertas condiciones, la falla podría haber permitido a un atacante colocar transacciones de la cuenta de otro usuario dentro de un lote sin obtener la autorización requerida. No se pusieron en riesgo los fondos de los usuarios porque la enmienda afectada nunca se activó.
Los desarrolladores reconstruyeron la función tras el descubrimiento, y Batch V1.1 se incluyó posteriormente en xrpld 3.3.0, lanzado el 6 de agosto.
El lanzamiento de xrpld 3.3.0 introdujo la implementación corregida de Batch junto con otras características de protocolo propuestas. Cada enmienda aún requiere la aprobación por separado de los validadores antes de activarse en la red principal.
La ingeniera de software de RippleX, Mayukha Vadari, dijo que el problema original de la firma se encontró en febrero antes del despliegue en la red principal. El trabajo posterior incluyó una corrección de la causa raíz, revisiones por cuatro ingenieros sénior, un concurso de seguridad de Sherlock y auditorías de Halborn y Common Prefix.
"Después de que el error de firma de la v1.0 se detectara en febrero (antes de la Mainnet, sin fondos en riesgo), lo reconstruimos", escribió Vadari en X el 14 de septiembre.
El proceso de revisión no terminó con la vulnerabilidad inicial. RippleX dijo que se encontraron otros 11 problemas mientras se examinaba la implementación de reemplazo.
Las revisiones de seguridad encontraron 11 problemas más en Batch
Los hallazgos adicionales abarcaban el manejo de firmas, las comprobaciones de autorización y condiciones de software capaces de provocar la caída de servidores.
Common Prefix clasificó una de las vulnerabilidades como crítica. Según la revisión de RippleX, el problema podría haber permitido a un atacante reutilizar un permiso que un usuario había firmado y realizar más transacciones de las que el usuario pretendía autorizar originalmente.
Otros hallazgos involucraban la forma en que las transacciones Batch verificaban permisos y procesaban firmas. Los desarrolladores abordaron los problemas reportados antes de que la enmienda alcanzara su etapa actual de votación de validadores.
RippleX dijo que cuatro ingenieros sénior revisaron la implementación, mientras que Halborn y Common Prefix realizaron auditorías externas. El código pasó por pruebas automatizadas y un concurso de seguridad público diseñado para exponer debilidades antes de la activación.
Las pruebas de seguridad se han utilizado en otras propuestas recientes de XRP Ledger. Una revisión de seguridad de Common Prefix de junio identificó problemas numéricos y de comportamiento en componentes de XRPL, con correcciones desplegadas mediante la versión 3.2.0. Posteriormente, se encargó a la firma de seguridad la verificación formal y el análisis de otras partes de la red.
Un concurso separado de Sherlock que cubría características propuestas de XRP Ledger encontró docenas de vulnerabilidades válidas antes de que las enmiendas afectadas llegaran a la mainnet, incluidos hallazgos críticos y de alta gravedad.
Batch forma parte del conjunto de características de xrpld 3.3.0
Batch es uno de los diversos cambios de protocolo introducidos a través del ciclo de software 3.3.0 mientras los desarrolladores de XRP Ledger trabajan en liquidación de transacciones, privacidad, permisos y características institucionales.
Antes de que se lanzara el software, los desarrolladores esbozaron cinco enmiendas propuestas de XRPL que incluían transacciones Batch, Confidential MPT, Sponsor, Dynamic MPT y Permission Delegation.
Batch está diseñado en torno a la liquidación atómica, donde múltiples operaciones relacionadas pueden gestionarse como una transacción coordinada en lugar de enviarse por separado.
Permission Delegation permitiría a una cuenta otorgar autoridad restringida a otra cuenta sin ceder el control total. Confidential MPT está diseñado para ocultar los saldos y los importes de transferencia de los Multi-Purpose Tokens mientras mantiene visibles las identidades de las cuentas en el libro mayor público.
Ninguna de las características se activa simplemente porque su código esté incluido en xrpld. Los validadores deciden por separado si apoyan las enmiendas, dejando cada propuesta en su propio calendario de votación.
La red ya ha visto diferentes tasas de adopción entre las propuestas de 3.3.0. Ripple votó en agosto por la enmienda PermissionDelegationV1_1 cuando contaba con el apoyo de siete de los 35 validadores de confianza.
Desde entonces, Batch se ha acercado mucho más al umbral de activación. Sus 27 votos actuales dejan a la enmienda a un validador de apoyo de comenzar el período de 14 días, siempre que los votos existentes se mantengan.
RippleX no ha nombrado los proyectos comerciales que dijo que están bajo contrato o en desarrollo para usar Batch. CoinDesk dijo que preguntó al equipo de desarrolladores qué empresas se están preparando para usar la característica y si las 11 últimas correcciones recibieron una revisión independiente contra la versión que los validadores están considerando actualmente.
