Hechos clave:
-
Esta soluciĆ³n busca garantizar el cierre forzoso de canales dentro del tiempo lĆmite de los HTLC.
-
La propuesta comenzĆ³ a desarrollarse tras la publicaciĆ³n de la vulnerabilidad.
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.
