Cómo funciona un pago Lightning: canales, liquidez y routing
Todo el viaje de un pago Lightning, desde que pulsas enviar hasta que llega al destino en milisegundos.
El viaje real de un pago
Cuando envías sats por Lightning, no estás escribiendo una transacción nueva en la blockchain. Estás actualizando estados de canales ya abiertos entre nodos. Tu wallet calcula una ruta, reserva liquidez en cada salto y ejecuta un flujo atómico basado en HTLCs. El receptor solo cobra si el pago llega completo; si no llega, todos recuperan su saldo original.
El pago suele tardar menos de un segundo, pero internamente ocurren varios pasos: búsqueda de ruta, validación de capacidad, negociación de condiciones y propagación del preimage de vuelta.
Canal de pago: la unidad base
Un canal Lightning nace con una transacción on-chain 2-de-2 multisig. Dentro del canal, dos partes intercambian nuevos estados firmados sin tocar la cadena base en cada pago. Solo apertura y cierre son on-chain.
Cada actualización invalida el estado anterior. Si una parte intenta publicar un estado antiguo para robar saldo, la contraparte puede ejecutar penalización y quedarse con todos los fondos del canal. Esa amenaza económica protege el protocolo.
Liquidez entrante y saliente
La liquidez define si puedes enviar o recibir. Si abres un canal con 500.000 sats desde tu lado, inicialmente tienes casi toda la liquidez para enviar y casi nada para recibir. Para recibir, necesitas que parte del saldo esté del lado remoto o que un LSP te abra capacidad entrante.
Abrir un canal no significa automáticamente poder recibir. Sin liquidez entrante, el pago fallará aunque tengas saldo total suficiente en Lightning.
Routing: encontrar camino en un grafo vivo
La red pública de Lightning es un grafo de nodos y canales. El emisor calcula rutas probables según capacidad, coste y fiabilidad histórica. Si una ruta falla, la wallet intenta otra automáticamente.
En móviles se usan estrategias como trampoline routing para delegar parte del cálculo a nodos bien conectados, reduciendo coste computacional local.
HTLC: atomicidad del pago
El receptor define un secreto (preimage) y publica su hash en la invoice. Cada salto de la ruta bloquea el monto bajo la condición “te pago si presentas el preimage antes de cierto tiempo”. Cuando el receptor revela el preimage para cobrar, el secreto vuelve por la ruta y cada nodo libera su tramo. Si no aparece el preimage a tiempo, los contratos expiran y cada salto recupera su saldo.
Comisiones de routing
Cada nodo intermedio puede cobrar una comisión fija (base fee) y otra proporcional (fee rate en ppm). Para pagos cotidianos, el coste suele ser muy bajo. Para pagos grandes, la liquidez necesaria en cada salto y el coste acumulado pueden crecer de forma relevante.
Qué cambia con MPP, splicing y LSP
- MPP: divide un pago grande en varias rutas más pequeñas para elevar probabilidad de éxito.
- Splicing: ajusta fondos de canal sin cerrar y abrir de cero.
- LSP: abstrae la gestión de liquidez para usuarios no técnicos.