Los desarrolladores del XRP Ledger (XRPL) han defendido el parche de seguridad de emergencia desplegado para corregir un bug capaz de crear XRP por encima del suministro fijo de la red, argumentando que no podían esperar la habitual votación de validadores de dos semanas de la blockchain sin exponer la falla a posibles atacantes.

A diferencia de las redes que emiten nuevas monedas con el tiempo, el XRP Ledger se lanzó con todo su suministro de 100 mil millones de XRP ya existente, por lo que una ruta de código capaz de emitir tokens adicionales atacaba una propiedad fundamental del activo.

El parche fue publicado el 25 de septiembre, tres días después de un reporte de bug bounty, y surtió efecto de inmediato en cualquier servidor que lo instalara. Según los desarrolladores, marcó la primera omisión deliberada del proceso estándar de enmiendas de la red desde que ese sistema se introdujo hace más de diez años. Bajo ese proceso, los cambios de protocolo se publican como enmiendas y solo se activan después de que más del 80% de los validadores los apoya durante dos semanas consecutivas, el mismo umbral que la XRPL Foundation citó posteriormente para defender la actualización obligatoria a la versión 3.4.1.

"Con una votación de enmienda normal, la solución habría sido pública durante semanas antes de entrar en vigor, arriesgando la seguridad de la red", dijeron los desarrolladores de XRPL en una publicación en X el domingo.

La solución acelerada ha generado preguntas sobre el grado de descentralización del XRP Ledger. En su sitio web, XRPL se describe como una blockchain pública completamente descentralizada, una caracterización que ha sido central en los argumentos de que su token nativo, XRP, no debería clasificarse como un valor. Esos argumentos tienen peso regulatorio: la Comisión de Bolsa y Valores de EE. UU. (SEC) demandó a Ripple en diciembre de 2020, alegando ofertas de valores no registradas de XRP, y el grado de descentralización de XRP ha sido un punto recurrente en ese caso.

La corrección de seguridad "generó muchas preguntas"

Justin Bons, fundador de Cyber Capital, dijo el jueves que comercializar XRP ante inversores minoristas como descentralizado equivalía a "puro fraude". Argumentó que la publicación de emergencia del 25 de septiembre se distribuyó solo como binarios, retuvo temporalmente el código fuente y presionó a los operadores a actualizar.

Sin embargo, la XRPL Foundation dijo que la decisión de omitir el proceso estándar de enmiendas fue tomada conjuntamente por la Foundation, RippleX, los desarrolladores principales y los validadores tras evaluar la gravedad del bug.

"Ninguna parte podía tomar esa decisión por sí sola. Cada validador y operador de nodo elige qué software ejecutar, y 3.4.1 solo se volvió obligatoria mediante una votación de enmienda normal con más del 80% de apoyo de los validadores durante dos semanas. Los cambios de protocolo aún pasan por enmiendas", dijo la fundación.

XRP Kuwait, un operador de validador independiente, también rechazó las afirmaciones de que las actualizaciones coordinadas señalaban un control centralizado.

"No estamos de acuerdo con la afirmación de que los operadores que coordinan una actualización sea, en sí mismo, prueba de control centralizado", dijo en una publicación en X. "La coordinación no es lo mismo que el control. Los operadores independientes pueden evaluar una situación, comunicarse entre sí y llegar a la misma conclusión sin renunciar a su independencia."

El bug podría haber emitido XRP ilimitado

Según el informe de divulgación de vulnerabilidades del proyecto, el bug era un desbordamiento de enteros en el motor de pagos del XRP Ledger que había estado presente desde 2015.

Los saldos de XRP se almacenan como enteros de 64 bits con un máximo fijo. Cuando una suma excedía ese máximo, el cálculo se revertía a un número menor en lugar de fallar.

Un atacante podría explotar la falla creando cientos de ofertas con precios especiales, cada una solicitando una cantidad muy grande de XRP, y luego enviando un solo pago que las consumiera todas. El motor acreditaría a cada propietario de oferta su monto completo mientras cobraría al comprador solo el pequeño total revertido, con la diferencia materializándose como XRP recién creado y utilizable.

El ataque requería ofertas construidas deliberadamente y no podía desencadenarse por actividad comercial normal, según el informe. Los desarrolladores dijeron que no encontraron evidencia de que el problema se haya explotado en alguna red pública.

Cómo una falla en uno de los componentes centrales del ledger pasó desapercibida durante aproximadamente una década sigue siendo una pregunta abierta en el debate que la divulgación ha generado.