Nivel 4

Routing de pagos

Los pagos saltan de nodo en nodo hasta llegar al destino. Cómo se encuentran las rutas y quién cobra por enrutar.

El concepto de routing

Lightning no requiere canal directo entre pagador y receptor. Los pagos pueden "saltar" a través de nodos intermediarios.

Si Alice quiere pagar a Diana:

  • Alice tiene canal con Bob
  • Bob tiene canal con Carol
  • Carol tiene canal con Diana

El pago fluye: Alice → Bob → Carol → Diana

Cada salto mueve el balance dentro de un canal. El resultado neto es que Alice tiene menos bitcoin y Diana tiene más, aunque no tengan canal directo.

Path finding

¿Cómo sabe Alice qué ruta usar?

El software de Lightning (el nodo o la wallet) tiene un "graph" de la red: conoce los canales públicos, sus capacidades, y sus fees.

Cuando quieres pagar, el software calcula rutas posibles y elige la mejor según:

  • Menor fee total
  • Mayor probabilidad de éxito (canales con suficiente liquidez)
  • Menor número de saltos

Si una ruta falla (un canal no tiene liquidez suficiente), el software prueba otra automáticamente.

Onion routing

Por privacidad, Lightning usa "onion routing":

Cada nodo intermediario solo conoce:

  • De quién recibió el pago (el salto anterior)
  • A quién debe pasarlo (el salto siguiente)

Ningún intermediario sabe:

  • Quién es el origen original
  • Quién es el destino final
  • Cuántos saltos hay en total

Los datos están encriptados en "capas" (como una cebolla). Cada nodo descifra solo su capa, descubre el siguiente salto, y pasa el resto.

Esto proporciona privacidad significativa incluso para nodos que participan en el routing.

Fees de routing

Los nodos intermediarios cobran por enrutar pagos. Es su incentivo para mantener liquidez y conectividad.

Las fees tienen dos componentes:

Base fee: Cantidad fija por pago enrutado (ej: 1 sat)

Fee rate: Porcentaje de la cantidad enrutada (ej: 0.0001 o 10 ppm = 10 partes por millón)

Ejemplo: fee de 1 sat base + 10 ppm

  • Enrutar 100.000 sats: 1 + 1 = 2 sats de fee
  • Enrutar 1.000.000 sats: 1 + 10 = 11 sats de fee

Las fees totales son la suma de las fees de todos los nodos en la ruta.

Competencia de fees

Los nodos compiten por routing. Si tus fees son demasiado altas, los pagos eligen otras rutas. Si son demasiado bajas, no cubres tus costes de capital y operación.

Encontrar el punto óptimo es parte del arte de operar un nodo.

Herramientas automáticas ajustan fees dinámicamente según demanda y competencia.

HTLCs: el mecanismo técnico

El routing funciona mediante HTLCs (Hash Time-Locked Contracts):

  1. Diana genera un secreto aleatorio y envía su hash a Alice (en la invoice)
  2. Alice crea un HTLC con Bob: "Te doy X sats si me revelas el secreto del hash H, o me los devuelves en T tiempo"
  3. Bob crea un HTLC similar con Carol
  4. Carol crea un HTLC con Diana
  5. Diana conoce el secreto, lo revela a Carol y cobra
  6. Carol ahora conoce el secreto, lo revela a Bob y cobra
  7. Bob revela a Alice y cobra
  8. El pago se completó

Si algún paso falla (timeout), los HTLCs se resuelven devolviendo los fondos. Nadie puede robar: o todo funciona, o nada.

Implicaciones para usuarios

Usando wallet (Phoenix, Breez)

El routing es transparente. Tu wallet encuentra rutas automáticamente. Ves una pequeña fee de routing además de la fee de red.

Operando tu propio nodo

Decides:

  • Qué fees cobrar por routing
  • Con qué nodos conectar (afecta qué rutas pasan por ti)
  • Cómo balancear liquidez para maximizar routing útil

Un nodo bien posicionado con buena liquidez puede generar ingresos pasivos por fees de routing. Pero no es mucho dinero: estamos hablando de satoshis, no de fortunas.

La salud de la red

El routing es lo que hace a Lightning una red y no solo conexiones aisladas.

Para que funcione bien, necesita:

  • Nodos bien conectados que ruteen eficientemente
  • Liquidez distribuida (no concentrada en pocos canales)
  • Fees que incentiven mantener liquidez sin ser prohibitivos

Es un ecosistema en equilibrio dinámico.