En Lightning Network, normalmente el remitente construye la ruta. A partir del grafo público de gossip, los datos del receptor y sus propios resultados estima un camino al destino; calcula hacia atrás importe, comisión y CLTV de cada salto, encapsula las instrucciones en un paquete onion y, si falla, prueba otra ruta. Como el grafo público no muestra el reparto actual de saldos, el routing es una decisión probabilística con información incompleta y cambiante.
El routing empieza en el payer: su wallet o node elige una path candidata al payee e indica el siguiente channel a cada intermediario. El receptor aporta identidad, features y quizá route hints o blinded paths, pero el remitente calcula normalmente la parte pública.
BOLT #7 difunde anuncios y channel updates direccionales con base fee, fee proporcional, CLTV delta, mínimos, máximos y disponibilidad. Describen policy y topología anunciadas; no prueban que el peer esté online ni que haya liquidez suficiente ahora.
El gossip público no revela el reparto del balance. El router combina liquidez local conocida, capacidad, éxitos, fallos, penalizaciones y scoring propio. La ruta teóricamente más barata puede no ser la más probable.
Importes y expiraciones se construyen desde el payee hacia el payer. Cada node recibe el importe del siguiente hop más su fee y un CLTV superior al outgoing CLTV por su delta; más hops aumentan fees y margen temporal.
BOLT #4 usa onion routing: el payer crea un paquete Sphinx con payload cifrado por hop. Un intermediario conoce peers adyacentes e instrucciones, no la ruta completa, longitud o posición; análisis de tráfico y colusión aún pueden reducir privacidad.
Fallos temporales, fee insuficiente, CLTV incorrecto o next peer desconocido devuelven una señal limitada. La implementación penaliza, recalcula y reintenta; un resultado no describe permanentemente el channel.
Cada hop debe aceptar el HTLC y tener liquidez útil en la dirección correcta tras reservas, pending HTLC y límites mínimos y máximos. Capacidad total y muchas conexiones no eliminan un channel desequilibrado.
Con basic MPP, el payer divide total_msat entre varias paths y el receptor liquida el conjunto. MPP aprovecha liquidez dispersa, pero añade HTLC, intentos y fees y no crea capacidad direccional.
Los route hints BOLT 11 revelan hops finales privados; BOLT 12 y route blinding entregan una cola cifrada mediante un introduction point. El payer aún debe llegar al primer punto y respetar fees y CLTV agregados.
Registre implementación, versión, amount, máximos de fee y CLTV, intentos, paths, tiempo y fallo exacto. Compare los mismos nodes en momentos cercanos: el éxito pertenece a un pago y estado concretos, no a una puntuación global. Fuentes: BOLT #4 — Onion Routing Protocol; BOLT #7 — P2P Node and Channel Discovery; BOLT #11 — Lightning Payment Encoding; Lightning Labs — Pathfinding; LDK — Routing and Route Parameters.
Para obtener la imagen más completa, lee esta entrada junto con Lightning Network, HTLC, Liquidez de Lightning, Payment Channel, Bitcoin, Inbound Liquidity. También enlazan con esta entrada HTLC, Liquidez de Lightning, BOLT 12, Inbound Liquidity.