Glosario / Lightning y capa 2
Delta de expiración CLTV
- ¿Qué es una delta de expiración CLTV?
- Una delta de expiración CLTV es el número de bloques, anunciado en el gossip por cada sentido del canal, que un nodo Lightning resta del bloqueo temporal (timelock) de un pago entrante antes de reenviarlo.
Cada nodo que reenvía en una ruta Lightning cobra dos precios, una comisión en milisatoshis y un retraso en bloques, y la delta de expiración CLTV es el retraso. BOLT 7 la transporta como un campo de 16 bits en el mensaje channel_update, junto al campo fee_base_msat, y cada lado de un canal publica su propio valor de forma independiente. Si un pago se atasca, esa suma de bloques es el tiempo que su dinero permanece congelado.
Cómo funciona
La delta de expiración CLTV la elige el nodo que hará el reenvío, y solo rige el sentido saliente de ese nodo.
La redacción de la especificación es precisa: un nodo debe asignar al campo el número de bloques que restará del campo cltv_expiry de un HTLC entrante. Así que la delta no es un plazo, es una diferencia. El nodo acepta un pago bloqueado hasta cierta altura de bloque absoluta, se queda con la delta y ofrece al siguiente salto un pago bloqueado hasta esa altura menos la delta. Esa diferencia es el margen de seguridad del nodo: si el salto de aguas abajo liquida en el último momento posible, al nodo le quedan otros tantos bloques para reclamar el pago aguas arriba.
Cada canal público lleva dos de estas cifras, una por sentido, cada una firmada por el nodo que la estableció. Viajan en channel_update, el mensaje de tipo 258, junto al campo htlc_minimum_msat y los dos campos de comisión. Solo importan las actualizaciones que anuncian los nodos que van a reenviar: en una ruta que va de A a B, luego a C y luego a D, el pagador usa la actualización de B para el tramo de B a C y la de C para el tramo de C a D, y ninguna de las suyas.
Por eso las rutas se construyen hacia atrás. El pagador empieza en el destino con la expiración final mínima que pide la factura, retrocede sumando la delta anunciada de cada salto, y el total acumulado se convierte en el bloqueo temporal del HTLC que entrega a su primer par. Cuando un nodo revisa sus precios, BOLT 7 le pide que siga aceptando los parámetros anteriores durante 10 minutos, porque el gossip no llega a todos los pagadores a la vez.
Dónde aparece
Las deltas de expiración CLTV deciden cuánto tiempo inmoviliza su saldo un pago Lightning atascado, y el propio ejemplo de enrutamiento de BOLT 7 pone cifras a dos rutas por lo demás idénticas.
Cuatro nodos forman un rombo: A, B, C y D, que anuncian 10, 20, 30 y 40 bloques, y C pide una delta de expiración final de 18, que la especificación llama el valor predeterminado. A envía 4.999.999 milisatoshis a C. Si se enruta a través de B, A entrega a su par 5.010.198 milisatoshis, 10.199 de ellos como comisión de B, y el primer HTLC expira en la altura de bloque actual más 80: 20 bloques para el salto de B, 18 para C y 42 más de relleno. Si se enruta a través de D, el mismo pago cuesta 5.020.398 milisatoshis y expira en la altura actual más 100. Mismo remitente, mismo destinatario, mismo monto, y 20 bloques más de exposición.
Ese 42 no es un añadido arbitrario. BOLT 7 advierte de que una ruta construida sumando fielmente las deltas permite a un nodo intermedio averiguar su propia posición y, a partir de ahí, adivinar a quién se paga, por lo que se aconseja al pagador añadir un desplazamiento aleatorio, que se obtiene recorriendo el grafo hacia fuera desde el destinatario y sumando las deltas que encuentra. La especificación llama al resultado shadow route extension (extensión de ruta sombra).
Nada de esto lo decide usted, salvo que opere el nodo que reenvía. Phoenix, que nuestra reseña llama un verdadero nodo Lightning autónomo en el teléfono, publica su precio de envío como 0,4 % más 4 sat, y esa tabla pone precio al dinero, no a los bloques.
Delta de expiración CLTV frente a OP_CHECKLOCKTIMEVERIFY
Una delta de expiración CLTV es una cifra de política de enrutamiento publicada en el gossip, mientras que OP_CHECKLOCKTIMEVERIFY es el opcode (código de operación) de Script de Bitcoin que hace cumplir un plazo absoluto on-chain.
Comparten tres letras y poco más. Una delta es relativa y vive por completo off-chain: no aparece en ningún script, ningún nodo completo la valida, y el nodo que la estableció la revisa con un nuevo channel_update. OP_CHECKLOCKTIMEVERIFY está escrito en la moneda, lo comprueba cada nodo completo y no puede editarse una vez que la moneda existe.