Lightning Routing consiste en encontrar y utilizar un camino para pagar a través de la red Lightning. Ese camino está formado por canales de pago: sus participantes bloquean fondos conjuntamente en Bitcoin y van actualizando cuánto corresponde a cada uno. Los canales los gestionan programas llamados nodos. El remitente suele planificar la ruta con información pública, datos del receptor y resultados de intentos anteriores. Sin embargo, no conoce todos los saldos actuales, por lo que debe estimar si la ruta funcionará y, a veces, probar otra.
Anna quiere pagar un café, pero no tiene un canal con la cafetería. Tiene uno con Pavel, que a su vez tiene otro con el establecimiento. El pago puede pasar por él: en el primer canal, parte del saldo pasa de Anna a Pavel; en el segundo, de Pavel a la cafetería. No se traslada la misma moneda de un canal a otro, sino que cambian sus saldos mediante pasos vinculados. Por eso Pavel necesita fondos propios utilizables en el lado desde el que paga a la cafetería. La cartera o el nodo del remitente elige una ruta al receptor y prepara instrucciones para cada paso. El receptor proporciona los datos necesarios y las funciones compatibles, quizá también información sobre un tramo final privado. Los nodos intermedios reenvían el pago según esas instrucciones. No buscan cada uno por su cuenta toda la ruta al destino. [1] [4]
Gossip es el mecanismo para compartir información entre nodos. BOLT #7 describe anuncios de canales y actualizaciones por dirección: comisión base y proporcional, diferencia de vencimientos CLTV, importes mínimo y máximo y un indicador de disponibilidad. Las condiciones anunciadas no prueban que el nodo vecino esté conectado ni tenga fondos suficientes. Aquí, CLTV se refiere a un plazo expresado como altura de bloque de Bitcoin, es decir, su posición en la cadena, no como una hora exacta del reloj. La diferencia entre plazos deja al intermediario tiempo para reaccionar si el reenvío se atasca. [2]
La capacidad total del canal no revela cuánto puede enviar cada lado en ese momento. El remitente conoce sus canales; para los demás usa estimaciones e historial de éxitos y fallos. El programa valora tanto las comisiones como la probabilidad de éxito. Mientras tanto, otro pago puede cambiar la liquidez: los fondos que pueden enviarse en el sentido necesario. [4] [5]
Los pasos se vinculan mediante HTLC, pagos condicionales que requieren revelar el secreto correspondiente para completarse. Si no se completan, permiten recuperar los fondos una vez vencido el plazo. El cálculo comienza por el importe que recibirá el receptor y retrocede. Cada intermediario necesita el importe para el siguiente nodo más su comisión. Su HTLC entrante debe vencer suficientemente después del saliente, según la diferencia CLTV requerida. Una ruta más larga puede aumentar los costes y el tiempo durante el que quedan fondos comprometidos si surge un problema. [1] [2]
Onion routing en BOLT #4 utiliza la construcción Sphinx: cada paso recibe instrucciones cifradas por separado. El intermediario conoce al nodo anterior, al siguiente y sus propias instrucciones. El paquete por sí solo no revela la ruta completa, su longitud ni la posición exacta del intermediario. El análisis del tráfico o la cooperación entre nodos pueden reducir la privacidad. [1]
Un canal puede fallar temporalmente, la comisión ser demasiado baja, el CLTV incorrecto o el siguiente nodo estar inaccesible o ser desconocido. El remitente recibe información limitada del error. Su programa puede bajar la valoración de una ruta, recalcularla y reintentar. No es una multa pagada al nodo, ni un solo resultado una valoración permanente de fiabilidad. [1] [4]
No basta con encontrar conexiones: cada paso debe aceptar el HTLC y disponer de fondos utilizables suficientes en el sentido necesario. Parte del saldo puede mantenerse como reserva o estar comprometida en pagos sin terminar. Además, los campos técnicos htlc_minimum_msat y htlc_maximum_msat fijan los límites inferior y superior del importe de un solo HTLC en esa dirección. La unidad msat es una milésima de satoshi; el satoshi es la unidad de valor más pequeña en la cadena de Bitcoin. Ni siquiera un límite anunciado alto demuestra que la liquidez necesaria esté disponible ahora. Por ello, un solo canal inadecuado puede impedir que funcione toda la ruta. [2]
Si el receptor admite basic MPP, es decir, un pago dividido en varias partes, el remitente puede repartir el importe total, identificado en el protocolo como total_msat, entre varias rutas. El receptor espera las partes necesarias y las liquida juntas. Así se aprovecha liquidez dispersa entre canales, pero MPP no crea liquidez nueva. Añade HTLC, intentos y posiblemente comisiones. [1]
Los route hints de BOLT #11 pueden proporcionar detalles de los últimos pasos no anunciados. Route blinding, utilizado en BOLT #12, ofrece en cambio un tramo final cifrado a través de un nodo de entrada, el introduction point. El remitente aún debe encontrar una ruta utilizable hasta él y cumplir las condiciones agregadas de comisiones y CLTV. Más privacidad no garantiza la entrega. [3] [6] [1]
En los pagos cotidianos, la cartera se encarga de encontrar la ruta. Los siguientes detalles resultan especialmente útiles para operadores de nodos y para investigar problemas recurrentes. Registre el programa y la versión, el importe, la comisión máxima y el límite CLTV, el número de intentos, las rutas usadas, el tiempo hasta completar el pago y el motivo exacto del fallo. Compare la misma pareja de nodos en momentos próximos. El éxito describe un pago concreto en un estado concreto de la red, no una puntuación global permanente. [4] [5]
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.