Los validadores de XRP Ledger (XRPL) han situado la enmienda BatchV1_1 en una activación condicional prevista para el 29 de septiembre a las 14:06:41 UTC. El cambio reemplaza una versión anterior de las transacciones por lotes que fue retirada antes de llegar a la red principal tras detectarse un fallo crítico de autorización. La votación, sin embargo, solo será válida si el apoyo se mantiene por encima del 80% durante el periodo exigido.
El 22 de septiembre, 30 de los 35 validadores de confianza respaldaban BatchV1_1, frente a un umbral visible de 28 votos. La mayoría apareció por primera vez en el registro de la red el 15 de septiembre. Según las reglas de enmiendas de XRPL, el respaldo debe superar el 80% durante dos semanas; si cae hasta ese nivel o por debajo, el periodo de mayoría se interrumpe y la fecha de activación deja de estar asegurada.
El fallo se detuvo antes de llegar a la red principal
La primera enmienda Batch nunca se activó en la red principal de XRP Ledger. En febrero, unos investigadores identificaron un problema en la fase de votación y recomendaron a los validadores rechazarla. La divulgación oficial de XRPL Labs indicó que no hubo fondos en riesgo.
El error afectaba al proceso que comprobaba las cuentas autorizadas para una operación por lotes. Si el código encontraba primero a un firmante de una cuenta recién creada cuya clave coincidía con la de esa cuenta, devolvía la autorización sin revisar el resto de firmantes. Un atacante podía aprovechar ese comportamiento colocando primero el firmante válido y añadiendo después una entrada falsificada que aparentara autorizar una cuenta de otra persona. De haberse activado la enmienda, la operación de esa cuenta podría haberse ejecutado sin sus claves.
La respuesta llegó en dos pasos. La versión 3.1.1 de xrpld marcó como no compatibles las enmiendas Batch y fixBatchInnerSigs, impidiendo su activación. Más tarde, BatchV1_1 sustituyó ambas por una ruta de autorización reescrita y nuevas defensas.
Una autorización más estricta no elimina los riesgos de integración
La especificación definitiva XLS-56 exige que un lote con varias cuentas incluya el conjunto exacto y completo de firmantes necesarios para autorizar sus operaciones internas, salvo la cuenta cuya firma normal autoriza la operación externa. Las entradas ausentes, adicionales, duplicadas o colocadas en un orden incorrecto deben ser rechazadas.
Además, cada firmante vincula su firma a la cuenta externa, al número de secuencia o ticket, al modo elegido, a los hashes ordenados de todas las operaciones internas y a la cuenta del propio firmante. En las firmas múltiples también queda vinculada cada cuenta firmante anidada. El objetivo es evitar que una firma válida se reutilice en otra operación o se atribuya a un participante distinto.
Un lote puede contener entre dos y ocho operaciones internas y utilizar uno de cuatro modos: ejecutar todas o ninguna, aplicar solo la primera operación que tenga éxito, procesarlas en orden hasta encontrar un fallo o intentar cada una de forma independiente. Por eso, no todos los lotes son atómicos en el sentido estricto de “todo o nada”.
El principal riesgo para las aplicaciones aparece en la interpretación del resultado. Una operación externa puede devolver tesSUCCESS aunque una o varias operaciones internas hayan fallado. Las carteras deben revisar los metadatos y códigos de resultado de cada acción, mientras que los exploradores e indexadores tienen que conservar la relación entre la operación externa y sus elementos internos.
El 29 de septiembre pondrá a prueba al ecosistema
El soporte de BatchV1_1 llegó a xrpld 3.3.0 el 6 de agosto. Cuando la enmienda se active, los servidores que no entiendan sus nuevas reglas quedarán bloqueados por la enmienda y no podrán validar el registro ni participar de forma fiable en el consenso hasta actualizarse.
También hay diferencias entre versiones de las bibliotecas cliente. Un problema registrado en xrpl.js señaló que la versión 5.0.0 generaba firmas Batch con el formato antiguo, sin vincular la cuenta externa, la secuencia y los participantes. Los nodos compatibles con BatchV1_1 rechazaban esas firmas con temBAD_SIGNATURE. El historial de lanzamientos de la biblioteca recoge soporte compatible a partir de la versión 5.1.0.
La activación demostrará si el proceso de validación logró detener una enmienda peligrosa y trasladar después una versión corregida a la red. No demostrará, por sí sola, que las aplicaciones estén preparadas ni que las carteras expliquen correctamente cada lote. La prueba real llegará después: con los nodos desactualizados, los posibles fallos de firma y la capacidad de las interfaces para mostrar cada resultado interno sin confundir el éxito de la operación externa con la ejecución completa.
