Búsqueda de Camino

Elegir una ruta — y entregar el pago

• Eric de Castro
• Atualizado em 07/06/2026

⚡ Lightning · Técnico

Con el grafo de canales en la mano, falta el último paso: elegir una ruta desde la origen hasta el destino y entregar el pago. A diferencia de Internet (donde cada router decide el siguiente salto), en Lightning es la origen quien calcula toda la ruta — es el source-based routing, y es lo que permite el enrutamiento onion.

El punto ciego: no conoces los saldos

Esto es lo que hace difícil la búsqueda de camino. Por el gossip, sabes que un canal existe, su capacidad y la política (comisión, cltv). Pero no sabes cómo está dividido el saldo entre los dos lados — y eso es justamente lo que determina si el canal puede reenviar tu valor en esa dirección.

Resultado: la búsqueda de camino es probabilística. Eliges un camino prometedor, pruebas, y si falla (por ejemplo, saldo insuficiente en algún salto), el error onion te dice dónde falló — y tú pruebas otra ruta.

La función de coste

Entre los caminos posibles, ¿cuál es el "mejor"? La cartera asigna un coste a cada arista y busca el de menor coste (normalmente con un algoritmo tipo Dijkstra, ejecutado de atrás hacia adelante, desde el destino hasta la origen — porque las comisiones y el cltv se acumulan en ese sentido). El coste combina:

• Comisión — base + proporcional (ppm) que cobra cada salto.
• Tiempo de bloqueo — un cltv_expiry_delta mayor inmoviliza tu dinero durante más tiempo si algo sale mal; eso tiene un coste.
• Fiabilidad — los canales que ya fallaron antes reciben una "penalización" para ser evitados en los siguientes intentos.

Compara rutas candidatas por la comisión total y por el CLTV total:

Comparador de Rutas

Comparador de Rutas

Compara rutas candidatas por comision, CLTV y una penalidad local ficticia. Es una heuristica didactica, no prueba liquidez real.

Valor a entregar (msat)

CLTV final minimo

Costo por bloque CLTV (msat)

Rutas candidatas

Una por linea. Formato: Nombre | base/ppm/cltv > base/ppm/cltv | penalidad_msat | probabilidad_0a100.

Rota A | 1000/100/40 > 1000/500/144 | 0 | 70 Rota B | 500/2000/80 > 2000/50/40 > 1000/100/144 | 1500 | 45 Rota C | 1200/50/34 > 800/80/40 | 4000 | 85

Resultado del comparador de rutas

Entrega: probar, fallar, probar de nuevo

Entregar un pago suele ser un ciclo:

1. elige la ruta de menor coste aún no descartada;
2. monta la cebolla y envía el HTLC;
3. si llegó, perfecto — el secreto vuelve y liquida todo;
4. si falló, lee el error onion, aprende de él (qué canal estaba sin saldo) y prueba la siguiente ruta.

Las implementaciones guardan lo que aprendieron sobre la red en esos intentos (en LND eso se llama mission control) para que las siguientes elecciones sean más certeras.

Pagos en partes (MPP)

¿Y si ningún camino único tiene saldo suficiente para todo el valor? Ahí entran los pagos multipartes (MPP, Multi-Part Payments): la origen divide el valor en fragmentos y envía cada uno por una ruta distinta. Todos los fragmentos llevan el mismo payment_hash, y un payment_secret los amarra. El destinatario solo rescata cuando la suma de los fragmentos recibidos coincide con el valor total — así que sigue siendo todo o nada.

¿Y los clientes ligeros?

Mantener el grafo entero y calcular rutas da trabajo — demasiado para una cartera de móvil. El trampoline routing resuelve eso dejando que el cliente ligero elija solo algunos nodos "trampolín" y delegue en ellos el cálculo del camino detallado, sin renunciar al enrutamiento onion.

Ya entendimos cómo el pago encuentra el camino. A continuación, volvemos al punto de partida de todo: la invoice (BOLT 11) — el pedido de pago que la origen lee para saber cuánto, para quién y con qué payment_hash.