Los validadores de XRP Ledger han puesto la enmienda corregida BatchV1_1 en camino a una activación condicional a las 14:06:41 UTC del 29 de septiembre. Treinta de los 35 validadores de confianza respaldaron la enmienda, por encima de su umbral de 28 votos, con la mayoría apareciendo por primera vez en el ledger el 15 de septiembre. Según las reglas de XRPL, el soporte debe mantenerse por encima del 80% durante dos semanas, por lo que la fecha sigue siendo condicional. La enmienda reemplaza a una versión anterior retirada después de que investigadores encontraran una falla crítica de autorización en febrero, antes de que llegara siquiera a la mainnet.
Por qué importa
El episodio validó el cortafuegos de enmiendas de XRPL. La enmienda Batch original aún estaba en su fase de votación cuando los investigadores revelaron un bug de bucle de firmantes que devolvía éxito de forma anticipada en lugar de comprobar los firmantes restantes. De haber entrado en producción, una entrada falsificada podría haber ejecutado la transacción de una víctima sin sus claves, aunque la divulgación de XRPL Labs confirma que nunca hubo fondos en riesgo.
BatchV1_1 reemplaza ese mecanismo con un esquema de autorización reescrito bajo la especificación XLS-56. Ahora cada firma de BatchSigner vincula la cuenta externa, su número de secuencia o ticket, el modo de batch, los hashes ordenados de todas las transacciones internas y cualquier firmante anidado, cerrando tanto el bug revelado como vectores de replay adyacentes.
Impacto en el mercado
La corrección a nivel de protocolo traslada el riesgo a la implementación. Un Batch externo puede devolver tesSUCCESS incluso cuando las transacciones internas fallan, por lo que los clientes deben inspeccionar cada código de resultado interno. El soporte de BatchV1_1 llegó con xrpld 3.3.0 el 6 de agosto, y los servidores que no se actualicen quedarán bloqueados por la enmienda una vez que se active. xrpl.js 5.0.0 construía las firmas sobre el payload antiguo y es rechazado con temBAD_SIGNATURE, con soporte compatible disponible en la versión 5.1.0.
La activación demuestra la disponibilidad del protocolo, no la adopción ni la demanda de XRP. Las señales a observar después son si los nodos desactualizados quedan bloqueados, si los fallos de firma se agrupan en torno a versiones antiguas de clientes y si las wallets y los exploradores presentan los batches multi-cuenta de forma comprensible.
Preguntas frecuentes
-
¿Cuándo se activará la enmienda BatchV1_1 de XRPL?
Condicionalmente a las 14:06:41 UTC del 29 de septiembre, siempre que el soporte de los validadores se mantenga por encima del 80% durante el período requerido de dos semanas. Actualmente treinta de los 35 validadores de confianza respaldan la enmienda, por encima de su umbral de 28 votos.
-
¿Cuál era la falla en la enmienda Batch original de XRPL?
Un bug de bucle de firmantes devolvía éxito de forma anticipada al encontrar un firmante de una cuenta recién creada, por lo que una entrada falsificada que pretendiera autorizar una cuenta víctima podría haberse ejecutado sin las claves de la víctima. No hubo fondos en riesgo.
-
¿Por qué un Batch de XRPL puede mostrar éxito mientras las transacciones internas fallan?
Un Batch externo puede devolver tesSUCCESS incluso cuando una o más transacciones internas fallan, y fuera del modo ALLORNOTHING la ejecución parcial es intencionada. Los clientes deben inspeccionar los metadatos y el código de resultado de cada transacción interna.
-
¿Qué versiones de software soportan BatchV1_1?
xrpld 3.3.0 incorporó el soporte de BatchV1_1 el 6 de agosto, y xrpl.js 5.1.0 añadió el formato de firma revisado. La versión 5.0.0 produce firmas que los nodos con BatchV1_1 rechazan con temBAD_SIGNATURE, y los servidores desactualizados corren el riesgo de quedar bloqueados por la enmienda.
-
¿La activación de BatchV1_1 significa mayor demanda de XRP?
No por sí sola. La votación y las publicaciones de software solo demuestran la disponibilidad del protocolo. Las señales útiles llegarán después de la activación, como nodos bloqueados, fallos de firma en clientes antiguos y cómo presentan los batches las wallets y los exploradores.
WuBlockchain
CoinTelegraph
CZ Binance
CoinDesk
Glassnode
TheBlock