XRPL corrige un fallo crítico antes de la red principal, pero las aplicaciones cliente siguen en riesgo

Los validadores del XRP Ledger (XRPL) han puesto a BatchV1_1 en un camino condicional para activarse a las 14:06:41 UTC del 29 de septiembre, convirtiendo un casi fallo de seguridad en una prueba en vivo del proceso de enmienda de la red y su software circundante.

El 22 de septiembre, xrpldashboard mostró que 30 de 35 validadores de confianza apoyaban la enmienda, por encima del umbral de 28 votos mostrado. La mayoría apareció por primera vez en el libro mayor el 15 de septiembre.

Bajo las reglas de enmienda de XRPL, el apoyo debe mantenerse por encima del 80% durante dos semanas. Una caída al 80% o menos termina el período de mayoría, por lo que la fecha de activación sigue siendo condicional.

El 29 de septiembre es la primera prueba de producción de si el proceso de validación de XRPL, la implementación de referencia y el ecosistema de clientes convirtieron un peligroso fallo previo a la red principal en una infraestructura de transacciones atómicas utilizable.

El cortafuegos de validadores funcionó antes de la red principal

La enmienda Batch original nunca se activó en la red principal del XRP Ledger. En febrero, los investigadores encontraron un fallo crítico de autorización mientras la enmienda aún estaba en su fase de votación, y se aconsejó a los validadores que votaran en contra.

La divulgación oficial de vulnerabilidades de XRPL Labs establece que no había fondos en riesgo.

El fallo se encontraba en el bucle que verificaba las cuentas que autorizaban un lote. Si el código encontraba un firmante para una cuenta recién creada cuyo clave coincidía con esa cuenta, devolvía éxito inmediatamente en lugar de continuar con los firmantes restantes.

Un atacante podría colocar ese firmante válido primero, luego agregar una entrada falsificada que pretendiera autorizar una cuenta víctima. Si la enmienda hubiera entrado en funcionamiento, la transacción de la víctima no verificada podría haberse ejecutado sin las claves de la víctima.

La respuesta de XRPL llegó en dos etapas. La versión 3.1.1 marcó la enmienda Batch original y fixBatchInnerSigs como no soportadas, bloqueando su activación. BatchV1_1 las reemplazó más tarde con un camino de autorización reescrito y defensas adicionales.

El episodio fue un fallo atrapado en el límite entre la liberación de software y la activación del protocolo.

La especificación final XLS-56 de la Fundación XRPL ahora requiere que un lote de múltiples cuentas contenga el conjunto exacto y completo de BatchSigners cuya autorización las transacciones internas normalmente necesitarían, aparte de la cuenta cuya firma normal autoriza la transacción externa.

Entradas faltantes, adicionales, duplicadas o incorrectamente ordenadas causan rechazo.

Cada BatchSigner también firma más que una colección suelta de transacciones internas. La carga útil vincula la firma a la cuenta externa, su número de secuencia o ticket, el modo de lote seleccionado, los hashes ordenados de cada transacción interna y la cuenta BatchSigner.

Una entrada firmada por múltiples también vincula cada cuenta firmante anidada. Eso evita que una firma válida sea levantada en una transacción externa diferente o reasignada a otro participante.

La implementación de referencia fusionada agrega cumplimiento en torno a ese diseño, incluidos los controles de orden y unicidad de firmantes, límites de conteo de transacciones, rechazo de transacciones internas enviadas directamente y protecciones contra la repetición del libro mayor.

Juntas, esos cambios abordan tanto el error de éxito prematuro divulgado como las formas adyacentes en que los datos de lote malformados o repetidos podrían cruzar los límites de autorización.

Un lote contiene de dos a ocho transacciones internas. Cada transacción interna no lleva firma ni tarifa y está marcada para que no pueda ser enviada de forma independiente. El lote externo selecciona exactamente uno de cuatro modos:

• TODO O NADA: cada transacción interna debe tener éxito o ninguno de sus cambios de estado se compromete.
• SOLO UNO: la primera transacción interna exitosa es la única que se aplica.
• HASTA FALLAR: las transacciones se aplican en orden hasta que una falla.
• INDEPENDIENTE: cada transacción interna se intenta independientemente de los resultados de las demás.

BatchV1_1 puede soportar flujos atómicos de todo o nada, pero no cada lote es atómico en ese sentido estricto. Los desarrolladores también pueden usarlo para retrocesos ordenados o paquetes independientes.

La activación traslada el riesgo a la implementación

La trampa de integración más inmediata es que un Batch externo puede devolver tesSUCCESS incluso cuando una o más transacciones internas fallan. Los clientes deben inspeccionar los metadatos y el código de resultado de cada transacción interna para determinar qué sucedió.

Esa distinción es importante fuera del modo ALLORNOTHING, donde la ejecución parcial o independiente es intencionada.

El soporte para BatchV1_1 se envió en xrpld 3.3.0 el 6 de agosto. Una vez que la enmienda se active, un servidor que no entienda las nuevas reglas quedará bloqueado por la enmienda. Ya no podrá validar el libro mayor de manera confiable ni participar en el consenso hasta que se actualice.

Un problema presentado contra xrpl.js documentó que la versión 5.0.0 construyó firmas de Batch utilizando la carga útil más antigua, omitiendo la cuenta externa, la secuencia y el enlace de participantes. Los nodos habilitados para BatchV1_1 rechazaron esas firmas con temBAD_SIGNATURE.

El historial de lanzamientos de xrpl.js registra soporte compatible en la versión 5.1.0.

La enmienda reparada BatchV1_1 de XRPL se acerca a una prueba de activación condicional después de que los validadores rechazaron un diseño anterior de bucle de firmantes.

Las filas de carteras e indexadores reflejan la guía de integración en las detalladas reglas XLS-56. El protocolo puede rechazar una firma mal formada, pero no puede obligar a una cartera a explicar claramente un paquete complejo ni a un explorador a presentar cada resultado interno en contexto.

La especificación también señala que la ejecución anticipada es un área que aún está bajo investigación. Una autorización más fuerte impide que una parte falsifique la aprobación de otra cuenta, pero no elimina todos los riesgos creados al empaquetar varias acciones orientadas al mercado en una única presentación ordenada.

Lo que probará el 29 de septiembre

Si la mayoría se mantiene, la activación mostrará que el proceso de validación de XRPL puede detener una enmienda peligrosa, redirigir a los operadores a una versión desactivada y luego mover un reemplazo reparado a través de la misma maquinaria de gobernanza.

También comenzará una prueba en el mundo real de si los servidores, bibliotecas de firma, carteras e infraestructura de datos están de acuerdo con el nuevo formato de transacción y sus resultados.

No probará que las aplicaciones han adoptado BatchV1_1, que los usuarios quieren la función o que la demanda de transacciones en la red aumentará. La votación de la enmienda y los lanzamientos de software establecen la disponibilidad del protocolo, pero no proporcionan evidencia de compras adicionales de XRP.

Las señales útiles vendrán después de la activación: si los nodos desactualizados quedan bloqueados, si los fallos de firma se agrupan alrededor de versiones antiguas del cliente, si las carteras presentan lotes de múltiples cuentas de manera inteligible y si los exploradores informan resultados internos sin confundir el éxito externo con la ejecución completa.

Los validadores de XRPL pasaron la primera prueba al evitar que el error original de Batch llegara a la mainnet. La activación condicional del 29 de septiembre pregunta si el ecosistema aprendió lo suficiente de ese casi error para operar el reemplazo de manera segura.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.