Ir para o conteúdo
Financial Context Wiki

Contrato com bloqueio por hash e tempo (HTLC)

Um HTLC permite resgatar um pagamento com uma pré-imagem antes do vencimento e reembolsá-lo por outro caminho depois. Entenda como coordena canais de pagamento e swaps atômicos e onde pode falhar.

Atualizado

Somente para fins educacionais; não constitui aconselhamento de investimento, jurídico ou de segurança. A segurança de um HTLC depende dos scripts ou contratos exatos, das regras das redes, da política de confirmação, das taxas, do monitoramento e da ação em tempo hábil.

Resposta direta

Um contrato com bloqueio por hash e tempo (HTLC) é um pagamento condicional com dois caminhos de gasto concorrentes. Antes do vencimento, o recebedor pode resgatar ao revelar um valor x cujo hash corresponda ao valor comprometido h = H(x) e cumprir as assinaturas ou autorizações exigidas. Depois, o pagador pode usar o caminho de reembolso. A ordem exata no limite é definida pela rede e pelo contrato, não pela palavra “antes”.

O hash lock conecta ações: conhecer a mesma pré-imagem pode permitir liquidar um pagamento de entrada relacionado após pagar um de saída. O time lock limita o período condicional. Canais de pagamento usam essas propriedades para encaminhar pagamentos; swaps atômicos podem coordenar transferências em sistemas distintos.

Um HTLC não é automaticamente sem confiança, atômico, privado ou autoexecutável. Também depende de código correto, hash e codificação compatíveis, vencimentos escalonados, premissas de finalidade, acesso a taxas, monitoramento e confirmação antes do prazo. O HTLC da Lightning é um projeto Bitcoin especificado; contratos em outras redes podem ter semântica diferente.

  • Ramo de hash: revele a pré-imagem e cumpra a autorização de sucesso enquanto o caminho for válido.
  • Ramo de tempo: cumpra a autorização de reembolso quando o bloqueio absoluto ou relativo vencer.

Como funciona

Em um pagamento, Bob escolhe uma pré-imagem nova e imprevisível x, calcula h = H(x) e entrega h a Alice. Alice bloqueia fundos sob regras que comprometem h, identificam as partes autorizadas e fixam o vencimento T.

  • Alice confere algoritmo, codificação, valor, ativo, recebedor, destino de reembolso, rede e vencimento antes de financiar.
  • Bob verifica a saída realmente financiada ou o contrato implantado, não um rascunho ou a interface.
  • Se Bob resgatar pelo ramo de sucesso, fornece x; a lógica verifica H(x) = h e a autorização.
  • Publicar ou transmitir x pode permitir a Alice ou a um intermediário liquidar outro HTLC com o mesmo hash de pagamento.
  • Se o sucesso não for usado a tempo, o reembolso torna-se elegível em T; isso não o transmite nem confirma.
  • Ainda é preciso preparar ou guardar a transação, pagar taxa suficiente, enviá-la, vigiar substituições e conflitos e obter confirmações.
  • Depois de revelar x a uma contraparte ou rede pública, trate-o como público e não o reutilize em outra condição.

Bitcoin distingue bloqueios absolutos e relativos. OP_CHECKLOCKTIMEVERIFY do BIP 65 impede o gasto até a altura ou tempo de bloco codificado pelo locktime; OP_CHECKSEQUENCEVERIFY do BIP 112 aguarda idade relativa suficiente da entrada. Os campos da transação também devem ser compatíveis. Um time lock é uma regra de validação, não um agendador.

Na Lightning, update_add_htlc leva valor, payment_hash e cltv_expiry. Cada salto oferece um HTLC de saída que vence antes do HTLC de entrada correspondente, deixando tempo para aprender a pré-imagem e resgatar a montante. O BOLT 3 define saídas de compromisso, caminhos HTLC-success e HTLC-timeout, assinaturas, revogação, corte por poeira e atrasos; o esboço de dois ramos não implementa um canal completo.

Exemplo

Considere, apenas para ensino, Alice trocando 1 BTC pelos 20 ETH de Bob. O exemplo mostra somente a ordem: produção exige código revisado para cada rede e não deve copiar estes prazos nominais.

  • Alice gera novos x e h = H(x) e bloqueia 1 BTC para Bob resgatar com a pré-imagem e Alice reembolsar após 48 hours.
  • Após verificar a transação Bitcoin e a política de confirmação, Bob bloqueia 20 ETH com hash e codificação compatíveis; o caminho de Alice termina após 24 hours e depois há o reembolso de Bob.
  • Antes de revelar x para resgatar 20 ETH, Alice verifica ID da rede Ethereum, bytecode, endereço, ativo, valor, partes, h e os dois caminhos invocáveis.
  • Bob obtém x do resgate ou da mensagem acordada e tenta o caminho de sucesso Bitcoin antes do prazo posterior.
  • Se a troca parar antes da revelação, cada reembolso só fica elegível pelas regras de sua rede; cada parte deve enviá-lo e confirmá-lo.

A diferença entre 48 hours e 24 hours é uma margem de reação, não um parâmetro universalmente seguro. Modele reorganizações, tempo de bloco, finalidade, execução, relés, mempool, taxas, censura e latência nos dois sistemas. A segunda parte não deve avançar só porque a interface diz “confirmado”.

Riscos

  • Compromisso errado: algoritmo, comprimento ou codificação diferem e o mesmo x não funciona nos dois lados.
  • Artefato errado: saída, ID de rede, endereço, bytecode, ativo, valor, recebedor ou reembolso divergem da interface.
  • Ordem insegura: prazos iguais ou próximos impedem resgate a montante após pagamento a jusante.
  • Erro de limite: altura, tempo de bloco, timestamp, idade relativa e comparações < e <= não equivalem.
  • Sem reembolso automático: maturidade só valida o gasto; carteira, nó, usuário ou vigia precisa agir.
  • Taxa e poeira: o resgate pode ser antieconômico, cortado na Lightning, ficar preso ou exigir o ativo nativo de taxa.
  • Confirmação e reorganização: ver transação ou pré-imagem não significa liquidação irreversível.
  • Corrida e congestionamento: sucessos, timeouts, substituições, conflitos ou atrasos maliciosos consomem a margem.
  • Implementação: falhas de script, contrato, carteira, assinatura, nonce, RPC ou cliente podem invalidar os caminhos.
  • Monitoramento: uma parte offline pode perder revelação, vencimento, fechamento forçado, substituição ou último momento útil.
  • Privacidade: hashes reutilizados, pré-imagens, valores, horários e eventos podem correlacionar transferências.
  • Opcionalidade e bloqueio: uma parte pode imobilizar liquidez e desistir; conclusão e compensação não são garantidas.

Antes de arriscar valor, teste sucesso e reembolso com quantia insignificante, registre artefatos e prazos, reserve taxas e atribua monitoramento e transmissão em falhas.

Equívocos comuns

  • “Os fundos voltam automaticamente no vencimento.” Em geral só se habilita o reembolso; alguém deve transmiti-lo e confirmá-lo.
  • “Cumprir H(x) = h é o contrato inteiro.” Assinaturas, ramos, campos, regras, revogação e autorização também importam.
  • “O mesmo vencimento nos dois lados é justo.” Intermediário ou segundo ator precisa de margem a montante após conhecer x.
  • “Uma pré-imagem visível garante tempo para resgatar.” Confirmações, reorganização, congestionamento, taxas e censura podem esgotá-lo.
  • “Atômico significa duas redes mudando numa transação indivisível.” Estados separados são coordenados; aborto, reembolso e estados unilaterais temporários continuam possíveis.
  • “HTLCs são anônimos e eliminam toda confiança.” Vazem sinais e dependem de código, redes, chaves, monitoramento e operação.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...