HTLC ou Hash Time Locked Contract são um tipo de contrato inteligente ou contrato inteligente usado para criar canais de pagamentos.
UUma das tecnologias mais poderosas dentro da linguagem de programação de Bitcoin Script são os conhecidos Contrato HTLC ou Hash Time Locked. Estes são um tipo de contratos inteligentes ou contrato inteligente cuja principal capacidade é criar canais de pagamento ou canais de pagamentos. Desta forma, os HTLCs permitem a construção de tecnologias como Rede de relâmpagos (LN) tanto em Bitcoin quanto em outras criptomoedas compatíveis com esta capacidade. Isso significa que os HTLCs permitem a criação de protocolos de segunda camada capazes de acelerar bastante a escalabilidade do Bitcoin. Tudo isso sem abrir mão da segurança desse blockchain.
No entanto, os HTLCs são muito mais do que apenas um contrato inteligente. São a união de várias outras tecnologias que no final permitem uma funcionalidade muito mais complexa e de acordo com as necessidades de crescimento do Bitcoin.
Neste artigo da Bit2Me Academy, você aprenderá mais sobre os prós e contras e o potencial desse algoritmo de blockchain.
Origem do HTLC
A origem dos HTLCs remonta à necessidade de criar mecanismos que permitam maior escalabilidade no Bitcoin. Curiosamente, as primeiras ideias que levaram ao HTLC são bastante originais, curiosas e até problemáticas em alguns casos como você pode ver abaixo:
Canal de sequência de Satoshi Nakamoto
A primeira ideia que levou ao HTLC veio desde o Satoshi Nakamoto, com o chamado Canais de sequência n. Esses tipos de canais de pagamento são criados usando o OP_CODE nSequence e nLockTime. Desta forma, poderia ser criado um sistema em que o usuário pudesse enviar uma transação com um valor de nLockTime (um bloqueio de tempo) e um nSequence (um valor que permite a substituição da transação por outra). Desta forma, o usuário pode fazer uma certa quantidade de compras e pagamentos "instantâneos".
Eles seriam então adicionados a uma transação final que substituiria a transação inicial antes que o nLockTime e o nSequence iniciais fossem finalmente fechados. Dessa forma, a nova transação arcaria com todas as despesas das compras realizadas na mesma operação.
Isso é possível porque:
- As nSequences foram projetadas para permitir a substituição de transações no mempool, se este valor não foi marcado com o valor hexadecimal 0xFFFFFFFF, pois se foi marcado com aquele valor o TX não pode ser substituído. Na verdade, este pequeno design foi o que levou à criação do Substitua por Taxa ou RBF. A ideia de seu uso nos Canais nSequence era adicionar operações de pagamento em um TX e substituí-lo no mempool, até que finalmente o referido TX fosse considerado como uma transação final (marcando-o com 0xFFFFFFFF em seu nSequence).
- Com nLockTime, um limite de tempo seria definido para que os mineiros pudessem finalmente pegar o TX e confirmá-lo. Curiosamente, nLockTime só funciona se nSequence for diferente de 0xFFFFFFFF, então efetivamente este valor serve para garantir que os Canais nSequence sejam enganados, garantindo o pagamento ao vendedor após um certo tempo, mesmo que o canal não tenha sido fechado por nSequence.
Certamente esta é uma solução muito básica, unilateral (apenas o criador do TX poderia lidar com isso), com um tempo de vida limitado (o uso de nLockTime e nSequence não permite operação infinita) e sem regras consensuais seguras (tudo acontece no mempool onde nada é confirmado). Mesmo assim, ainda era uma ideia reveladora.
E, ver o Bitcoin como um meio de criar canais de pagamento e construir sistemas movidos por seu OP_CODE abriu muitas possibilidades, algo que Nakamoto mostrou graciosamente com essa ideia. O melhor? Essa ideia era aplicável desde a versão 0.1.0 do Bitcoin, por isso faz parte do protocolo desde o seu início.
Canais Spilman e CLTV
Duas outras formas conhecidas de canais de pagamento são Canais Spilman e os canais CLTV. O primeiro deles foi proposto por Jeremy Spilman, em que as transações de múltiplas assinaturas são combinadas com o uso do nLockTime para evitar armadilhas que permitem o roubo de fundos. Basicamente, um canal Spilman consiste em:
- Crie uma transação com várias assinaturas 2 de 2 em que o comprador e o vendedor criam o canal de pagamento. A transação é apenas criada, mas não transmitida à rede até que toda a operação seja concluída. Essa primeira transação é conhecida como transação de financiamento.
- Em seguida, é criada uma transação que gasta a anterior usando nLockTime que garante o pagamento do TX multi-assinatura. Esta transação é entregue ao vendedor, que a assina e a devolve ao comprador.
- O primeiro TX é enviado para a rede para confirmação, e uma vez confirmado você pode começar a pedir o que quiser, desde que o canal de pagamento tenha sido aberto.
- Agora, a cada nova transação de pagamento, é criado um TX que gasta a transação de financiamento (a primeira transação criada). Esta operação envia o pagamento do que você pediu ao vendedor e devolve o troco ao comprador. O comprador poderá gastar o quanto quiser enquanto sua operação de financiamento permitir, se ultrapassar o limite não poderá continuar gastando. Se você acabou de gastar, fechando o canal com uma mudança, esta irá para o comprador automaticamente.
Este sistema também pode ser criado usando o OP_CODE, OP_CHECKLOCKTIMEVERIFY(CLTV). Nesse caso, a CLTV só permite a inclusão de novas condições de fechamento do canal de pagamento que evitem certas armadilhas (como o vendedor não querer fechar o canal de pagamento quando quiser parar de consumir). Além disso, o uso do CLTV minimiza as etapas por não precisar criar a segunda transação do canal Spilman.
Essas duas experiências iniciais foram o que levou à criação dos HTLCs, que mais tarde levou à criação da Rede Lightning. Isso para implementar uma segunda camada na rede de blockchain Bitcoin para gerenciar transações fora dela por meio de canais de pagamento. Isso foi possível graças ao trabalho de Joseph Poon e Tadge Dryja, que criaram este sistema em 2016.
Como funcionam os HTLCs?
A operação do HTLC recai em duas partes muito importantes. A primeira é sua capacidade de hashlock ou bloqueio por hash das transações que são realizadas. E a segunda é a capacidade de realizar timelock, ou bloqueios de tempo dessas mesmas transações. Juntas, essas duas funções permitem que os HTLCs executem transações sob certas condições acordadas na execução do contrato. O melhor de tudo é que essas transações são protegidas no nível de hash e de tempo. Isso os torna muito seguros em comparação com os modelos de canais de pagamento iniciais, como o Canal nSequence.
A ideia é que, quando um participante está interessado em fazer uma transação, ele pode entrar em contato com outra pessoa e chegar a um acordo. Este acordo permite que ambos realizem transações sob condições com as quais ambos concordem. Assim, ambas as partes podem ter certeza de que não haverá trapaça em suas operações. Isso fornece a garantia de que os fundos não podem ser acessados de forma mal-intencionada com antecedência. E, ao mesmo tempo, que as transações realizadas sejam concluídas corretamente.
Para fazer isso, o HTLC cria um hash exclusivo da chave privada da transação que é entregue a cada uma das partes (o que é possível pelo hashlock). Dessa forma, cada parte deve participar da transação tanto para abrir quanto para fechar o canal de pagamento. Sem os dois hashes, a transação (uma vez aberta) não pode ser fechada para reclamar o pagamento. Isso força a comunicação entre as partes para que o final da transação seja assinado em conjunto.
Uma segunda proteção adicional é dada pelo timelock, com o qual é especificado um tempo razoável para que os participantes da transação possam realizar as ações necessárias para que a transação seja realizada sem inconvenientes. Decorrido este tempo e a transação não é concretizada, são executadas as condições secundárias da referida transação, que permitem a recuperação dos fundos aos seus proprietários originais. É claro que as condições podem ser diferentes, mas o objetivo do timelock é dar tempo para que as partes fechem o canal da maneira correta, sem recorrer a instruções secundárias.
O modelo de contrato HTLC foi projetado com o lançamento da Bitcoin's Lightning Network em mente, uma rede de pagamentos instantâneos fora da cadeia que se beneficia deles para oferecer segurança aos seus usuários.
Principais usos do HTLC
O principal uso dos HTLCs é na criação de canais de pagamento, conforme descrito por Poon e Dryja em seu trabalho na Lightning Network. De facto, graças aos HTLCs, este tipo de sistema é seguro e permite uma comunicação bidireccional, tanto entre os participantes e criadores do canal, como também a rede. cadeia lateral e a cadeia principal da criptomoeda onde o HTLC é executado. Nesse sentido, os HTLCs são um método confiável para construir esses tipos de funções de pagamento avançadas, como o LN mostrou até agora.
Outro uso importante de HTLCs é em trocas atômicas ou trocas atômicas. Graças à sua capacidade fora da cadeia, os HTLCs podem intercomunicar duas blockchains diferentes e permitir que seus usuários realizem trocas atômicas instantâneas que podem ser alternadas perfeitamente para mainchain.
Prós e contras do HTLC
Uma das maiores vantagens dos HTLCs é facilitar as transações em canais de pagamento P2P. Desta forma, é fácil criar uma rede de nós que manuseie todos esses canais off-chain, e encaminhe esses pagamentos para que as partes recebam os pagamentos com segurança. Desta forma, sem a necessidade de contar com nós intermediários, é possível criar uma rede de pagamentos gigantesca, quase instantânea, segura e de baixíssimo custo.
Outro ponto a favor dos HTLCs é que as transações de pagamento podem ser protegidas com condições bem especificadas. Assim, o roubo de fundos ou ação maliciosa das partes dentro do sistema pode ser evitado.
Além disso, os HTLCs fornecem à rede Bitcoin uma grande melhoria em sua escalabilidade e capacidade de fazer micropagamentos. Isso, ao mesmo tempo que reduz os gargalos na cadeia, as comissões são reduzidas e a rede é dimensionada para atender a mais e mais pessoas.
Porém, nem tudo é positivo. Muitos especialistas do mundo da criptografia encontraram alguns problemas em HTLCs. Em primeiro lugar, há o ponto de rastreabilidade das operações, o que significa que os pagamentos feitos com HTLC não são anônimos. Outra desvantagem é que os HTLCs podem resultar em sistemas mais complexos e, portanto, em software com problemas de segurança não detectados.
Quanto você sabe, cryptonuta?
Os HTLCs são uma maneira real de melhorar os sistemas de pagamento usando Bitcoin?VERDADEIRO!
Os canais de pagamento, desde o tempo de Satoshi Nakamoto, têm sido vistos como o caminho a seguir para melhorar a experiência de pagamento usando Bitcoin. Isso levou os desenvolvedores e grande parte da comunidade Bitcoin a ver os canais de pagamento (incluindo HTLC) como o futuro dos pagamentos instantâneos, começando com a tecnologia líder nesse sentido, a Lightning Network (LN).
Outras alternativas para HTLC
Apesar das vantagens oferecidas pela implementação de HTLCs, alguns desenvolvedores têm seu interesse focado no desenvolvimento de novas alternativas a esses contratos inteligentes. Os desenvolvedores do ecossistema Lightning Network estão unindo forças para fazer mudanças profundas nesta rede. Isto com o intuito de utilizar a PTLC na execução de transações com um nível de privacidade muito superior às atualmente oferecidas pela HTLC.
Outros contratos inteligentes que estão surgindo na execução de transações com várias assinaturas, como Raiz principal. Tudo busca chegar a uma nova era de contratos inteligentes na rede Bitcoin que dão maior privacidade, versatilidade e segurança às transações.