Los validadores de XRP Ledger (XRPL) han encaminado la enmienda BatchV1_1 hacia una activación condicional el 29 de septiembre a las 14:06:41 UTC. El cambio sustituye a una versión anterior del sistema de transacciones por lotes, retirada antes de llegar a la red principal tras detectarse un fallo crítico de autorización. La reparación, sin embargo, no elimina los riesgos para las aplicaciones que firman, muestran o indexan estas operaciones.
La votación queda supeditada a mantener el 80% de apoyo
El 22 de septiembre, 30 de los 35 validadores de confianza registrados por xrpldashboard respaldaban BatchV1_1, por encima del umbral mostrado de 28 votos. La mayoría apareció por primera vez en la cadena el 15 de septiembre. Según las reglas de enmiendas de XRPL, el apoyo debe mantenerse por encima del 80% durante dos semanas para que la activación siga adelante. Si cae al 80% o menos, el periodo de mayoría termina y la fecha deja de estar asegurada.
La votación representa la primera prueba en producción de la respuesta completa de XRPL a un problema detectado antes de la activación de una funcionalidad. La enmienda Batch original nunca llegó a desplegarse en la red principal. En febrero, unos investigadores encontraron un fallo en el proceso que comprobaba las cuentas que autorizaban un lote y recomendaron a los validadores rechazarla. La divulgación oficial de XRPL Labs indicó que no hubo fondos en riesgo.
El error se producía cuando el código encontraba primero a un firmante válido de una cuenta recién creada cuya clave coincidía con la de esa misma cuenta. En ese punto devolvía una respuesta de éxito sin revisar el resto de los firmantes. Un atacante podía colocar esa firma válida al principio y añadir después una entrada falsificada que aparentara autorizar una cuenta de una víctima. Si el cambio se hubiera activado, la transacción de esa cuenta podría haberse ejecutado sin sus claves.
Una revisión del formato de autorización
La respuesta llegó en dos fases. La versión 3.1.1 marcó como no compatibles las enmiendas Batch y fixBatchInnerSigs, impidiendo su activación. Más tarde, BatchV1_1 reemplazó ambas con una ruta de autorización reescrita y controles adicionales.
La especificación final XLS-56 exige que un lote con varias cuentas incluya el conjunto exacto y completo de BatchSigners que necesitarían autorización para las transacciones internas, salvo la cuenta cuya firma normal autoriza la operación externa. Las entradas ausentes, adicionales, duplicadas o colocadas en un orden incorrecto deben provocar el rechazo.
Además, cada BatchSigner vincula su firma a la cuenta externa, el número de secuencia o ticket, el modo seleccionado, los hashes ordenados de todas las transacciones internas y la cuenta del propio firmante. En las operaciones con múltiples firmas también queda vinculada cada cuenta firmante anidada. El objetivo es impedir que una firma válida se reutilice en otra transacción externa o se atribuya a un participante distinto.
Un lote puede contener entre dos y ocho transacciones internas. Estas no llevan firma ni comisión propia y están marcadas para que no puedan enviarse de forma independiente. El lote externo debe escoger uno de cuatro modos: ejecutar todo o nada, aplicar solo la primera operación válida, procesar en orden hasta encontrar un fallo o intentar todas las transacciones de manera independiente.
El protocolo puede estar listo antes que las aplicaciones
La activación desplaza parte del riesgo hacia los servidores y clientes. El soporte para BatchV1_1 llegó a xrpld 3.3.0 el 6 de agosto. Cuando la enmienda se active, los servidores que no entiendan sus reglas quedarán bloqueados por la propia enmienda y no podrán validar correctamente el libro mayor ni participar en el consenso hasta actualizarse.
En el lado de las aplicaciones, una incidencia registrada en xrpl.js mostró que la versión 5.0.0 generaba firmas con el formato antiguo. Faltaban en ellas la cuenta externa, la secuencia y la vinculación con los participantes, por lo que los nodos compatibles con BatchV1_1 rechazaban esas firmas con el código temBAD_SIGNATURE. El historial de versiones recoge el soporte compatible en xrpl.js 5.1.0.
Hay otro matiz relevante: un lote externo puede devolver tesSUCCESS aunque una o varias transacciones internas hayan fallado. Los clientes deben revisar los metadatos y códigos de resultado de cada operación para conocer el desenlace real, especialmente cuando se utilizan modos distintos del de ejecución completa o nula. Las carteras tendrán que mostrar cada acción y el modo elegido, mientras que exploradores e indexadores deberán conservar la relación entre la transacción externa y sus operaciones internas.
Si el apoyo se mantiene, el 29 de septiembre no demostrará por sí solo que las aplicaciones estén preparadas ni que los usuarios adopten la funcionalidad. La prueba continuará después de la activación: habrá que observar si quedan nodos obsoletos bloqueados, si se concentran los errores de firma en versiones antiguas y si las interfaces explican correctamente los resultados parciales. La especificación también mantiene el riesgo de anticipación de operaciones como un asunto todavía en investigación.
