Los validadores de XRP Ledger se están acercando a la aprobación de BatchV1_1, pero los datos de votación en vivo del 8 de septiembre mostraron que la enmienda permanecía por debajo del umbral necesario para iniciar su período de activación de dos semanas.
Resumen
- BatchV1_1 actualmente tiene 24 de 35 votos de validadores, lo que equivale a un 68,57% de apoyo en la red principal de XRPL.
- La activación requiere más del 80% de apoyo continuamente durante catorce días, y no ha comenzado ninguna cuenta regresiva.
- Las transacciones por lotes pueden contener hasta ocho operaciones y admiten cuatro modos de ejecución después de la activación.
- La versión 3.3.0 de XRPL introdujo BatchV1_1 después de que los desarrolladores deshabilitaran el código Batch original debido a una vulnerabilidad.
- La falla anterior podría haber permitido pagos no autorizados, pero la enmienda vulnerable nunca se activó en la red principal de XRPL.
BatchV1_1 tenía el apoyo de 24 de 35 validadores en la Lista de Nodos Únicos predeterminada, lo que equivale al 68,57%, según XRPScan. Se requerirían al menos 29 votos afirmativos para superar el 80% con el recuento actual de validadores.
La enmienda permitiría a las cuentas agrupar hasta ocho transacciones en una operación coordinada. Sin embargo, los informes que sugieren que se activará en septiembre siguen siendo especulativos porque no se ha alcanzado la mayoría requerida.
Una activación en septiembre solo es posible si el apoyo primero supera el 80% y se mantiene allí continuamente durante catorce días.
La votación de Batch de XRP Ledger no ha comenzado su cuenta regresiva
Las enmiendas de XRPL se activan solo después de mantener el apoyo de más del 80% de los validadores de confianza durante dos semanas consecutivas. Si el apoyo cae por debajo de ese nivel durante el período, el temporizador se reinicia.
Por lo tanto, BatchV1_1 necesita al menos cinco votos afirmativos adicionales bajo la configuración actual de 35 validadores. Los cambios en el conjunto de participantes podrían alterar el número exacto requerido.
La enmienda no tiene una fecha de activación confirmada. Incluso si cruzara el umbral de inmediato, no podría activarse hasta que finalice el período continuo de dos semanas.
Los votos de los validadores también pueden cambiar. Los operadores pueden retirar su apoyo si las pruebas revelan problemas de compatibilidad, seguridad u operativos.
BatchV1_1 combinaría ocho transacciones
La documentación oficial de XRPL dice que las transacciones por lotes pueden contener hasta ocho transacciones internas. Las operaciones se empaquetan dentro de una transacción externa que gestiona la secuenciación, las tarifas y la autorización.
Habría cuatro modos de ejecución disponibles. "Todo o nada" requiere que cada transacción interna tenga éxito. "Solo una" aplica la primera operación exitosa, mientras que "hasta fallar" procesa transacciones hasta que una falle. "Independiente" intenta cada transacción incluida independientemente de otros resultados.
Los usos potenciales incluyen intercambios atómicos de tokens, acuñación de NFT seguida de una oferta, tarifas de plataforma agrupadas y acciones coordinadas que involucran varias cuentas. Los lotes de múltiples cuentas requieren que cada cuenta participante autorice la colección completa.
La característica podría reducir la infraestructura externa que las aplicaciones necesitan para coordinar acciones dependientes. Cada transacción interna comprometida conservaría metadatos separados y una referencia a su lote principal.
Como crypto.news informó cuando se lanzó la versión 3.3.0, el envío del código no activó la característica. La aprobación del validador seguía siendo necesaria.
La enmienda corregida reemplaza el código Batch vulnerable
La versión 3.3.0 de XRPL introdujo BatchV1_1 el 6 de agosto como reemplazo de la enmienda Batch original. Los desarrolladores desactivaron esa versión anterior en febrero después de que los investigadores encontraran una falla crítica de autorización.
Pranamya Keshkamat y la herramienta de seguridad Apex de Cantina AI identificaron un error en la lógica utilizada para verificar los firmantes de Batch. La falla podría haber permitido a un atacante omitir verificaciones para algunos participantes y enviar transacciones no autorizadas desde la cuenta de una víctima.
XRPL Labs dijo que la enmienda vulnerable no se había activado en la red principal y que ningún fondo de usuario estuvo en riesgo. Se recomendó a los validadores votar en contra, mientras que la versión 3.1.1 de rippled marcó el Batch original y su corrección complementaria como no compatibles.
La versión corregida elimina el error de salida temprana, agrega salvaguardas de autorización y restringe cómo se verifica cada firmante. Una auditoría independiente revisó posteriormente el reemplazo antes de su lanzamiento.
En cobertura relacionada de la revisión de seguridad, crypto.news informó que la falla original se detectó antes de la activación y BatchV1_1 fue reescrito para la versión 3.3.0.
La activación depende completamente de los validadores
Los operadores de nodos deben ejecutar software que admita BatchV1_1 antes de votar por él. XRPL también advirtió a los operadores de Clio que actualicen a la versión 2.8.0 para que su infraestructura API pueda procesar los nuevos formatos de transacción y libro mayor si las enmiendas se activan.
El próximo hito confirmado es el umbral del 80% de validadores. Solo entonces el libro mayor registrará el comienzo del período de mayoría de dos semanas.
Una activación a finales de septiembre sigue siendo matemáticamente posible, pero no está programada. El momento exacto depende de votos adicionales de validadores y del soporte ininterrumpido posterior.
No se pudo atribuir ningún movimiento de precio de XRP verificado específicamente al voto de BatchV1_1. La enmienda cambia la funcionalidad de las transacciones, no el suministro de XRP ni las reglas de emisión.
