Lightning Network no puede bifurcarse exactamente como lo hace Bitcoin, pero está comenzando a ramificarse. El protocolo viable mínimo básico se especificó inicialmente en los documentos BOLT antes de que nada se pusiera en marcha en la red principal de Bitcoin, pero ese fue solo el punto de partida. Todavía hay muchas extensiones para construir en el protocolo y áreas con problemas de escala sin resolver. En general, el protocolo Lightning en sí mismo todavía tiene un largo camino por recorrer en términos de resolver los problemas existentes y volverse lo suficientemente robusto y escalable para servir como una red transaccional global además de Bitcoin.
Parte de la razón de ser de los sistemas de segunda capa como una solución escalable para Bitcoin, aparte de la realidad obvia de que las cadenas de bloques no escalan, es dejar espacio para una experimentación más sencilla. Cuando se trata de segundas capas como Lightning, no es necesario que todos acepten un cambio para probar algo nuevo. Siempre que lo que esté haciendo funcione con la funcionalidad de la capa base compatible con Bitcoin, solo dos personas pueden separarse y jugar con nuevas funciones sin necesidad de preocuparse por todos los demás que lo apoyan. Diferentes implementaciones están comenzando a aprovechar esta mayor libertad que la capa base de Bitcoin, y algunos miembros de los equipos Core Lightning (CLN), Lightning Network Daemon (LND) y Lightning Dev Kit (LDK) participaron en un panel muy interesante en Bitcoin 2022 para discutir algunas de las diferentes prioridades que cada equipo está tomando en términos de expandir el conjunto de funciones de sus clientes Lightning.
LND
LND, administrado por Lightning Labs, es la implementación de Lightning más ampliamente adoptada en la red, actualmente el backend de billeteras populares como Breez, Blixt, Zap y la aplicación Lightning de Lightning Lab antes de que dejara de desarrollarse. También impulsa empresas importantes como Bitrefill y Hodl Hodl. Una de las mayores deficiencias de LND ha sido la tasa de crecimiento masivo de su base de datos de estado de canales (que se optimizará en su próxima versión), pero aún es el líder actual del paquete en la red.
El equipo de Lightning Labs generalmente se ha enfocado en brindar sus propios servicios monetizados para ayudar a abordar las deficiencias inherentes al protocolo Lightning como el núcleo de su modelo comercial. En términos de la hoja de ruta actual a corto plazo, LND priorizó dos cosas diferentes como la principal prioridad de sus esfuerzos de desarrollo.
Primero está la implementación de Taproot para permitir una nueva estructura de transacciones para los canales (recuerde, todo lo que un canal es un conjunto de transacciones prefirmadas) para sentar las bases para futuras mejoras de privacidad. Uno de ellos es el cambio de contratos de bloqueo de tiempo hash (HTLC) a contratos de bloqueo de tiempo puntuales (PTLC). Actualmente, los HTLC son los que garantizan que un pago tenga éxito o falle en cada salto a lo largo de una ruta de pago; la preimagen del hashlock se libera y garantiza que el pago se realice para todos o no y se reembolse para todos. Los PTLC logran lo mismo usando firmas de adaptadores en lugar de hashes, lo que significa que cada salto a lo largo de la ruta no tiene el mismo hash que podría identificar un solo pago en múltiples saltos si una persona ejecuta varios nodos a lo largo de la ruta de pago. Si bien esto de ninguna manera es una solución de privacidad mágica para la red, es un componente básico hacia la privacidad integral una vez que se implementan otras soluciones.
El siguiente paso después de implementar los canales Taproot para Lightning es actualizar los canales en vivo en la red para usarlos. Hay 82,697 canales Lightning públicos a partir de este escrito. Con casi el uso más eficiente del espacio de bloques que contiene alrededor de 3300 transacciones, se necesitarían 25 bloques de solo cierres de canales para cerrarlos todos y otros 25 para reabrirlos como canales Taproot.
Supongamos que hay el doble de canales privados que públicos. Esto llevaría el total a alrededor de 150 bloques para cerrar y reabrir todos los canales Lightning existentes como canales Taproot, suponiendo que los bloques se llenen sin otras transacciones. Sin embargo, en realidad, esos bloques no estarán llenos solo de transacciones Lightning, por lo que este proceso podría demorar una semana o más para que toda la red se complete y actualice. LND planea implementar una función llamada “actualizaciones de canales sobre la marcha”, donde en lugar de cerrar los canales existentes y abrir otros nuevos, simplemente gasta el estado del canal existente (transacción prefirmada) en uno nuevo en lugar de en salidas que cerrar el canal en cadena. Esto tiene el costo de una transacción adicional para los cierres no cooperativos, pero permitiría a los operadores de nodos aprovechar las nuevas funciones basadas en Taproot sin tener que cerrar los canales existentes.
Obviamente, la implementación de Taro probablemente ocupará un lugar destacado en algún momento después de estos desarrollos, pero la implementación de un nuevo protocolo de token de capa superior probablemente llevará una cantidad significativa de tiempo. Dadas otras características que podrían ser una buena idea implementar, así como el trabajo diario de optimizar la funcionalidad existente del nodo, no creo que se sepa cuánto tiempo pasará hasta que vea la luz del día. =
CLN
CLN (anteriormente c-lightning), fue, a pesar de muchos informes de lo contrario en ese momento, la primera implementación de Lightning que se lanzó en mainnet en 2018. Toda la arquitectura de CLN se construyó en torno a la idea de la modularidad, de modo que diferentes las piezas del nodo (como las claves de manejo de piezas y la firma) se pueden intercambiar y personalizar fácilmente. Incluso hay un sistema de complementos diseñado para que los usuarios puedan escribir su propio comportamiento personalizado para interactuar con CLN y alterar la forma en que opera el nodo en ciertas situaciones o en respuesta a eventos específicos.
Un excelente ejemplo de esto es la funcionalidad de pago, que incluso se implementa como un complemento para el comportamiento de pago predeterminado que se envía con CLN. Esta es la parte del nodo que se encarga de averiguar las rutas de pago y enviarlas. Hay un gran catálogo de complementos disponibles, desde la gestión automatizada de nodos con CLBOSS, complementos de torre de vigilancia y lógica de sondeo automatizado, hasta la eliminación dinámica de Bitcoin Core para garantizar que CLN siempre tenga los bloques que necesita para mantenerse sincronizado. Puede encontrar una gran lista de complementos aquí.
El objetivo principal de CLN siempre ha sido la modularidad y la flexibilidad, y el equipo planea llevar esto al siguiente nivel con su paquete de software Greenlight. Greenlight separará aún más la funcionalidad de las diferentes partes del nodo hasta el punto de que los usuarios podrán almacenar y administrar sus claves y operaciones de firma en diferentes (e incluso múltiples) dispositivos desde donde se pueden ejecutar los canales de manejo del backend real del nodo y otros datos. en otro lugar, ya sea en la nube o incluso en un dispositivo alojado en casa. Breez Wallet incluso planea cambiar al uso de CLN/Greenlight y dividir las diferentes funciones de su billetera en aplicaciones separadas para aprovechar la libertad que permite esta arquitectura. Aplicaciones separadas para transmisión de podcasts, uso general de billetera, sistemas PoS, todo conectado al mismo nodo. Esto incluso abre la puerta para recibir pagos cuando su billetera móvil está fuera de línea, un problema importante en muchos casos de uso con Lightning. Un dispositivo de firma independiente podría dejarse en casa en línea todo el tiempo y programarse para firmar solo actualizaciones de canales cuando aumentan el saldo de su canal. Problema resuelto, ya no tienes que preocuparte por tener tu teléfono abierto todo el tiempo para recibir fondos.
La próxima prioridad de CLN será aprovechar el trabajo de Niftynei en los canales de doble financiación. Actualmente, al abrir un canal Lightning, solo un lado del canal proporciona un UTXO de financiación, dejando toda la liquidez en el canal del lado de esa parte. CLN actualmente admite el financiamiento dual en el que ambos lados del canal pueden contribuir con UTXO en la transacción de financiamiento, lo que permite que el canal comience en un estado equilibrado en el que ambos lados tienen fondos. Sobre la base de esta funcionalidad, actualmente está trabajando en la implementación del empalme, una característica largamente discutida para el protocolo.
El empalme le permitiría abrir y cerrar un canal en una sola transacción para agregar más fondos o eliminar algunos pero no todos los fondos del canal. Esto sería una gran victoria para la liquidez del canal. Imagina abrir un canal con alguien para que pueda recibir fondos y darte cuenta de que asignaste diez veces la cantidad que necesitaban. El empalme le permitiría eliminar el exceso sin interrumpir la capacidad de su par para recibir fondos y asignar su bitcoin a un lugar más productivo. Esta es una gran victoria tanto para los usuarios promedio como para los proveedores de servicios Lightning (LSP) y los nodos de enrutamiento. Les permitiría a todos utilizar su liquidez de manera más eficiente sin cerrar el canal para la otra parte.
LDK
Lightning Dev Kit no es tanto una implementación de nodo Lightning como una biblioteca que se puede usar para construir un nodo Lightning. Proporciona código para cada pieza aislada de un nodo Lightning, la lógica de enrutamiento, la gestión de canales, la lógica para monitorear el estado de la cadena de bloques para verificar si los canales están abiertos, todo el tinglado.
Blue Wallet está trabajando en una implementación basada en LDK, y también se está construyendo una nueva implementación de Lightning, Sensei, en torno a LDK. Cash App incluso construyó un nodo completamente desde cero. Cuando comenzó a buscar la integración de Lightning, quería integrar profundamente el comportamiento de sus nodos Lightning con el backend que manejaba los saldos de los usuarios de Cash App. Ninguna implementación existente permitiría una fácil integración hasta ese punto, por lo que personalizaron la suya usando LDK.
El equipo de LDK está asumiendo un esfuerzo muy diferente en comparación con otras implementaciones de Lightning. Como se señaló anteriormente, en realidad no es una implementación, sino más bien un juego de herramientas que se puede usar para crear uno usted mismo con el comportamiento personalizado que desea. Como tal, en realidad no está priorizando ningún conjunto de funciones específico sobre ningún otro. El objetivo de LDK es admitir ampliamente todas las funciones estándar del protocolo Lightning y permitir que los desarrolladores hagan uso de cualquier característica estandarizada de la forma que elijan en sus propias aplicaciones, o no.
El camino por delante
Una gran parte del argumento de Lightning fue facilitar pagos nativos en Internet para servicios digitales, pero la experiencia del usuario de ese objetivo no se ha materializado realmente de una manera sencilla y hábil.
LND, CLN y LDK han trabajado para abordar este problema. Web Assembly (WASM) es un nuevo lenguaje y formato binario para facilitar la ejecución de programas más eficientes y ligeros en el navegador web. LND y LDK tienen archivos binarios WASM para sus nodos, y CLN planea implementar herramientas de administración de claves para ejecutar en WASM que pueden conectarse a un nodo Lightning de forma remota, basándose en su trabajo Greenlight. Si bien hay problemas de seguridad a tener en cuenta al administrar claves en un navegador web, se acercan los días de integración perfecta de Lightning en la web.
Lightning como protocolo y red todavía tiene un largo camino por recorrer en términos de resolver problemas abiertos y descubrir cómo crear aplicaciones que sean fáciles e intuitivas para los usuarios finales, pero el trabajo está avanzando. Sin duda, se volverá más complicado a medida que los diferentes equipos diverjan y se centren en resolver diferentes problemas y ampliar la funcionalidad en diferentes direcciones, pero sin duda se está produciendo un progreso. Solo podemos esperar que las cosas no se desvíen hasta el punto de fragmentar la red y la compatibilidad del software. El camino por delante será muy interesante.
Esta es una publicación invitada de Shinobi. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.
