Descripción General
Un Contrato de Bloqueo por Hash y Tiempo (HTLC) es un pago condicional que combina dos primitivas poderosas: un bloqueo por hash (que requiere conocimiento de un secreto para reclamar fondos) y un bloqueo temporal (que permite al remitente recuperar fondos después de un plazo). Los HTLCs son el mecanismo crítico que permite los pagos multi-salto a través de la Red Lightning y los intercambios atómicos sin confianza entre cadenas, ya que garantizan que o todas las partes de una cadena de pagos reciben sus fondos o ninguna lo hace.
Cómo Funciona un HTLC
Alice quiere pagar a Carol a través de Bob (Alice → Bob → Carol)
Paso 1: Carol genera un secreto aleatorio R y envía hash(R) a Alice
Paso 2: Alice crea HTLC con Bob:
┌──────────────────────────────────────────────┐
│ HTLC: Alice → Bob │
│ │
│ SI Bob proporciona preimagen R donde │
│ hash(R) = H Y firma de Bob │
│ ENTONCES Bob puede reclamar los fondos │
│ │
│ SI expira el tiempo límite (ej., 48 horas) │
│ ENTONCES Alice puede recuperar los fondos │
└──────────────────────────────────────────────┘
Paso 3: Bob crea HTLC con Carol (mismo hash, tiempo límite más corto):
┌──────────────────────────────────────────────┐
│ HTLC: Bob → Carol │
│ │
│ SI Carol proporciona preimagen R donde │
│ hash(R) = H Y firma de Carol │
│ ENTONCES Carol puede reclamar los fondos │
│ │
│ SI expira el tiempo límite (ej., 24 horas) │
│ ENTONCES Bob puede recuperar los fondos │
└──────────────────────────────────────────────┘
Paso 4: Carol revela R para reclamar de Bob
Paso 5: Bob ahora conoce R, lo usa para reclamar de Alice
Las Dos Condiciones de Bloqueo
Bloqueo por Hash: El destinatario debe revelar una preimagen (valor secreto) cuyo hash coincida con un valor de hash predeterminado. Esto garantiza que el secreto se propague hacia atrás a través de la cadena de pagos a medida que cada salto reclama su pago.
Bloqueo Temporal: Si el pago no se reclama dentro de una ventana de tiempo especificada, el remitente puede recuperar los fondos. Los bloqueos temporales disminuyen en cada salto (ej., 48h, 24h, 12h) para garantizar que cada intermediario tenga tiempo de reclamar después de conocer el secreto.
Estructura de bloqueo temporal entre saltos:
Alice ──[48h]──► Bob ──[24h]──► Carol
Carol reclama primero (conoce el secreto)
Bob reclama segundo (aprendió el secreto de Carol)
El tiempo límite de Alice es el más largo (más tiempo para resolver)
Propiedades de Seguridad
- Atomicidad: O el pago completo se completa o ninguna parte lo hace. Carol no puede reclamar sin revelar R, y Bob no puede reclamar sin R.
- Sin confianza: Ningún intermediario puede robar fondos. Bob no puede reclamar de Alice sin primero pagar a Carol (porque necesita R).
- Sin riesgo de contraparte en el secreto: La función hash garantiza que la preimagen no pueda ser adivinada.
HTLCs en la Práctica
En la Red Lightning, los HTLCs generalmente se resuelven fuera de la cadena mediante el mecanismo normal de actualización del canal. El script HTLC en cadena solo se usa como respaldo si una parte no responde o intenta hacer trampa. Esto significa que, en la práctica, los pagos multi-salto de Lightning se completan en segundos sin tocar la blockchain.
Limitaciones
- Liquidez bloqueada: Los fondos en un HTLC están bloqueados hasta que el pago se completa o expira el tiempo límite, reduciendo temporalmente la capacidad del canal disponible
- Correlación de enrutamiento: Se usa el mismo hash en todos los saltos, lo que hace posible teóricamente que un nodo que controla múltiples saltos los correlacione (los PTLCs, que usan bloqueos de punto en lugar de bloqueos de hash, abordan esto)
- Riesgos de tiempo límite: Si un nodo se desconecta durante la ventana de tiempo límite, los fondos pueden quedar bloqueados hasta que expire el timelock
Conceptos Erróneos Comunes
- Los HTLCs no son exclusivos de la Red Lightning. Pueden usarse en cadena y son la base de los intercambios atómicos entre diferentes blockchains.
- El "hash" en HTLC se refiere al hash de la preimagen secreta, no al hashing de prueba de trabajo de Bitcoin.
- Los HTLCs no requieren confianza en ningún intermediario. La construcción criptográfica garantiza que los nodos de reenvío no puedan robar fondos.