Red Lightning
La Red Lightning (Lightning Network) es una red de canales de pago bidireccionales construida sobre Bitcoin. Los participantes bloquean bitcoins en canales y pueden actualizar la distribución de los fondos sin registrar cada pago en la cadena de bloques. Normalmente solo la apertura, el cierre o la ejecución de un canal necesita confirmación en la capa base.
Lightning está pensada para pagos frecuentes y relativamente pequeños que se benefician de menor latencia y comisiones. No aumenta la capacidad de bloques de Bitcoin; reduce la necesidad de publicar cada saldo intermedio e introduce riesgos propios de liquidez, disponibilidad, enrutamiento y software.
Diseño
Canales de pago
Dos participantes abren un canal con una transacción de financiación en cadena. Después intercambian transacciones de compromiso firmadas que representan la distribución vigente del saldo. Cada actualización válida sustituye a la anterior sin transmitirse inmediatamente a la cadena de bloques.
Por ejemplo, Alice y Bob pueden financiar un canal que asigne 0,06 BTC a Alice y 0,04 BTC a Bob. Si Alice paga 0,01 BTC a Bob, ambos firman un nuevo estado con 0,05 BTC para cada uno. Pueden seguir actualizando el saldo mientras el canal esté abierto sin publicar cada pago intermedio.
El protocolo desincentiva publicar una transacción de compromiso obsoleta. En el diseño tradicional basado en penalizaciones, la otra parte dispone de un periodo limitado para reclamar los fondos cuando se usa un estado antiguo. Por ello un usuario no custodial debe vigilar la cadena o delegar la vigilancia.
Pagos enrutados
Alice no necesita un canal directo con cada destinatario. Si tiene un canal con Bob y Bob posee liquidez saliente suficiente hacia Carol, el pago puede pasar por Bob. Una ruta real puede contener varios nodos intermedios.
Los contratos con hash y bloqueo temporal (HTLC) enlazan las transferencias. El destinatario revela un secreto criptográfico que permite liquidar la ruta; de lo contrario las transferencias caducan. Los nodos intermedios no reciben control unilateral de los fondos, aunque pueden cobrar por reenviar.
Las reglas interoperables se publican como especificaciones Basis of Lightning Technology o BOLT. Cubren mensajes entre pares, transacciones de canal, enrutamiento cebolla, difusión de red, facturas y negociación de funciones.[1]
Liquidez y enrutamiento
Un canal solo puede enviar el saldo disponible del lado del remitente y recibir hasta la capacidad libre en sentido contrario. Cada salto necesita liquidez suficiente en la dirección adecuada. La capacidad anunciada no equivale a lo que cualquier usuario puede enviar.
Los nodos pueden obtener liquidez entrante recibiendo pagos, abriendo o reorganizando canales, usando intercambios submarinos o comprando liquidez de canal a un Proveedor de servicios Lightning. Algunos proveedores pueden abrir un canal justo a tiempo cuando llega el primer pago entrante del cliente, en vez de exigir que compre un canal por adelantado.[2] Los operadores también pueden reequilibrar fondos entre sus propios canales. Estas operaciones tienen costes y pueden requerir transacciones en cadena.
El enrutamiento es probabilístico porque los saldos exactos no se publican globalmente y pueden cambiar. Las carteras pueden intentar otras rutas o dividir un pago. Un pago exitoso puede completarse en segundos, pero los intentos fallidos, pares no disponibles o liquidez insuficiente aumentan la latencia.
Cierre y ejecución de canales
Un canal puede permanecer abierto mientras las partes cooperen. En un cierre cooperativo acuerdan el saldo final y publican una transacción de cierre; suele ser más rápido y eficiente que la ejecución unilateral.
Si un par no está disponible o no coopera, la otra parte puede realizar un cierre forzoso publicando su compromiso más reciente. Los bloqueos temporales retrasan algunas salidas y el cierre consume espacio de bloque y comisiones. El plazo permite responder a un estado obsoleto.
La vigilancia puede delegarse a una watchtower. Esta supervisa la cadena y puede publicar una transacción de penalización o recuperación si detecta un cierre antiguo. No custodia los fondos, pero su disponibilidad y los datos de remedio preparados por la cartera forman parte del modelo de seguridad.[3]
Las copias de seguridad requieren cuidado: restaurar una base de datos de canales antigua no equivale a restaurar una cartera ordinaria y puede producir pérdida de fondos. Debe seguirse el procedimiento de la implementación concreta.
Velocidad, comisiones y carga de la cadena
Una ruta establecida con liquidez suficiente puede liquidar sin esperar un nuevo bloque. Esto sirve para puntos de venta y cantidades que serían antieconómicas como transacciones individuales de la capa base.
Los pagos no son necesariamente gratuitos. Un nodo puede cobrar una tarifa base, una proporcional o ambas; abrir y cerrar canales también exige comisiones en cadena. La ventaja depende del importe, la ruta, la liquidez y las comisiones vigentes de Bitcoin.
Como la mayoría de actualizaciones queda fuera de la cadena, normalmente solo las transacciones de financiación, cierre y ejecución llegan al libro de Bitcoin. Reutilizar canales reduce la carga por pago, pero no elimina la necesidad de espacio de bloque.
Privacidad y confianza
El enrutamiento cebolla BOLT proporciona a cada nodo solo la información necesaria sobre el salto anterior y el siguiente. Mejora la privacidad frente a publicar cada pago, pero no garantiza anonimato: las aperturas y cierres son públicos y el análisis de tiempo, importe, red o extremos puede revelar relaciones.
Dos participantes de un canal propio no entregan a un intermediario control unilateral de sus fondos. Sin embargo, una cartera no custodial deja las claves y obligaciones al usuario; una cartera custodial oculta la gestión pero exige confiar en la solvencia, seguridad y retiradas del proveedor.
Implementaciones
Entre las implementaciones independientes están LND, Core Lightning, Eclair y las bibliotecas Lightning Development Kit. Las BOLT permiten interoperabilidad, pero difieren APIs, almacenamiento, operación y ciclos de publicación.
Core Lightning, antes c-lightning, es una implementación de código abierto que funciona en la red principal de Bitcoin desde 2018.[4] En 2026 se divulgaron dos fallos remotos de denegación de servicio por consumo ilimitado de memoria. El problema de connectd se corrigió en 26.04 y el de gossipd en la línea candidata 26.06.[5] Afectaban a la disponibilidad del nodo, no al protocolo.
Otra noticia de agosto de 2026 no se incluye como hecho porque al preparar este borrador no existía un aviso público coincidente, divulgación técnica o versión corregida.
Limitaciones y fallos
- Liquidez: un pago puede fallar aunque el remitente tenga bitcoins si ninguna ruta dispone de capacidad en la dirección necesaria.
- Disponibilidad: pares y nodos necesitan conexión; recibir sin conexión exige soporte específico.
- Vigilancia: el usuario no custodial debe detectar cierres antiguos o usar una watchtower.
- Dependencia on-chain: apertura y ejecución dependen de confirmaciones y comisiones de Bitcoin.
- Complejidad: los nodos gestionan capital, conexión, copias, actualizaciones y tarifas.
- Fiabilidad: información obsoleta, nodos caídos, límites o cambios de liquidez pueden hacer fallar una ruta.
Lightning es una capa de pagos complementaria, no un reemplazo de la capa de liquidación de Bitcoin.
Historia
Joseph Poon y Thaddeus Dryja publicaron el documento de Lightning Network en 2015.[6] El diseño amplió trabajos anteriores sobre canales de Bitcoin con canales bidireccionales enrutados mediante bloqueos hash y temporales.
Los desarrolladores de c-lightning, Eclair y LND demostraron pagos interoperables en 2017. LND publicó su primera beta para la red principal en marzo de 2018 y las tres implementaciones tenían versiones beta en junio de 2018.[7][8] El desarrollo posterior mejoró el enrutamiento, pagos multiparte, watchtowers, gestión de canales, móviles y extensiones.
Véase también
Enlaces externos
Referencias
- ↑ Basis of Lightning Technology specifications, repositorio de especificaciones Lightning, consultado el 27 de agosto de 2026.
- ↑ bLIP 52: LSPS2 JIT Channel Negotiation, repositorio de especificaciones Lightning, consultado el 3 de septiembre de 2026.
- ↑ Watchtowers, Bitcoin Optech, consultado el 27 de agosto de 2026.
- ↑ Core Lightning documentation, Elements Project, consultado el 27 de agosto de 2026.
- ↑ Vulnerability disclosure: twin memory exhaustion DoS vulnerabilities in Core Lightning, Delving Bitcoin, 2026.
- ↑ The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments, Joseph Poon y Thaddeus Dryja, 2015.
- ↑ Announcing our first Lightning mainnet release, lnd 0.4-beta, Lightning Labs, 15 de marzo de 2018.
- ↑ Announcing c-lightning 0.6, Blockstream, 25 de junio de 2018.