Enrutamiento en Lightning Network

El problema: enrutar sin revelar

Lightning Network es un grafo de canales peer-to-peer donde cada nodo conoce los canales públicos, pero no cuánta liquidez hay en cada lado ni los canales privados. Cuando Alice quiere pagar a Carol, necesita resolver tres problemas simultáneamente:

• Descubrimiento: ¿qué canales existen y entre qué nodos?
• Búsqueda: ¿cuál es una secuencia de canales con suficiente liquidez que conecte a Alice con Carol?
• Privacidad: ¿cómo ejecutar el pago sin que los nodos intermedios sepan quién paga a quién?

Lightning resuelve cada uno con un componente distinto: gossip para el descubrimiento, algoritmos de camino más corto para la búsqueda, y onion routing para la privacidad.

Gossip protocol: descubriendo la topología

Definido en BOLT 7, el gossip es el mecanismo por el cual los nodos anuncian al resto de la red:

• channel_announcement: la existencia de un canal público, identificado por su short channel ID.
• channel_update: los parámetros de enrutamiento: base fee, fee rate proporcional, cltv_delta, y capacidades mínima/máxima para HTLCs.
• node_announcement: metadatos del nodo (alias, color, direcciones de red, features soportadas).

Cada nodo almacena localmente una copia del grafo completo de canales públicos. Los canales privados no aparecen en gossip; quien cobra puede incluirlos como route hints en su factura (invoice). Según mempool.space, el 30 de agosto de 2026 el grafo público tenía 16.237 nodos y 32.674 canales.

Búsqueda de ruta: Dijkstra con restricciones

Con el grafo en memoria, el nodo que paga ejecuta un algoritmo de camino más corto (variante de Dijkstra) sobre un grafo ponderado donde cada arista tiene un costo que combina comisiones (una base en milisatoshis más una parte proporcional en ppm, partes por millón: base + importe × ppm ÷ 1.000.000, según BOLT 7), CLTV delta, y una probabilidad estimada de éxito basada en intentos previos.

El problema crítico: la liquidez de un canal no es pública. El gossip revela la capacidad total, pero no cómo está distribuida entre ambos extremos. Un canal de 10M sats podría tener 10M en un lado y 0 en el otro. El nodo solo puede estimar la distribución probabilísticamente y actualizar sus creencias tras cada intento. Esto se conoce como probabilistic pathfinding, implementado en LND, CLN y Eclair.

Inbound y outbound: las dos caras de la liquidez

Cada canal tiene dos capacidades desde el punto de vista de un nodo:

• Liquidez outbound: satoshis en tu lado. Es lo que puedes enviar.
• Liquidez inbound: satoshis en el lado del peer. Es lo que puedes recibir.

Gestionar este balance es una de las tareas operativas centrales de cualquier nodo Lightning activo, y ha dado lugar a servicios especializados (swaps submarinos, Liquidity Ads, Lightning Pool).

Onion routing: privacidad inspirada en Tor

Una vez encontrada la ruta, quien paga construye un paquete Sphinx (BOLT 4) en capas cifradas, una por salto. El diseño es análogo al onion routing de Tor:

• Cada nodo intermedio recibe un paquete que solo él puede descifrar con su clave privada.
• Al descifrar, obtiene: el siguiente salto, el importe a reenviar, el CLTV, y el paquete reducido para pasar adelante.
• Ningún nodo conoce la ruta completa: solo su predecesor y sucesor inmediatos.
• El paquete tiene siempre el mismo tamaño (1.366 bytes, de los que 1.300 son los datos de los saltos), rellenando los saltos no usados con ruido, de modo que ningún nodo puede inferir la longitud del camino por el tamaño.

Fallos y reintentos

Los pagos Lightning fallan con frecuencia por liquidez insuficiente, nodos offline o tarifas desactualizadas. Cuando un salto falla, el nodo devuelve un mensaje de error cifrado hacia atrás. Quien paga actualiza su grafo local y reintenta con otra ruta.

Para pagos grandes se usa MPP (Multi-Path Payments) y AMP (Atomic Multi-Path Payments): dividir el pago en varias fracciones que viajan por rutas distintas y se reúnen en el nodo de quien cobra. Así fallan muchos menos pagos.

Trampoline routing: para clientes ligeros

Mantener el grafo completo al día cuesta datos y batería en un móvil. El trampoline routing, una propuesta que todavía no forma parte de las BOLT, resuelve esto delegando la búsqueda de ruta en un nodo público ("trampolín"): el móvil construye una cebolla corta con un único salto trampolín, que construye internamente la ruta completa hasta el destino. El precio es la privacidad: el trampolín tiene que saber a quién va el pago para buscar la ruta (salvo que el destino use una ruta cegada).

Mejoras en curso

Rutas cegadas (blinded paths, BOLT 4)

Las facturas tradicionales incluyen route hints que revelan los canales finales de quien cobra. Los blinded paths permiten a quien cobra anunciar una ruta cuyos saltos finales están cifrados: quien paga construye la cebolla hasta el "punto de introducción", y a partir de ahí cada nodo recibe instrucciones que solo él puede abrir. Así ni siquiera quien paga conoce la identidad real de quien cobra. Son la base de BOLT 12 offers.

PTLCs y privacidad mejorada

La migración futura de HTLCs a PTLCs eliminará la correlación por payment hash a lo largo de la ruta y mejorará la privacidad del onion routing.

Enrutar un pago en Lightning es resolver un problema de búsqueda en grafos bajo incertidumbre, con restricciones económicas, sin comprometer la privacidad y casi siempre en segundos.