Los validadores del XRP Ledger (XRPL) han encaminado la enmienda BatchV1_1 hacia una activación condicional el 29 de septiembre a las 14:06:41 UTC. La actualización sustituye a una versión anterior de Batch que fue retirada antes de llegar a la red principal por un fallo de autorización, aunque el cambio no elimina los riesgos de integración para servidores, carteras, librerías y exploradores.
La votación llega tras bloquear una vulnerabilidad
El 22 de septiembre, 30 de los 35 validadores de confianza respaldaban BatchV1_1, por encima del umbral de 28 votos que muestra xrpldashboard. La mayoría apareció por primera vez en la cadena el 15 de septiembre. Sin embargo, la fecha de activación aún no es definitiva: las reglas de enmiendas del XRPL exigen mantener un apoyo superior al 80% durante dos semanas. Si el respaldo cae hasta el 80% o menos, el periodo de mayoría se interrumpe.
El antecedente explica la cautela. La primera enmienda Batch nunca se activó en la red principal. En febrero, varios investigadores detectaron un fallo de autorización mientras el cambio todavía estaba en fase de votación y recomendaron a los validadores rechazarlo. Según la comunicación oficial de XRPL Labs, no hubo fondos en riesgo.
El problema estaba en el proceso que comprobaba las cuentas autorizadoras de una operación por lotes. Si el código encontraba primero a un firmante válido de una cuenta recién creada cuya clave coincidía con la de esa cuenta, devolvía una respuesta satisfactoria sin revisar el resto de firmantes. Un atacante podía colocar ese firmante legítimo en primer lugar y añadir después una entrada falsificada para aparentar la autorización de una cuenta víctima.
De haberse activado aquella versión, la transacción de la víctima podría haberse ejecutado sin sus claves. La respuesta se produjo en dos fases: la versión 3.1.1 de xrpld marcó como no compatibles las enmiendas Batch y fixBatchInnerSigs, bloqueando su activación, y BatchV1_1 las reemplazó mediante una ruta de autorización reescrita y controles adicionales.
Una protección más estricta, con nuevas exigencias para los clientes
La especificación final XLS-56 exige que un lote con varias cuentas incluya el conjunto exacto y completo de firmantes necesarios para autorizar las transacciones internas. Las entradas ausentes, adicionales, duplicadas o colocadas en un orden incorrecto deben provocar el rechazo de la operación.
Además, cada firma queda vinculada a la cuenta externa, su número de secuencia o ticket, el modo elegido, los hashes ordenados de todas las transacciones internas y la cuenta del firmante. En las operaciones con múltiples firmas también se vincula cada cuenta firmante anidada. El objetivo es impedir que una firma válida se reutilice en otra transacción o se reasigne a un participante diferente.
La implementación de referencia incorpora comprobaciones sobre el orden y la unicidad de los firmantes, límites al número de transacciones, rechazo de transacciones internas enviadas directamente y defensas frente a reproducciones del registro contable. Un Batch puede contener entre dos y ocho transacciones internas. Estas no llevan firma ni comisión propias y están marcadas para impedir su envío independiente.
El lote externo puede operar en cuatro modos: ALLORNOTHING, que aplica todos los cambios o ninguno; ONLYONE, que ejecuta únicamente la primera transacción que tenga éxito; UNTILFAILURE, que procesa las operaciones en orden hasta encontrar un fallo; e INDEPENDENT, que intenta cada transacción con independencia del resultado de las demás. Por tanto, BatchV1_1 permite operaciones atómicas, pero no todos los lotes tienen ese comportamiento.
El riesgo se desplaza ahora a las aplicaciones
El principal reto para los integradores es interpretar correctamente el resultado. Un lote externo puede devolver tesSUCCESS aunque una o varias transacciones internas hayan fallado. Las aplicaciones deben consultar los metadatos y códigos de resultado de cada operación para saber qué ocurrió, especialmente cuando se utilizan modos de ejecución parcial o independiente.
El soporte para BatchV1_1 llegó a xrpld con la versión 3.3.0, publicada el 6 de agosto. Tras la activación, los servidores que no entiendan las nuevas reglas quedarán bloqueados por la enmienda y tendrán que actualizarse para volver a validar el registro y participar en el consenso.
También hay diferencias entre versiones de xrpl.js. La 5.0.0 generaba firmas con el formato antiguo y omitía la cuenta externa, la secuencia y la vinculación con los participantes. Los nodos compatibles con BatchV1_1 rechazaban esas firmas con el error temBAD_SIGNATURE. La compatibilidad revisada figura en la versión 5.1.0.
La activación, si mantiene el respaldo necesario, pondrá a prueba no solo el mecanismo de validación del XRPL, sino también la preparación del ecosistema. Las carteras tendrán que mostrar cada acción interna y el modo elegido; los exploradores e indexadores deberán conservar la relación entre la operación externa y sus componentes. El protocolo puede rechazar firmas defectuosas, pero no puede garantizar que una interfaz explique correctamente un lote complejo. La especificación también mantiene el riesgo de front-running como un asunto todavía en estudio.
