Enrutamiento en Lightning Network

El problema: enrutar sin revelar

Lightning Network es un grafo de canales peer-to-peer donde cada nodo solo tiene una visión parcial de la red. 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; el receptor puede incluirlos como route hints en su invoice. El grafo público a inicios de 2026 ronda los 12.000-15.000 nodos activos y unos 40.000-50.000 canales públicos.

Búsqueda de ruta: Dijkstra con restricciones

Con el grafo en memoria, el nodo emisor ejecuta un algoritmo de camino más corto (variante de Dijkstra) sobre un grafo ponderado donde cada arista tiene un costo que combina comisiones (base + proporcional al monto), 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, el emisor 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 monto 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 total (1300 bytes), 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. El emisor 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 reensamblan en el receptor. Esto mejora drásticamente la tasa de éxito.

Trampoline routing: para clientes ligeros

Un teléfono móvil no puede mantener el grafo completo en memoria. El trampoline routing 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 destino final no se revela al trampolín más de lo que ya se revelaría a cualquier router.

Mejoras en curso

Blinded paths (BOLT 12)

Las invoices tradicionales incluyen route hints que revelan los canales finales del receptor. Los blinded paths permiten al receptor anunciar una ruta cuyos saltos finales están cifrados: el pagador 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 el pagador conoce la identidad real del receptor. 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, completando la promesa de 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 en menos de un segundo. Es una de las piezas de ingeniería más sutiles del ecosistema Bitcoin.