Canales ancla: la respuesta a ataques de inundación en la red Lightning de Bitcoin

Desarrolladores han propuesto el mecanismo de “canales ancla” como solución a una vulnerabilidad de la red Lightning (LN) de Bitcoin que podría poner en riesgo los fondos de sus usuarios. La propuesta busca frenar posibles ataques que aprovechen los Contratos de hash bloqueados por tiempo (HTLC) mediante la “inundación” de los canales de LN.

A través de su lista de correo, el desarrollador Alex Bosworth destacó la propuesta de “canales ancla” que está en Github desde mediados de abril, señalando la reactivación del proceso. Bosworth, quien trabaja para Lightning Labs, alegó en su correo que, si bien la propuesta podría no presentar mejoras “concluyentes”, al menos apunta en la dirección correcta y “aumentan el costo y la complejidad de los ataques”.

“El gran cambio aquí es que sea más fácil impulsar una ejecución predecible por aumento de tarifas a través de ‘salidas ancla’: salidas en la transacción de compromiso que están diseñadas para ayudar a aumentar estas comisiones con CPFP.”

Alex Bosworth, desarrollador en Ligtning Labs.

En la publicación disponible en el repositorio, el desarrollador y CTO de Lightning Labs, Olaoluwa Osuntokun (Roasbeef), expone que la intención es garantizar que las transacciones potencialmente vulnerables, las atadas a HTLC, lleguen a tiempo a un bloque de Bitcoin para así evitar el reclamo de fondos por parte de un posible atacante.

Los HTLC se usan para el funcionamiento en red de los canales de pago de Lightning. Estos contratos establecen una garantía de que los canales intermedios usados en el proceso no se apoderarán maliciosamente de los fondos, aunque este proceso tiene un período de caducidad medido en bloques de la cadena de Bitcoin. En casos como el del cliente lnd, el límite es de 10 bloques.

El ataque que inundó todo

Recientemente, los investigadores Jona Harris y Aviv Zohar, de la Universidad Hebrea de Jerusalén, publicaron una investigación que explica una vulnerabilidad y posible ataque que pondría en peligro los fondos en la red de canales de pago de Bitcoin.

Una de las características del ataque explorado por los investigadores nace de la imposibilidad de los dueños de los canales atacados de fijar sus propias tarifas para las transacciones. Las víctimas dependen de las comisiones fijadas al momento de la apertura del canal, que podrían no corresponderse con las necesarias en un escenario de gran congestión de Bitcoin.

“Nuestro ataque se hace aún más fácil ya que el protocolo Lightning permite al atacante aumentar la tarifa ofrecida por sus propias transacciones”, escribieron en su reporte los investigadores.

Como reportó CriptoNoticias en su momento, Zohar y Harris evaluaron en su estudio posibles formas de mitigar el riesgo, entre los que destaca precisamente el método de las anclas, buscando la garantía de confirmación de las transacciones que buscaría impedir el atacante.

Para este mecanismo, se implementaría el uso de CPFP (los niños pagan por los padres). Los CPFP permiten acelerar transacciones mediante el envío de una nueva transacción que gaste fondos de la transacción no confirmada, pero con comisiones más altas que garanticen su inclusión en un bloque rápidamente.

La respuesta de los canales ancla

La solución que exploran actualmente los desarrolladores de lnd busca garantizar que los HTLC y el cierre de canales lleguen a tiempo a sus bloques incluso en escenarios de congestión de la red principal de Bitcoin.

“Uno de los objetivos principales de los productos de anclaje es poder ajustar las tarifas para garantizar que tanto la transacción de compromiso como los HTLC posiblemente disputados lleguen al bloque a tiempo.”

Olaoluwa Osuntokun (Roasbeef), desarrollador.

La principal novedad de esta propuesta, a efectos prácticos, es la capacidad de ajustar las comisiones de las transacciones para confirmar HTLC en función del estado de la red Bitcoin para asegurar la confirmación necesaria. Para ello, se definirían tiempos límite de ingreso en un bloque de los HTLC.

Entre los comentarios en el Github, el colaborador yyforyongyu ha planteado establecer rangos de acción estandarizados para fijar los aumentos de comisiones.

En su planteamiento, yyforyongyu comenta la posibilidad de tomar tres acciones distintas dependiendo de los escenarios. Suponiendo que el bloque límite establecido para la confirmación del HTLC esté todavía lejano, no se apuraría la transacción con nuevas comisiones. En caso de que la cantidad de bloques esté a una distancia intermedia, podría hacerse un ajuste paulatino de las comisiones. Pero si faltan muy pocos bloques, se elevaría a la máxima comisión para garantizar la confirmación.

Uno de los problemas que enfrenta la propuesta surge del monto total del botín al que apunte un potencial atacante. Entre los comentarios, el desarrollador Joost Jager (de Lightning Labs) se preguntó cuánto sería la comisión máxima que se estaría dispuesto a pagar para evitar un potencial robo.

Para yyforyongyu, ese monto lo establece el usuario. Aunque, más que el problema, este colaborador considera el esfuerzo de la propuesta como una forma de aumentar “las posibilidades de éxito” ante los escenarios que plantea la vulnerabilidad.

Posible llegada de la solución a la red Lightning de Bitcoin

Los ataques por inundación no son una novedad en el ecosistema de la red Lightning de Bitcoin. Ya a comienzos de marzo, CriptoNoticias reportó los hallazgos de un estudio que apuntaba hacia esta vulnerabilidad.

En ese informe, el propio Zohar (co-autor del estudio más reciente) y Ayelet Mizrahi habían establecido la vulnerabilidad de LN a ataques de congestión en los canales de pago. Además de Lightning, otras redes de canales de pago, como Raiden, serían vulnerables ante estos escenarios, reportaron los investigadores en ese momento.

La propuesta de los canales ancla fue creada en Github a mediados de abril de este año. Pero no ha sido sino hasta comienzos de julio cuando comenzaron a participar y comentar diversos desarrolladores. Esta activación del proyecto coincide con la publicación del informe de Zohar y Harris.

Anteriormente, en junio, Roasbeef comenzó con el desarrollo de esta solución. Ese mismo mes, el desarrollador estableció la meta de tener lista esta respuesta a la vulnerabilidad para la próxima versión (0.12.0) de la implementación lnd de la red Lightning.

No hay de momento una fecha establecida para que eso ocurra. Y si vemos el avance del proyecto en Github para esa actualización de lnd, nos encontramos con que está en una fase temprana.

Siendo una red todavía en fase beta, es común el hallazgo de errores y vulnerabilidades en la Lightning Network de Bitcoin. Por ello, también las actualizaciones y soluciones son constantes.