-
@ Bitcoin Txoko
2024-11-23 11:13:57
En los dos capítulos anteriores aprendimos cómo dos pares pueden enviar fondos entre sí en un canal actualizando el estado e invalidando estados antiguos. En este capítulo, daremos una visión general de cómo los HTLC permiten pagos de múltiples saltos. El próximo capítulo será una inmersión profunda en los HTLC.
¡Vamos a ello con un ejemplo simple!
### Red simple de 3 nodos y 2 saltos
En esta red simple, tenemos tres nodos: Alice, Bob y Charlie. Hay dos canales entre ellos: uno entre Alice y Bob y otro entre Bob y Charlie. Cada canal tiene una capacidad de 10 BTC distribuida equitativamente entre los participantes.
Para simplificar, solo mostramos una transacción de compromiso que gasta de la transacción de financiación, determinando así el estado del canal. Esto no es exactamente preciso, ya que aprendimos sobre compromisos asimétricos en el último capítulo, pero para los propósitos de entender los HTLC, esta simplificación será más fácil. Una descripción más precisa se dará en un capítulo posterior.
Ahora, supongamos que Alice quiere pagar a Charlie. No puede pagarle directamente ya que no tienen un canal entre ellos y es costoso (en términos de tiempo y dinero) abrir un canal solo para una transacción rápida. En su lugar, Alice puede usar su canal con Bob para enrutar un pago a Charlie, ya que Bob y Charlie comparten un canal.
### Paso 1: Generar y compartir un hash de pre-imagen
Alice primero necesita decirle a Charlie que quiere pagarle. Charlie generará un secreto aleatorio (la **pre-imagen**) `S` y obtendrá el **hash** de `S`, que llamaremos `H`. Charlie envía `H` a Alice.
### Paso 2: Configurar la cadena de HTLC
Supongamos que Alice quiere pagar a Charlie 1 BTC. Primero necesita encontrar una ruta hacia Charlie. En este caso es A-B-C. También ve que para usar esta ruta, necesita incentivar a Bob para que la ayude dándole una tarifa de enrutamiento. Supongamos que Bob cobra una tarifa fija de 1 BTC por enrutar pagos, por lo que Alice pagará un total de 2 BTC: 1 BTC por el enrutamiento y 1 BTC por Charlie. Alice luego le indica a Bob que le gustaría enrutar un pago sugiriendo que actualicen su estado de canal. En este ejemplo simplificado, la transacción de compromiso del canal tendrá las siguientes salidas (recuerda que en realidad Alice y Bob tendrán sus propias transacciones de compromiso):
- Una salida de 3 BTC de vuelta a Alice.
- Una salida de 5 BTC a Bob.
- Una salida de 2 BTC a un script especial que tiene 2 posibles caminos de gasto:
1. El primer camino puede ser gastado por Bob si tiene la pre-imagen de `H`
2. El segundo camino puede ser gastado por Alice después de un tiempo absoluto `cltv_expiry_AB`
Esta última salida con un script especial que bloquea los 2 BTC se llama un **Contrato de Bloqueo de Hash y de Tiempo** (Hash Time Locked Contract; HTLC) porque tiene un camino bloqueado por hash y un camino bloqueado por tiempo.
Bob actualizará felizmente a este nuevo estado de canal porque puede ver que no está perdiendo dinero: si la transacción se lleva a cabo en la cadena y aún no tiene la pre-imagen, entonces aún recupera sus fondos originales. También puede ver que si coopera y reenvía el pago, será recompensado con una tarifa de enrutamiento si el pago tiene éxito porque podrá reclamar la salida bloqueada por hash en la transacción.
Bob ahora bloquea algunos fondos de manera similar en su canal con Charlie. Actualiza la transacción de compromiso del canal para incluir las siguientes salidas:
- Una salida de 4 BTC a Bob
- Una salida de 5 BTC a Charlie
- Una salida de 1 BTC a un script HTLC que nuevamente tiene dos caminos de gasto:
1. El primer camino es gastable por Charlie si puede revelar la pre-imagen de `H`
2. El segundo camino es gastable por Bob después de un `cltv_expiry_BC`
Bob puede bloquear sus fondos de esta manera con confianza porque sabe que si el pago falla, podrá reclamar sus fondos a través del camino bloqueado por tiempo y si el pago tiene éxito y Charlie revela la pre-imagen cuando gasta a través del camino bloqueado por hash, entonces Bob verá esta pre-imagen y podrá reclamar la salida bloqueada por hash en el HTLC de la transacción de compromiso que tiene con Alice.
Cuando Charlie recibe esta oferta de HTLC de Bob, puede ver que de hecho conoce la pre-imagen `S` que se hash a `H`, por lo que sabe que puede reclamar el camino bloqueado por hash de la salida HTLC de la transacción de compromiso si se lleva a cabo en la cadena. Sin embargo, idealmente, las cosas no tienen que resolverse en la cadena. En su lugar, Charlie simplemente envía la pre-imagen `S` a Bob. Esto le prueba a Bob que Charlie reclamaría la salida HTLC si se llevara a cabo en la cadena y así ahora Bob y Charlie pueden acordar simplemente actualizar su transacción de compromiso para reflejar que Charlie ahora tiene 1 BTC más:
Ahora que Bob tiene la pre-imagen `S`, puede dar la vuelta y revelar `S` a Alice, probando que si su transacción de compromiso se lleva a cabo en la cadena, Bob reclamaría la salida bloqueada por hash. Así como Bob y Charlie hicieron en su canal, Alice y Bob actualizan su transacción de compromiso eliminando la salida HTLC para reflejar el nuevo saldo de fondos:
Alice envió a Charlie 1 BTC y Bob ganó 1 BTC en tarifas de enrutamiento.
### cltv_expiry
¿Qué pasa si las cosas salen mal? Por ejemplo, Charlie se desconecta y no responde a Bob con una pre-imagen. Si esto sucede, Bob necesitará transmitir la transacción de compromiso para que pueda reclamar sus fondos a través del camino bloqueado por tiempo del HTLC. Si transmite la transacción pero luego Charlie vuelve a estar en línea antes del `cltv_expiry_BC` y gasta a través del camino bloqueado por hash del HTLC, entonces Bob verá la pre-imagen en la cadena y podrá dar la vuelta a Alice y revelarle la pre-imagen como de costumbre.
A partir de este ejemplo, puedes ver que es importante que los valores de `cltv_expiry` disminuyan a lo largo del camino del remitente al receptor. Esto se debe a que en el peor de los casos, Charlie solo revela `S` a Bob justo antes de `cltv_expiry_BC` y luego Bob aún necesita tiempo para ir a Alice y revelar `S` antes de que ella pueda gastar a lo largo del camino `cltv_expiry_AB`. En otras palabras, `cltv_expiry_BC` debe ser antes de `cltv_expiry_AB`.
### Revisión
- **Contrato de Bloqueo de Hash y de Tiempo** (Hash Time Locked Contract; HTLC): Un script de salida especial en la transacción de compromiso que tiene un camino bloqueado por hash y un camino bloqueado por tiempo
- **Pre-imagen**: un secreto aleatorio utilizado para reclamar pagos
- **Hash** (de la pre-imagen): el hash de la preimagen utilizada para bloquear fondos a lo largo de una ruta de pago
- **Verificación de tiempo de bloqueo** (Check Locktime Verify; CLTV): El bloqueo de tiempo absoluto utilizado en los HTLC que debe disminuir a lo largo de la ruta de pago del remitente al receptor
### Referencias
- [BOLT2: Peer Protocol](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#normal-operation)
- [BOLT3: Transactions](https://github.com/lightning/bolts/blob/master/03-transactions.md)
- [LN Things Part 4: HTLC Overview](https://ellemouton.com/posts/htlc/) por nostr:nprofile1qqswrt9pnxatlplu49h6meld8svmwqt87wwvk256rqk07n6eu4qeh5gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dszpfjtz
- [Time locks](https://docs.lightning.engineering/the-lightning-network/multihop-payments/timelocks)