Después de años de conceptualización y desarrollo, las primeras implementaciones de Lightning están ahora en beta. Como resultado, cada día aparecen más nodos en línea, un número creciente de usuarios están abriendo canales entre sí, y algunos comerciantes incluso empezaron a aceptar pagos de Lightning.
Pero por supuesto, estos son todavía los primeros días de Lightning Network. Aunque las principales implementaciones son utilizables y algunas wallets y otras aplicaciones están disponibles, se prevé que la red de pagos superpuesta de Bitcoin mejore en los próximos años en áreas que van desde la arquitectura de la red hasta la seguridad y la usabilidad, entre otras.
Estos son algunos de los proyectos más importantes de Lightning Network que están actualmente en desarrollo.
Canales con doble financiación
La Red Lightning consiste en una serie de canales de pago. Cada canal de pago existe entre dos usuarios, lo que permite que los fondos se envíen de un lado a otro.
Sin embargo, en esta primera fase de desarrollo, los canales de pago sólo pueden ser financiados por una de las dos partes. La parte financiadora debe primero realizar una transacción a su contraparte; sólo entonces puede esta última devolver un pago dentro del mismo canal de pago.
El white paper de Lightning Network, sin embargo, proponía canales de doble financiación, para los cuales ACINQ, la empresa que está detrás de eclair, también ha hecho una propuesta de especificación. Como su nombre indica, los canales de doble financiación permitirán a ambos usuarios financiar parcialmente un canal de pago mediante el depósito de bitcoin. Esto debería traer más flexibilidad a la experiencia del usuario de Lightning, ya que los usuarios pueden enviar y recibir pagos inmediatamente después de haber abierto un canal.
Intercambio de Submarinos
Para realizar un pago de Lightning, los usuarios deben depositar fondos en un canal de Lightning. Una vez en un canal, estos fondos no pueden ser enviados a direcciones Bitcoin regulares (en la cadena), a menos que el canal se cierre primero. Esto significa que Bitcoin en un canal Lightning está algo separado de Bitcoin en una billetera regular, no muy diferente a como el dinero en una cuenta corriente está algo separado de dinero en una cuenta de ahorros.
Pero hay soluciones para hacer que el cambio entre los pagos de Lightning y los pagos en la cadena sea más sencillo.
Una solución es el Intercambio de Submarinos (Submarine Swaps). Desarrollado por Alex Bosworth (pero conceptualizado por el CTO de Lightning Labs Olaoluwa Osuntokun incluso antes), Submarine Swaps esencialmente permite a los usuarios enviar pagos de Lightning a un intermediario en la Red Lightning; ese intermediario enviará la cantidad correspondiente de Bitcoin a una dirección de Bitcoin regular (en la cadena). También funciona al revés: los usuarios pueden enviar pagos regulares en la cadena al intermediario; ese intermediario enviará la cantidad correspondiente de Bitcoin a un nodo receptor de la Red Lightning.
Y lo que es más importante, con Submarine Swaps, esta conversión se hace "atómicamente". Utilizando un truco que ya está integrado en la Red Lightning, el pago de Lightning y el pago en cadena se pueden vincular de forma efectiva entre sí. Esto hace imposible que el intermediario robe fondos al no reenviar el pago. (De acuerdo con los usuarios, él podría cobrar una pequeña tarifa por su servicio).
Empalme
Otra solución para que la experiencia del usuario de Lightning sea más fluida se llama "empalme" (splicing). En esencia, el empalme permite a un usuario "recargar" fondos en un canal de Lightning existente, o "drenar" fondos del mismo, manteniendo potencialmente el canal abierto.
La idea es simple. Cualquier canal de Lightning comienza con una transacción de apertura, lo que asegura que ambos usuarios aprueban el movimiento de los fondos en el canal. El resto del canal Lightning consiste en una serie de transacciones posteriores intercambiadas entre los usuarios, que no suelen ser emitidas a la red Bitcoin. Los fondos en la transacción de apertura no se mueven hasta que se cierra el canal.
Cuando se "empalma", los usuarios toman la transacción de apertura para enviar fondos a una transacción de apertura de reemplazo, que incluye más Bitcoin, de uno o ambos usuarios. Una vez que esta nueva transacción de apertura se confirma en la cadena de bloques, el canal se llena. Hasta que se confirme la nueva transacción de apertura, los dos usuarios pueden simplemente actualizar tanto el canal antiguo como el nuevo al mismo tiempo para evitar cualquier "tiempo de inactividad del canal".
Por el contrario, cuando se "desligan", los usuarios toman la transacción de apertura para enviar fondos a una dirección regular (en la cadena), y potencialmente mantienen parte de ella en el canal usando el mismo truco. De esta manera, los usuarios pueden realizar transacciones en cadena directamente desde un canal Lightning.
Eltoo
Cada vez que se realiza un nuevo pago, los canales de Lightning entre usuarios se actualizan para reflejar sus saldos mutuos. El truco utilizado para lograr esto actualmente incluye una penalización para los usuarios que intentan engañar transmitiendo un saldo mayor (presumiblemente porque ese saldo mayor les pagaría más). Los usuarios que hacen trampa pueden perder todos los fondos que tienen en un canal.
El problema es que la emisión de viejos balances no siempre es un intento de engaño. Hay una serie de escenarios en los que los usuarios pueden transmitir accidentalmente un saldo más antiguo; por ejemplo, debido a un error de software o a una copia de seguridad que ha salido mal. En tales escenarios, la pérdida total de los fondos del canal es un castigo bastante severo.
Publicada por primera vez el 30 de abril de 2018, ELTOO es la propuesta más reciente presentada en este artículo. Desarrollado por el equipo de desarrollo de c-lightning de Blockstream –Dr. Christian Decker y Rusty Russell– y Osuntokun de Lightning Labs, eltoo actualiza un canal mediante la construcción de una cadena de transacciones bloqueadas por tiempo, donde cada transacción gasta fondos del anterior para reflejar el último balance del canal.
Si un usuario emite una transacción anterior (que representa un saldo de canal más antiguo), su contraparte tiene tiempo para emitir la última transacción (que representa el saldo de canal más reciente).
Una solución como esta podría funcionar hoy en día, pero no es práctica en casos de fracaso. Requeriría que toda la cadena de transacciones se emitiera y grabara en la cadena de bloques de Bitcoin, lo que iría más o menos en contra de la finalidad de la red Lightning. Por lo tanto, Decker propuso un cambio en el protocolo de Bitcoin para introducir un tipo de jerarquía en este tipo de transacciones: cualquier transacción más reciente puede anular cualquier transacción anterior sin requerir que todas las transacciones de toda la cadena sean emitidas.
Si este soft fork se adopta y activa en la red Bitcoin, los usuarios de Lightning podrían crear canales tanto en el estilo actual como utilizando eltoo, dependiendo de lo que prefieran.
Filtrado de bloque compacto del lado del cliente
Mientras que la Red Lightning es un protocolo de segunda capa, la propia cadena de bloques Bitcoin sigue siendo relevante para los usuarios de Lightning por motivos de seguridad. Específicamente, los usuarios de Lightning deben vigilar la cadena de bloqueo para ver si se incluyen transacciones específicas. Esto puede requerir muchos recursos, en particular para los usuarios móviles.
Una solución para esto se llama Verificación de pago simplificada (SPV) y se describe en el libro blanco de Bitcoin. Las carteras actuales de las SPVs utilizan un truco llamado "filtros Bloom" para averiguar si se ha producido alguna transacción relevante.
Desafortunadamente, los filtros Bloom son poco amigables con la privacidad, ya que las billeteras revelan esencialmente todas sus direcciones a los nodos de la red Bitcoin. También tienen algunos problemas de escalabilidad y usabilidad, ya que cada cartera de SPV individual consume recursos de al menos un nodo completo de Bitcoin.
Para abordar estos problemas, Osuntokun y Alex Akselrod de Lightning Labs, junto con el desarrollador de Coinbase Jim Posen, diseñaron una nueva solución llamada "filtro compacto de bloques del lado del cliente", que están implementando en la cartera de Neutrino.
El filtrado compacto por el lado del cliente invierte esencialmente el truco que utilizan las carteras SPV actuales. En lugar de carteras que solicitan transacciones relevantes para ellos creando y enviando un filtro Bloom a los nodos completos, los nodos completos crean un filtro para todas las carteras de Neutrino. La billetera Neutrino utiliza este filtro para establecer que la transacción relevante no ocurrió - que es realmente todo lo que los usuarios necesitan saber para estar seguros de que no están siendo engañados. (Si el filtro produce una coincidencia, Neutrino obtiene el bloque correspondiente para ver si la coincidencia se refiere realmente a la transacción exacta en lugar de a un falso positivo).
Curiosamente, aunque este truco fue diseñado pensando en la experiencia de Lightning, también podría ser utilizado para beneficiar a las billeteras ligeras regulares.
Torres de vigilancia
Para evitar ser engañados, los usuarios de Lightning deben hacer un seguimiento de las transacciones potenciales en la cadena que puedan ser relevantes para ellos.
Mientras que el filtrado compacto por el lado del cliente debería hacer las cosas mucho más fáciles, los usuarios necesitan "registrarse" de vez en cuando para asegurarse de que no están siendo engañados. Si se olvidan de comprobarlo, se crea un riesgo para la seguridad.
Las "torres de vigilancia" (Watchtowers) son una solución potencial que se puede rastrear hasta el libro blanco de la Red Lightning y que desde entonces ha sido mejorada por el coautor del libro blanco de la Red Lightning y el desarrollador de lit Tadge Dryja y otros. Como su nombre indica, las Watchtowers podrían permitir a los usuarios externalizar la supervisión de la cadena de bloqueo a terceros.
Los diseños actuales de las Watchtowers no están grabados en piedra, pero funcionarían de esta manera. Cada vez que los usuarios actualizan un canal, envían un pequeño paquete de datos a una Watchtower. La primera parte de este paquete es un "indicio" de una transacción que deben buscar, como si fuera una pieza de un rompecabezas. Esta pista por sí sola no revela nada sobre el contenido de la transacción que la Watchtower debe tener en cuenta; los usuarios no renuncian a la privacidad en este sentido.
Sin embargo, si la transacción relevante aparece en la cadena de bloques Bitcoin, la Watchtower puede usar la sugerencia para reconocerla. Luego, con los datos de la transacción en la propia cadena de bloques, la Watchtower puede utilizar la segunda parte del paquete que ha recibido para reconstruir la transacción de penalización. Esta transacción de penalización envía todos los fondos del canal al usuario que está siendo engañado. La transacción de penalización también puede ser diseñada para permitir a la Watchtower reclamar parte de los fondos como recompensa, como incentivo para hacer su trabajo.
Los usuarios pueden externalizar la monitorización de canales a múltiples Watchtowers. Incluso si uno falla, otro podría no hacerlo, limitando el riesgo para los usuarios de Lightning hasta el punto de que se puede decir que es insignificante.
Pagos atómicos multitrayecto
Lo que hace de la Red Lightning una red es que los canales de pago entre usuarios están interconectados. Los usuarios pueden pagar a través de canales de pago, a través de pares en la red que actúan como "intermediarios", a usuarios con los que no tienen un canal directo abierto.
Sin embargo, ahora mismo un solo pago debe ser enrutado a través de una sola ruta. Si un usuario quiere pagar 5 mBTC a otro, no sólo debe tener 5 mBTC en un solo canal, sino que todos los intermediarios en la ruta también deben tener 5 mBTC listos en un canal para reenviar. Cuanto mayor sea el pago, menores serán las probabilidades de que esto ocurra.
Los pagos atómicos multitrayecto (AMP) podrían contribuir en gran medida a resolver esta limitación. La idea, propuesta por primera vez por Osuntokun y Conner Fromknecht de Lightning Labs, es simple: Los pagos más grandes se pueden "cortar" en pedazos más pequeños, todos los cuales tienen su propia ruta desde el que paga hasta el que recibe el pago, a través de diferentes intermediarios.
Un desafío para realizar esta solución es que los pagos de Lightning pueden fallar, lo que en este caso significaría que un pago se realiza parcialmente. Sin embargo, los pagos parciales pueden ser fácilmente un problema mayor que la falta de pago: un comerciante no estará satisfecho con un pago parcial, mientras que un cliente no estará contento de gastar dinero por nada.
La solución a este problema es que los AMPs utilizan una extensión de los contratos de hash con bloqueo de tiempo, que ya se utilizan a lo largo de las rutas de Lightning y que implican la transmisión de datos secretos a través de una red. Utilizando un truco similar al utilizado por las carteras determinísticas (que generan múltiples direcciones Bitcoin a partir de una sola semilla), las piezas más pequeñas de un pago mayor sólo pueden ser redimidas por el beneficiario si todas ellas lo son: si algunos datos secretos no pasan por toda la ruta, el pago completo falla.
Intercambios Atómicos
La Red Lightning está diseñada como una capa de escalado para Bitcoin. Pero como muchos altcoins son forks de software de las bases de código de Bitcoin, a menudo no es difícil crear capas de escalado similares para estos altcoins. Ya existe una pequeña Red Lightning de Litecoin, y es probable que le sigan más redes de Lightning.
Curiosamente, estas redes no necesitan permanecer separadas en el futuro.
Utilizando un componente fundamental de la Red Lightning llamado "atomic swaps" o “intercambios atómicos” (primero propuesto por Tier Nolan y realizado en Lightning por Fromknecht de Lightning Labs), los canales de pago pueden ser conectados a través de diferentes cadenas de bloques. En otras palabras, un usuario puede enviar Bitcoin, y mientras un nodo de la red esté dispuesto a hacer el intercambio, otro usuario puede recibir el pago como Litecoin.
Por supuesto, esto también significa que los usuarios pueden enviarse tales pagos a sí mismos: pueden enviar Bitcoin y recibir Litecoin. En efecto, la Red Lightning podría establecer una red de intercambios de criptomonedas sin confianza.
Para obtener más información sobre este tema, véase "Intercambios atómicos: Cómo se extiende la Red Lightning a Altcoins".
Fábricas de canales
El principal beneficio de Lightning Network es, sin duda, su potencial para aumentar enormemente el límite superior de las transacciones de Bitcoin sin que ello suponga una carga para la red Bitcoin. Mientras dos usuarios tengan fondos en su canal, pueden pagarse mutuamente un número virtualmente ilimitado de veces, mientras que sólo se requieren dos transacciones en cadena: una para abrir un canal de pago y otra para cerrarlo.
Aún así, dos transacciones por canal de pago podrían sumar si Bitcoin y la Red Lightning ganan más adopción con el tiempo.
Una propuesta de los investigadores de ETH Zurich Christian Decker (también de Blockstream), Roger Wattenhofer y Conrad Burchert llamada "Channel Factories" (Fábricas de Canales) podría reducir aún más el número medio de transacciones en la cadena requeridas por canal de pago, quizás de forma significativa.
Basadas en una propuesta anterior de Decker y Wattenhofer de 2015, las Fábricas de Canales son un tipo de canal de pago que puede existir entre muchos usuarios. Mientras tanto, como cualquier otro canal de pago, una Fábrica de Canales sólo requiere dos transacciones en cadena. (Si las firmas Schnorr se implementan en Bitcoin, estas transacciones podrían ser bastante compactas, incluso si involucran a muchos usuarios).
Las fábricas de canales pueden, a su vez, actuar como "subcanales" para la Red Lightning. Los participantes dentro de una Fábrica de Canales pueden abrir y cerrar un número virtualmente ilimitado de canales de rayos entre sí, sin requerir ninguna transacción adicional en la cadena. De esta manera, en teoría, podrían reducir en una magnitud el número de transacciones en cadena necesarias para la Red Lightning.
Agradecimientos al desarrollador de Blockstream Christian Decker, al desarrollador de Lightning Labs Conner Fromknecht, al CEO de ACINQ Pierre-Marie Padiou y a otros por su información y comentarios.
Gracias a Aaron van Wirdum por el texto. Versión original en inglés: The Future of Bitcoin: What Lightning Could Look Like.
Join the conversation.