HTLC o Hash Time Locked Contract son un tipo de smart contracts o contrato inteligente que sirven para crear payments channels.
Una de las tecnologías más potentes dentro de lenguaje de programación de Bitcoin Script son los conocidos HTLC o Hash Time Locked Contract. Estos son un tipo de smart contracts o contrato inteligente que tiene como principal capacidad crear canales de pagos o payments channels. De esta manera, los HTLC permiten la construcción de tecnología como Lightning Network (LN) tanto en Bitcoin como en otras criptomonedas compatibles con esta capacidad. Esto quiere decir que los HTLC permiten crear protocolos de segunda capa capaces de acelerar en gran medida la escalabilidad de Bitcoin. Todo ello sin renunciar a la seguridad de esta blockchain.
Sin embargo, los HTLC son mucho más que un simple contrato inteligente. Son la unión de varias otras tecnologías que al final permiten una funcionalidad mucho más compleja y acorde a las necesidades de crecimiento de Bitcoin.
En este artículo de Bit2Me Academy conocerás más a fondo los entresijos y el potencial de este algoritmo blockchain.
Origen de los HTLC
El origen de los HTLC se remonta a la necesidad de crear mecanismos que permitan una mayor escalabilidad en Bitcoin. Curiosamente, las primeras ideas que llevaron a los HTLC son bastante originales, curiosas y hasta problemáticas en algunos casos como podrás ver a continuación:
Los nSequence Channel de Satoshi Nakamoto
La primera idea que llevó a los HTLC vino del mismísimo Satoshi Nakamoto, con los llamados nSequence Channels. Este tipo de canales de pagos son creados usando los OP_CODE nSequence y nLockTime. De esta forma, se podía crear un sistema en el que el usuario podía enviar una transacción con un valor nLockTime (un bloqueo de tiempo) y un nSequence (un valor que permitía el reemplazo de la transacción por otra). De esta forma, el usuario puede realizar una determinada cantidad de compras y pagos “instantáneos”.
Luego serían sumados a una transacción final que reemplazaría a la transacción inicial antes de que el nLockTime y nSequence inicial quedaran finalmente cerrados. De esta manera, la nueva transacción pagaría todos los gastos de las compras realizadas en una misma operación.
Esto es posible porque:
- Los nSequence fueron diseñados para permitir reemplazar transacciones en la mempool, si este valor no estaba marcado con el valor hexadecimal 0xFFFFFFFF, ya que si estaba marcada con ese valor la TX no se podía reemplazar. De hecho, este pequeño diseño fue lo que llevó a la creación del Replace by Fee o RBF. La idea tras su uso en los nSequence Channels era sumar operaciones de pago en una TX y reemplazar la misma en la mempool, hasta que finalmente se considerara dicha TX como una transacción final (marcándola con 0xFFFFFFFF en su nSequence).
- Con nLockTime se pondría un tiempo límite para que los mineros pudieran finalmente tomar la TX y confirmarla. Como dato curioso, nLockTime solo funciona si nSequence es diferente de 0xFFFFFFFF, así que efectivamente este valor sirve para garantizar que se haga trampa en los nSequence Channels asegurando el pago al vendedor pasado un tiempo, incluso si el canal no se ha cerrado por nSequence.
Ciertamente esta es una solución muy básica, unidireccional (solo el creador de la TX podía manejarla), con un limitado tiempo de vida (el uso de nLockTime y nSequence no permite funcionamiento infinito) y sin reglas de consenso seguras (todo pasa en la mempool donde nada está confirmado). Pero aún así, no dejaba de ser una idea reveladora.
Y es que, ver a Bitcoin como un medio para crear canales de pagos y construir sistemas impulsados por su OP_CODE abría muchas posibilidades, algo que Nakamoto mostró con gracia con esta idea. ¿Lo mejor? Esta idea era aplicable desde la versión 0.1.0 de Bitcoin, así que es parte del protocolo desde sus inicios.
Spilman y CLTV channels
Otras dos formas de canales de pagos bien conocidos son los Spilman Channels y los CLTV Channels. El primero de ellos fue propuesto por Jeremy Spilman, en la que se unen transacciones multifirmas con el uso de nLockTime para evitar trampas que permitan el robo de fondos. Básicamente, un Spilman Channel consta de:
- Crear una transacción multifirma 2-de-2 donde el comprador y vendedor crean el canal de pago. La transacción solo se crea, pero no se transmite a la red hasta que toda la operación no esté realizada. Esta primera transacción es conocida como transacción de financiación.
- Seguidamente se crea una transacción que gasta la anterior usando nLockTime que garantiza el pago de la TX multifirma. Esta transacción se le entrega al vendedor, quien la firma y la devuelve al comprador.
- La primera TX se envía a la red para su confirmación, y una vez confirmada puede comenzar a pedir lo que desee, ya que el canal de pago se ha abierto.
- Ahora con cada nueva transacción de pago, se crea una TX que gasta la transacción de financiación (la primera transacción creada). Dicha operación envía el pago de lo que pida al vendedor y devuelve al comprador el cambio. El comprador podrá gastar cuanto desee siempre y cuando su transacción de financiación lo permite, si rebasa el límite no podrá seguir gastando. Si ha terminado de gastar, cerrándose el canal con un cambio, este irá a manos del comprador de forma automática.
Este sistema también puede crearse usando el OP_CODE, OP_CHECKLOCKTIMEVERIFY (CLTV). En este caso, el CLTV solo permite incluir nuevas condiciones para el cierre del canal de pagos que evitan ciertas trampas (como que el vendedor no quiera cerrar el canal de pago cuando usted desee no seguir consumiendo). Además el uso de CLTV minimiza los pasos al no necesitar crearse la segunda transacción del canal Spilman.
Estas dos experiencias iniciales fueron las que llevaron a la creación de los HTLC, que llevaron luego a la creación de Lightning Network. Esto con el fin de implementar una segunda capa en la red blockchain de Bitcoin para gestionar transacciones fuera de la misma a través de canales de pago. Esto fue posible gracias al trabajo de Joseph Poon y Tadge Dryja, quienes idearon este sistema en 2016.
¿Cómo funcionan los HTLC?
El funcionamiento de los HTLC recae en dos parte bien importantes. La primera es su capacidad de realizar hashlock, o bloqueos por hash de las transacciones que se realizan. Y la segunda, es la capacidad de realizar timelock, o bloqueos de tiempo de esas mismas transacciones. Estas dos funciones juntas son las que permiten a los HTLC, ejecutar transacciones bajo ciertas condiciones acordadas en la realización del contrato. Lo mejor de todo es que estas transacciones están protegidas a nivel de hash y tiempo. Esto las hace muy seguras en comparación con los modelos iniciales de canales de pagos, como por ejemplo el nSequence Channel.
La idea detrás es que cuando un participante esté interesado en realizar una transacción, este pueda contactar con otra persona y alcanzar un acuerdo. Este acuerdo permite que ambos puedan realizar transacciones bajo condiciones que ambos acepten. Así, ambas partes pueden estar seguras de que no habrá trampas en sus operaciones. Esto brinda la seguridad de que no se podrá acceder de forma maliciosa a los fondos antes de tiempo. Y, al mismo tiempo, que las transacciones realizadas sean completadas de forma correcta.
Para ello, el HTLC crea un hash único de la clave privada de la transacción que es entregado a cada una de las partes (lo que posible por el hashlock). De esta manera, cada parte debe participar en la transacción tanto para abrir como para cerrar el canal de pago. Sin ambos hash, la transacción (una vez abierta) no puede cerrarse para reclamar el pago. Esto fuerza la comunicación entre las partes para que se firme el fin de la transacción de forma conjunta.
Una segunda protección adicional, es dada por el timelock, con el que se especifica un tiempo prudencial para que quienes participan en la transacción puedan realizar las acciones necesarias para que la transacción se realice sin inconvenientes. Si dicho tiempo transcurre y la transacción no se cierra, se ejecutan las condiciones secundarias de dicha transacción, las cuales permiten recuperar los fondos a sus propietarios originales. Por supuesto, las condiciones pueden ser otras, pero el fin del timelock, es dar tiempo necesario para que las partes cierren el canal de buena manera, sin recurrir a instrucciones secundarias.
El modelo de contrato de los HTLC fue diseñado teniendo en mente la puesta en marcha de Lightning Network de Bitcoin, una red de pagos instantáneos off-chain (fuera de la cadena) que se beneficia de los mismos para ofrecer seguridad a sus usuarios.
Principales usos de los HTLC
El principal uso de los HTLC está en la creación de canales de pago, tal como lo describen Poon y Dryja en su trabajo sobre Lightning Network. De hecho, gracias a los HTLC, este tipo de sistemas son seguros y permiten la comunicación bidireccional, tanto entre los participantes y creadores del canal, como de la sidechain y la mainchain de la criptomonedas donde se ejecute dicho HTLC. En tal sentido, los HTLC son un método confiable para construir este tipo de funciones avanzadas de pagos, tal como lo ha demostrado LN hasta el momento.
Otro uso importante de los HTLC está en los intercambios atómicos o atomic swaps. Gracias a su capacidad off-chain, los HTLC pueden intercomunicar dos cadenas de bloques distintas y permitir que sus usuarios realicen intercambios atómicos instantáneos que luego pueden pasar a mainchain sin problemas.
Pros y contras de los HTLC
Una de las mayores ventajas de los HTLC es facilitar la realización de transacciones en canales de pago P2P. De esta forma, resulta sencillo crear una red de nodos que manejen off-chain todos estos canales, y enrutar dichos pagos para que las partes reciban los pagos de forma segura. De esta manera, sin necesidad de confiar en los nodos intermedios, es posible crear una red de pagos gigantesca, casi instantánea, segura y de muy bajo costo.
Otro punto a favor de los HTLC, es que las operaciones de pago pueden ser protegidas con condiciones bien especificadas. Así se puede evitar el robo de fondos o la actuación maliciosa de las partes dentro del sistema.
Adicionalmente, los HTLC aportan a la red Bitcoin una gran mejora en su escalabilidad y capacidad para realizar micropagos. Esto a la vez que se reducen los cuellos de botella on-chain, se reducen las comisiones y la red escala para atender a más y más personas.
Sin embargo, no todo es positivo. Muchos expertos del mundo de la criptografía, han encontrado algunos problemas en los HTLC. En primer lugar está el punto de la trazabilidad de las operaciones, lo que significa que los pagos realizados con HTLC no son anónimos. Otro punto en contra es que los HTLC pueden resultar en sistemas más complejos y por tanto en software con problemas de seguridad no detectados.
Otras alternativas a los HTLC
A pesar de las ventajas que ofrece la implementación de los HTLCs, algunos desarrolladores tienen su interés enfocado hacia el desarrollo de nuevas alternativas a estos contratos inteligentes. Desarrolladores del ecosistema de Lightning Network, están sumando esfuerzos para realizar cambios profundos en esta red. Esto con miras a utilizar PTLC en la ejecución de transacciones con un nivel mucho mayor de privacidad que las que ofrece actualmente HTLC.
Otros contratos inteligentes que se perfilan en la ejecución de transacciones multifirmas como Taproot. Todo persigue alcanzar una nueva era de contratos inteligentes en la red Bitcoin que le den mayor privacidad, versatilidad y seguridad a las transacciones.
