La larga espera ha llegado a su fin: los miembros del equipo de c-lightning estamos muy felices de poder anunciar la versión 6.0 de c-lightning, un importante hito en el proyecto. Esta reescritura total de la implementación anterior es la primera versión de c-lightning que cumple con todas las especificaciones. Se aleja del protocolo utilizado al diseñar la especificación y migra hacia una nueva arquitectura que es modular y extensible y que se adapta mejor a las necesidades y la infraestructura del usuario.
Estadísticas de crecimiento de la red de Lightning
Hoy también es un día importante para el crecimiento y el desarrollo de la red de Lightning: ¡las tres implementaciones de Lightning (Eclair, lnd y c-lightning) ahora están en beta! Desde la introducción de la tienda de Blockstream en enero, la red de Lightning ha crecido exponencialmente. En el momento en que se anunció la tienda de Blockstream, la red de Lightning tenía un total de 46 canales abiertos y una capacidad de 0,682 BTC. Hoy, hay aproximadamente 7.800 canales abiertos con una capacidad de 26 BTC. ¡Eso equivale a un aumento de 16.856 % para los canales y de un 4.084 % en la capacidad de los canales en 6 meses!
Nuevas características
Si bien las nuevas características de la versión 6.0 son tantas que no es posible nombrarlas todas, las siguientes son las más interesantes y las de mayor impacto:
● Nodos livianos: Las versiones anteriores requerían que hubiera un nodo completo de bitcoind activo en paralelo con c-lightning para permitir el acceso a la red de Bitcoin. La versión actual aún requiere la herramienta de bitcoin-cli, pero ahora puede comunicarse con nodos remotos, incluidos algunos nodos livianos tales como los recortados. Esto permite ejecutar un nodo de c-lightning en el Raspberry Pi, así como en otros dispositivos de baja potencia.
● Se ha actualizado el protocolo gossip con el fin de utilizar un mecanismo de ancho de banda más liviano que solicite información específica, en lugar de intercambiar vistas completas de las redes, como era el caso en la versión anterior. Esto es de especial interés para dispositivos móviles y de baja potencia que, de otro modo, consumirían mucho ancho de banda y energía para descargar y verificar información que ya tienen.
● Estabilidad de API: Se han rediseñado la interfaz JSON-RPC de c-lightning y las bibliotecas de respaldo con el fin de minimizar los cambios en versiones futuras. Esta estabilidad de API debería promover que se desarrollen otros proyectos a partir de c-lightning ya que respaldaremos esta versión de la API en el futuro previsible y mantendremos la compatibilidad retroactiva en caso de implementar cualquier cambio.
● Monedero y sincronización: ahora c-lightning incluye un monedero muy completo que gestiona fondos tanto on-chain como off-chain. ¡Ya no se trabaja con transacciones en crudo! Se lleva a cabo un rastreo automático de todos los fondos, que vuelven al monedero interno lo antes posible sin que se requiera la interacción del usuario. Asimismo, el rastreo de blockchain ahora conserva una vista interna de la blockchain, lo que pone fin a las largas reexaminaciones de esta.
● Respaldo de TOR: ahora, c-lightning es compatible con los nodos que se conectan a través de la red TOR, de modo que se produce el registro automático como servicio oculto y se aceptan las conexiones entrantes a través de TOR.
● Se ha realizado una reestructuración integral de la lógica de pago con el fin de que permita los reintentos automáticos en caso de falla de ruta, la aleatorización de la selección de rutas y un mejor feedback sobre el estado actual de un pago.
● Y como siempre: desempeño, desempeño, desempeño.
Flexibilidad a través de la modularidad
La arquitectura de c-lightning se basa en un número de procesos de comunicación independientes, cada uno de los cuales tiene sus propias funciones. Eso permite una mejor integración con la infraestructura del usuario y una mejor adaptación a las necesidades de este. Por su diseño modular, es importante destacar dos daemons, gossipd y hsmd, que son globales para todos los canales.
En el caso de gossipd, permite la vista local de la red y su papel es encontrar una vía desde el origen del pago hasta su destino. La implementación por defecto intenta encontrar una ruta que equilibre razonablemente las tarifas, los límites de tiempo y la estabilidad. También oculta la ruta haciendo una selección arbitraria de un número de rutas posibles y retoca los montos y los límites de tiempo con el fin de ocultar los extremos de un pago. La implementación por defecto puede desactivarse fácilmente si el usuario tiene requisitos específicos de enrutamiento o si quiere implementar una política específica de enrutamiento, como por ejemplo seleccionar siempre la ruta que tenga los límites de tiempo más cortos o las tarifas más bajas.
En el caso de hsmd, gestiona todas las operaciones que tocan materiales criptográficos y controla los fondos en el canal. Es el único subsistema que tiene acceso a la clave privada del nodo. Eso significa que otros subsistemas no contienen información privada y deben comunicarse con el daemon hsmd para firmar o descifrar cualquier dato. Esta centralización de las operaciones criptográficas reduce la superficie que hay que proteger y posibilita una serie de aplicaciones interesantes. Si bien la implementación por defecto de hsmd ya brinda un buen nivel de seguridad mediante la separación de procesos y la capacidad de aumentar la seguridad a través de seguridad de nivel OS, como por ejemplo SELinux y AppArmor, puede reemplazarse fácilmente por una implementación que se comunique con un HSM físico. Además, reemplazar la implementación de hsmd permite llevar a cabo una operación acéfala, por ejemplo, ejecutar un nodo de c-lightning desde el hogar, con una aplicación móvil sincronizada que gestione las claves privadas, inicie los pagos o emita las facturas.
Esta separación de la funcionalidad de c-lightning en múltiples daemons no solo implica una mejora significativa en lo que respecta a flexibilidad, sino también en lo relativo a seguridad de nodos, ya que impide que un atacante interactúe directamente con cualquier cosa que esté en contacto con las claves privadas. Cada subsistema verifica de forma independiente la uniformidad del estado interno, desconecta un usuario y destruye el proceso si se detectan incongruencias. La arquitectura con múltiples daemons también permite el uso de Docker, SELinux y App Armor para restringir la información a la que tiene acceso cada daemon y las acciones que cada uno puede realizar.
Próximas novedades
A c-lightning le queda mucho trabajo por delante; trabajamos constantemente para desarrollar características y mejoras, así como para perfeccionar el desempeño, la estabilidad y la facilidad de uso. ¿Usted no pudo encontrar su característica favorita? ¿Quiere hacer algún comentario que podría resultar útil? Lo invitamos a abrir un debate en Github, mandarnos un mensaje a través de la lista de correos o comunicarse con nosotros a través de IRC.
En paralelo, también estamos trabajando para mejorar la especificación de Lightning y estamos realizando investigaciones sobre la próxima iteración posible del protocolo a través de iniciativas como la propuesta eltoo y propuestas ascendentes de Bitcoin tales como SIGHASH_NOINPUT.
También queremos agradecer a todos los colaboradores que, además de haber aportado código para c-lightning, fueron lo bastante #osados para ponerlo a prueba y hacer comentarios sobre lo que funciona y lo que podría mejorarse. ¡Y por último, queremos agradecer a los demás equipos de la red de Lightning, ACINQ y Lightning Labs, así como a los colaboradores individuales que hicieron sus aportes para que la comunidad de la red de Lightning sea un entorno tan abierto, agradable y colaborativo!