El día de ayer en Reddit se ha publicado el caso de una persona que tenia canales abiertos en Lightning Network (LN) con un saldo de 4 BTC y que luego de algunos eventos técnicos que no ha podido manejar le han llevado a la pérdida del total de fondos. Quiero explicar lo que ha ocurrido para tenerlo como aprendizaje.
Lightning Network es una red que se aprovecha de la capacidad de Script de Bitcoin para generar una red paralela donde gestionar transacciones que se realizan a través de la apertura de lo que se conoce como canales entre dos llaves públicas. En este canal se producen un número de transacciones de manera más eficiente, por ende en menor tiempo de confirmación. De esta manera esta tecnología sirve mucho mejor para casos de uso que demandan confirmaciones en segundos, como los pagos digitales. Al momento de abrir un canal se efectúa una transacción en la red Bitcoin y al momento de cerrarlo se efectúa otra con la compensación, es decir se transfiere el saldo resultado de todas las transacciones que se han efectuado entre ambos.
Como en cualquier tecnología, existen diferentes implementaciones de la misma y esta persona utilizaba lnd. Había montado su nodo y luego de un tiempo lo dejo apagado. Cuando ha querido activarlo nuevamente el ordenador había sufrido algún problema que le ha llevado a intentar restaurar una copia de respaldo que tenía. Al activar esta copia y empezar a operarla se ha encontrado con problemas de sincronización que le ha llevado a ejecutar la orden con la opción --force, que significa forzar la operación. A partir de ese momento se han producido una serie de eventos que han resultado en el problema.
Lo que ha ocurrido es que, dado que LN se basa en la confianza de los estados de saldos, el protocolo también tiene mecanismos para prevenir que se aproveche del mismo. Un caso de aprovechamiento es cuando se efectúa una transacción de transferencia de fondos, pero previamente se anuncia el cierre del canal, lo que resultaría en que el destinatario no reciba los fondos en el canal y no se efectúe la compensación con el saldo que correspondería tampoco. El protocolo contempla que en ese caso, se devuelva los fondos del usuario al beneficiario de los mismos. Es decir, que quién pensaba hacer trampa sea penalizado perdiendo los fondos que había comprometido en el canal LN.
Involuntariamente, al utilizar esta opción de forzado, la persona se ha visto en esa situación y el protocolo ha actuado como debería haber actuado. Todo eso se conocía y sabía que seria así, por lo que no ha sido mayor sorpresa en el entorno técnico. Lo que sí habría que aprender de este caso es lo siguiente:
- No comprometer una cantidad grande de fondos en un nodo de LN. Aunque no ha sido el caso, tecnología, si bien es ya útil y se viene usando en el mundo, todavía está en desarrollo y por tanto puede estar expuesta a fallos, como todo software.
-
Mantener copias del estado. Las principales implementaciones de LN tienen mecanismos para mantener copias del estado de los canales. Esto es los balances y otros temas adicionales, que van mas allá de simplemente hacer una copia de la carpeta
.lnd. - Entender bien las funciones del software. Quizá aquí haya espacio para mejoras, como en todo, y las implementaciones deben hacer lo posible por indicar al usuario lo que se producirá al efectuar una determinada acción en la aplicación. Sin embargo, también es importante, aún mas para una tecnología nueva, el que el usuario entienda bien la misma y qué cosas le permite hacer el software que utiliza.
Sobre el último punto, en un reciente tuit, Rusty Russell ha comentado que lnd podría haberlo hecho mejor al no efectuar el cerrado de canales de manera que produzca un “breach-attack”, ataque de intrusión. Señala que c-lightning, implementación de Blockstream, intenta efectuar el cerrado mutuo en primer lugar, antes de forzar cualquier acción relacionada a los canales.