Por Luis Carlos García

Desde 2016, año de publicación del documento «The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments», cada vez se oye hablar más de Lightning Network. Pero, ¿a qué nos estamos refiriendo? Estrictamente, Lightning es un protocolo de comunicación en una red informática, aunque también podemos incluir en su denominación al conjunto de nodos y canales que conforman la red que lo materializa y da soporte.

Está diseñado para transferir valor de forma segura, como Bitcoin —otro protocolo—, no obstante, este último no depende de Lightning para funcionar, no siendo cierto el inverso. Se dice que son soluciones de segunda capa —con Bitcoin como primera—, puesto que se construyen y funcionan a partir de una capa preexistente. Sin embargo, ambas atacan el mismo problema: el de la transmisión de valor a través de Internet.

A diferencia de Bitcoin, cuyo protocolo logra un consenso sobre una estructura de datos llamada cadena de bloques, usando pruebas de trabajo, Lightning no utiliza cadena de bloques, sino que hace uso de una red de canales de pagos que crean sus nodos. Es decir, Lightning Network no es una «tecnología blockchain» aunque necesite de esta para garantizar su correcto funcionamiento.

Origen

Podemos remontarnos hasta el principio mismo de Bitcoin para encontrarnos con el concepto de los canales de pago. El inventor de Bitcoin, Satoshi Nakamoto, en la versión 0.1 de su software incluye en el código un apartado donde plantea la posibilidad de realizar liquidaciones de saldos entre dos usuarios, movimientos que no necesariamente han de ser reflejados en la cadena de bloques. La contrapartida es que se requiere confianza entre ambos. Esta es la idea subyacente sobre la que se construye la estructura de Lightning Network.

Posteriormente surgieron ideas que mejoraban el proceso. Ideas como los canales bidireccionales, los sistemas de liquidación —requerían un procesador intermedio sobre el que era necesario depositar cierta confianza, que fraccionando pagos podría reducirse—, o los microcanales de pagos —sin depender de terceros, pero su sistema no era práctico debido a un diseño basado en bloqueos temporales del saldo, que necesitaban mucho tiempo de espera de recuperación de los fondos en caso de fallo en la transmisión del pago—.

Así se llega a principios de 2015, donde —gracias al trabajo de Joseph Poon y Thaddeus Dryja— se presenta un nuevo concepto conocido como «canales de Poon-Dryja». Este esquema añade a las propuestas anteriores la idea de intercambiar transacciones firmadas parcialmente junto con ciertas claves secretas. El mecanismo consigue la actualización del estado de los canales —su balance— en ambos extremos; lo que permite a una transacción saltar de unos canales a otros usando a los nodos como intermediarios e impidiendo a estos hacerse con los fondos.

Todo ello logra que Lightning sea visto con buenos ojos —facilitando su despliegue sobre la red Bitcoin—, puesto que mantiene una de las propiedades básicas e irrenunciables para la mayoría de los defensores de la tecnología Bitcoin, que consiste en no depender de terceros a la hora de transferir valor.

Necesidad

Uno de los problemas que presenta Bitcoin desde su origen es la falta de inmediatez de los pagos. Aunque la notificación de una transacción es instantánea —debido a su diseño de pagos irreversibles—, el receptor necesita esperar un tiempo durante el cual se acumule el trabajo que realiza la red, de tal forma que las probabilidades de que un agente malicioso —por un golpe de suerte— sea capaz de deshacer el pago, sean suficientemente pequeñas para el receptor. Esto se conoce como confirmaciones de la transacción y se corresponde con el trabajo acumulado que se materializa en la creación de bloques.

Para tener mayores garantías de irreversibilidad se deberá esperar a la inclusión de la transacción en un bloque y a la generación de algunos más sobre este. Un valor usado como estándar por el software desde los comienzos de Bitcoin era el de seis confirmaciones, lo que requiere una espera aproximada de una hora antes de poder disponer de los fondos. Además, la inclusión de la transacción en un bloque depende del uso de la red, lo que conduce —en periodos de alta demanda— a tiempos de espera largos para obtener la primera confirmación, o bien al abono de comisiones elevadas.

Una solución consiste en aumentar la carga de datos que se añade a la cadena, pero esto desembocaría en escenarios de requerimiento de hardware sofisticado que implicaría el uso de soluciones empresariales. Ello dañaría una característica fundamental de Bitcoin: el ser una red entre iguales (P2P) —característica que una gran parte de su comunidad considera irrenunciable—. Lightning llega para atenuar estos dos problemas. De igual forma que no empleamos el mismo nivel de seguridad con 20 que con 200.000 euros, tampoco se requiere en Bitcoin. Lightning es una solución que se adapta especialmente bien a los micropagos, pues evita que sean registrados en la cadena principal, dejando así espacio libre a movimientos con elevados importes, que demandan mayor seguridad y que estarán dispuestos a pagar más por ella.

Los pagos en Lightning no necesitan confirmaciones para ser seguros, a la vez que permiten costes por transacción extremadamente bajos, puesto que no compiten por espacio en bloque ni requieren prueba de trabajo. Esto permitirá abrir Internet a toda una nueva economía en la que será factible el envío instantáneo de multitud de pequeñas cantidades de dinero a comisiones mínimas. Por ejemplo, en el pago por contenido, donde es muy interesante que la recepción del dinero sea inmediata y recurrente, de tal forma que el cliente va abonando a medida que consume pero no más.

La idea sobre la que funciona la red Lightning consiste en el depósito de una cierta cantidad de Bitcoins en un contrato entre dos participantes que funciona a modo de dirección multifirma. Esto requiere una transacción inicial, que deberá ser confirmada en la cadena de bloques de Bitcoin y que depositará dichos fondos en la cuenta multifirma que maneja el contrato del canal. El depósito corre a cargo de su creador —que es el emisor de la transacción—. Además, los usuarios pueden establecer por iniciativa propia canales con cualquier nodo de la red que les sea accesible.

Los dos participantes del canal se quedan con una copia del contrato. Este, básicamente, consiste en la firma de una transacción de liquidación con el último balance de la cuenta aún sin publicar.

En caso de hacerlo cualquiera de las partes, se realizaría un pago en la cadena de bloques de Bitcoin en el que se distribuirían los fondos del canal indicados en el contrato a sus respectivos propietarios. Una vez establecido el canal, se puede hacer un número indeterminado de modificaciones de su balance, que se refleja en una serie de nuevas versiones del contrato que ambas partes firman y almacenan. Puesto que estas modificaciones del balance del canal no se publican en la cadena de bloques —se producen de forma local—, Lightning permite realizar un número ilimitado de pagos que no tienen impacto sobre Bitcoin —mientras el canal permanezca activo—, funcionando así como una verdadera solución de escalabilidad para aquel.

La gran innovación que presenta Lightning es que los nodos permiten transferir pagos también entre usuarios que no tienen canales en común. Los nodos reciben saldo de uno de sus colaterales por un canal y lo devuelven por otro hacia un tercero sin que varíe su saldo total —sí lo hace el balance relativo de sus canales—. El mantenimiento de un nodo Lightning —actualmente también requiere la ejecución simultánea de un nodo completo de Bitcoin— está incentivado con el ingreso de comisiones por cada pago en el que intermedia. A mayor cantidad de fondos depositados en los canales del nodo Lightning, mayores posibilidades de intermediar en pagos, lo que se traducirá en ingresos más elevados. De todas formas, se espera que las comisiones por transacción en Lightning se mantengan permanentemente muy contenidas, puesto que dichos nodos no necesitan realizar ningún tipo de prueba de trabajo. Otro detalle relevante es que no pueden quedarse con el dinero de las transacciones en las que intermedian puesto que, o bien el pago es recibido por el destinatario por muchos nodos que atraviese, o bien el pago no circula por ninguno de ellos —no es posible que la transacción quede bloqueada en algún punto intermedio—.

Implementaciones

Existen tres equipos de referencia trabajando en diferentes alternativas para el software que ha de funcionar como nodo o monedero dentro de la red, que son: Lightning Network Daemon (LND), la versión de Lightning Labs; c-Lighting, que es la propuesta de Blockstream; y Eclair, la implementación del grupo francés Acinq. Ahora mismo solamente se dispone de software en estado alfa o calificado de beta —de pruebas— por sus creadores, como puede ser la versión del nodo LND o el monedero para Android desarrollado por Acinq. En todo caso, estamos siendo testigos de los primeros pasos de una nueva tecnología, donde sus actuales usuarios —aún pioneros— se exponen a errores importantes en el código de las aplicaciones que podrían conducir a pérdidas de fondos. Por ello, las cantidades que pueden arriesgar aquellas personas interesadas en participar en esta fase temprana no deberían ser muy significativas.

Retos

Un funcionamiento ágil de las transacciones en Lightning requiere la disponibilidad de suficientes canales que permitan encontrar fácilmente rutas de pago entre dos usuarios. Esto se logra mediante automatismos que crean nuevos canales con nodos al azar utilizando el saldo disponible —no deposi- tado en canales— que contiene la cartera del nodo. Al establecer un canal con un nodo desconocido, todo el saldo de este pertenece al usuario que ha realizado la apertura.En esta situación,el balance del canal solamente permite gastar al usuario que ha creado el canal y recibir fondos a su colateral. A medida que los nodos gestionan pagos, los canales pueden pasar a un estado en el que sus propietarios poseen una fracción del total del saldo, permitiendo enviar o recibir por él, lo que mejora la dinámica de la red en su conjunto.

Un aspecto que también conviene tener en cuenta es la necesidad de conexión permanente con la red, con el objetivo de detectar intentos de liquidación de balances antiguos del saldo del canal —que beneficiarían al colateral fraudulentamente—. Ello requiere el cierre de este de forma unilateral por el presunto defraudador. La cancelación unilateral del canal arranca con un bloqueo temporal de la transacción de liquidación, plazo durante el cual se puede revocar dicha liquidación haciendo pública la versión más reciente del contrato —la revocación penaliza al defraudador entregando todos los fondos del canal a su contraparte para desincentivar esta práctica—. No obstante, la necesidad de vigilancia constante hace que, de momento, el monedero para Android, Eclair, de Acinq, no permita recibir dinero —evitando la posibilidad de robo mientras la aplicación permanece sin conexión, algo habitual en teléfonos móviles—.

Actualmente otro contratiempo es la dependencia de los canales de una IP fija en los nodos para mantener su estado como activo. Cambios en el valor de IP pueden dejar inactivos ciertos canales obligando a liquidarlos posteriormente, lo que supone transacciones en la cadena de bloques, diluyendo así la ventaja que aporta Lightning.

Mejoras

Se hace necesario recordar que esta tecnología apenas se está desplegando, de modo que se plantean muchas propuestas de mejora para ella. Algunos ejemplos son:

• Canales no dependientes de IPs. Basados en el identificador del nodo e independientes de su IP pública.

•Financiación dual de canales (dual-funded channels). La transacción de apertura puede ser financiada por ambos usuarios, lo que permite desde el momento inicial enviar o recibir pagos a través del canal recién creado.

• Pagos atómicos multirruta (atomic multi-path payments). Permiten enviar pagos superiores al saldo del mayor canal disponible mediante la unión de rutas con importes menores.

• Atalayas (watchtowers). Son servicios que vigilan la publicación de contratos con balances antiguos, logrando la revocación del intento de fraude para aquellas carteras en las que no es práctico mantener una conexión permanente a la red, como los monederos de los teléfonos móviles

• Empalmes (splicing). Consiguen aumentar o reducir los fondos depositados en un canal sin la necesidad de cerrarlo y abrirlo de nuevo, pudiendo utilizar el saldo antiguo mientras se confirma el nuevo.

• Intercambios atómicos (atomic swaps). Sirven para enviar pagos a usuarios de otras cadenas de bloques usando ciertos nodos de la red que funcionan como intercambios de criptomonedas —solo para monedas con Lightning implementado—.

• Factorías de canales (channel factories). Aprovechan la transacción de apertura para generar un canal especial que permite múltiples usuarios, también la creación y el cierre de un número ilimitado de subcanales entre usuarios dentro de la factoría sin la necesidad de ejecutar nuevas transacciones en la cadena de bloques.

Y aún más innovaciones propuestas, que una vez desarrolladas permitirán potenciar la funcionalidad de esta solución de segunda capa. Todo ello puede aliviar enormemente el problema del tamaño de la cadena con su consiguiente aumento en los tiempos de validación de bloques y transacciones, debido al crecimiento de la primera capa, y así mantener viva la posibilidad de que cada usuario verifique por sí mismo —sin necesidad de terceros— la validez de su propia copia de la cadena de bloques de Bitcoin.