HTLC

Los contratos de bloqueo temporal (timelock) con hash son lo que hace seguro el reenvío de un pago Lightning de varios saltos. Cada salto bloquea su dinero en el mismo hash SHA-256, y un canal puede llevar como máximo 483 de ellos en cada sentido a la vez. Para usted, esa es la razón por la que un pago Lightning o se liquida por completo o falla por completo, y nunca deja dinero atrapado a mitad de la ruta.

Cómo funciona

Dos condiciones protegen el dinero de un HTLC, y con el tiempo exactamente una de ellas se cumplirá.

El destinatario inventa un secreto aleatorio de 32 bytes, llamado preimagen, calcula su hash con SHA-256 y pone el resultado en la factura. Después, cada nodo de la ruta ofrece al siguiente una salida gastable de dos maneras: de inmediato, por cualquiera que pueda mostrar la preimagen, o, pasada una altura de bloque acordada, por el nodo que la ofreció. Como todos los saltos comparten un mismo hash, en el momento en que el destinatario reclama su dinero revelando la preimagen, cada salto anterior la conoce y reclama el suyo. Nadie se queda nunca habiendo pagado hacia delante sin que le paguen a su vez, que es la propiedad sobre la que se construye Lightning.

Las alturas de bloque descienden escalonadamente a lo largo de la ruta. Cada canal anuncia un valor cltv_expiry_delta, y el pagador acumula esas deltas para que el salto más cercano al destinatario expire primero y cada salto anterior tenga un margen de seguridad. BOLT 11 indica al pagador que reserve al menos 18 bloques para el último salto cuando la factura no diga otra cosa. Ese retraso acumulado es el costo real de un HTLC: si un pago se atasca, el dinero no se pierde, pero puede quedar congelado durante horas mientras se resuelven los timeouts (expiraciones de plazo).

On-chain, estos contratos se convierten en transacciones reales. En un canal ancla, una transacción HTLC-timeout pesa 666 unidades de peso y una transacción HTLC-success pesa 706, y un cierre forzado con varios pagos en tránsito implica difundir una de ellas por cada uno. Los montos demasiado pequeños para merecer una salida no reciben ninguna; en su lugar se suman a la comisión de minería, y por eso un pago diminuto puede desaparecer en comisiones si un canal se cierra en el momento equivocado.

Dónde aparece

Usted ve los HTLC en los segundos que pasan entre tocar el botón de pagar y que la factura se ponga en verde, y los vuelve a ver en el cálculo de comisiones de un swap on-chain.

Los servicios centrados en Lightning, como Strike, mueven el dinero así en cada pago, y los nodos de enrutamiento Lightning muestran el número de HTLC pendientes como métrica operativa, porque un canal lleno de contratos atascados no puede reenviar nada. La misma construcción funciona fuera de Lightning: un intercambio submarino cambia un HTLC on-chain por un pago Lightning bloqueado en el mismo hash, y un intercambio atómico entre cadenas hace lo mismo entre dos registros públicos. En cada caso, el hash es el árbitro compartido y el timeout es el reembolso.

El límite importa más de lo que parece. Una transacción de compromiso tiene que seguir siendo una transacción de bitcoin válida, así que BOLT 2 prohíbe más de 483 contratos aceptados por sentido, cifra que baja a 114 en el formato más nuevo de compromisos sin comisión. Los grandes canales de enrutamiento chocan con ese techo en los períodos de mucha actividad, y esa es una razón honesta por la que un pago a veces falla y sale bien treinta segundos después.

HTLC frente a PTLC

Un HTLC usa un solo hash para toda la ruta, mientras que un PTLC da a cada salto un bloqueo distinto derivado de un punto de la curva elíptica. Esa única diferencia es un agujero de privacidad: dos nodos de enrutamiento del mismo operador, situados en puntos distintos de su ruta, pueden ver el mismo hash dos veces y reconstruir su pago. La red funciona realmente con HTLC. Los PTLC son el reemplazo especificado y, hasta que se lancen, dé por hecho que cualquier gran operador de enrutamiento puede correlacionar los saltos que reenvía.