Los validadores del XRP Ledger (XRPL) han situado la enmienda BatchV1_1 en una vía condicional para activarse el 29 de septiembre a las 14:06:41 UTC. La actualización sustituye a un diseño anterior que fue retirado antes de llegar a la red principal por un fallo crítico de autorización. Sin embargo, la activación también pondrá a prueba a las aplicaciones, bibliotecas de firma, monederos y herramientas de datos que deben interpretar el nuevo formato.
La votación aún depende de mantener el respaldo
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. Según las reglas de enmiendas del XRPL, el apoyo debe mantenerse por encima del 80% durante dos semanas. Si cae al 80% o menos, el periodo de mayoría termina y la fecha de activación deja de estar vigente.
Por eso, el 29 de septiembre no es todavía una fecha garantizada. Si el respaldo se mantiene, la red afrontará su primera prueba de producción para comprobar si el proceso de validación, la implementación de referencia y el ecosistema de clientes han convertido el fallo detectado en la fase previa a la red principal en una infraestructura utilizable para transacciones por lotes.
El fallo original fue bloqueado antes de llegar a la red principal
La primera enmienda Batch nunca se activó en la red principal. En febrero, unos investigadores identificaron un problema crítico mientras seguía en fase de votación y los validadores recibieron la recomendación de rechazarla. La divulgación oficial de vulnerabilidades de XRPL Labs indicó que no hubo fondos en riesgo.
El defecto estaba en el proceso que comprobaba las cuentas autorizadoras de un lote. Si encontraba primero a un firmante válido de una cuenta recién creada cuya clave coincidía con esa cuenta, el código devolvía el resultado correcto sin revisar los firmantes restantes. Un atacante podía colocar ese firmante legítimo en primer lugar y añadir después una entrada falsificada que aparentara autorizar una cuenta víctima. De haberse activado la enmienda, la transacción de esa cuenta podría haberse ejecutado sin sus claves.
La respuesta llegó en dos fases. La versión 3.1.1 de xrpld marcó como no compatibles las enmiendas Batch y fixBatchInnerSigs, lo que impedía su activación. Más tarde, BatchV1_1 reemplazó ambas con una ruta de autorización reescrita y defensas adicionales.
La especificación final XLS-56 exige que un lote con varias cuentas incluya el conjunto exacto y completo de firmantes que necesitarían autorización para las transacciones internas, salvo la cuenta cuya firma normal autoriza la transacción exterior. Las entradas ausentes, adicionales, duplicadas o desordenadas provocan el rechazo. Además, cada firmante vincula su firma a la cuenta exterior, su número de secuencia o billete, el modo seleccionado, los hashes ordenados de todas las transacciones internas y la cuenta que firma. En las firmas múltiples también queda vinculada cada cuenta firmante anidada.
El riesgo se traslada ahora a las aplicaciones
BatchV1_1 admite entre dos y ocho transacciones internas y ofrece cuatro modos: ejecución de todas o ninguna, ejecución exclusiva de la primera operación válida, ejecución en orden hasta el primer fallo y ejecución independiente de todas. Por tanto, no todos los lotes son atómicos en el sentido estricto de “todo o nada”.
La principal dificultad para los clientes es que una transacción exterior puede devolver tesSUCCESS aunque una o varias operaciones internas hayan fallado. Monederos y aplicaciones deben revisar los metadatos y códigos de resultado de cada transacción interna, especialmente cuando el modo permite ejecuciones parciales o independientes.
El soporte para BatchV1_1 llegó a xrpld 3.3.0 el 6 de agosto. Tras la activación, los servidores que no entiendan las nuevas reglas quedarán bloqueados por la enmienda y no podrán validar la cadena de forma fiable ni participar en el consenso hasta actualizarse.
También existe una dependencia concreta en xrpl.js. Una incidencia documentó que la versión 5.0.0 generaba firmas Batch con el formato antiguo, sin vincular la cuenta exterior, la secuencia ni los participantes. Los nodos compatibles con BatchV1_1 rechazaban esas firmas con temBAD_SIGNATURE. El historial de versiones de xrpl.js registra soporte compatible en la 5.1.0.
La activación, si se confirma, demostrará que el protocolo puede detener una enmienda peligrosa y sustituirla por otra corregida. No demostrará, por sí sola, que los monederos hayan integrado el cambio o que los exploradores presenten correctamente cada resultado interno. La prueba real llegará después: en los nodos desactualizados, en los fallos de firma y en la capacidad de las interfaces para explicar al usuario qué acciones contiene cada lote.
