HTLC

Os contratos de bloqueio temporal com hash são o que torna seguro o encaminhamento de um pagamento Lightning de vários saltos. Cada salto trava seu dinheiro no mesmo hash SHA-256, e um canal pode carregar no máximo 483 deles em cada direção ao mesmo tempo. Para você, é por isso que um pagamento Lightning ou é liquidado por completo ou falha por completo, e nunca deixa dinheiro preso no meio do caminho.

Como funciona

Duas condições protegem o dinheiro em um HTLC, e exatamente uma delas acabará sendo verdadeira.

O recebedor inventa um segredo aleatório de 32 bytes, chamado preimagem, calcula seu hash com SHA-256 e coloca o resultado na fatura. Cada nó ao longo da rota então oferece ao nó seguinte uma saída gastável de duas maneiras: imediatamente, por qualquer um que consiga mostrar a preimagem, ou, depois de uma altura de bloco acordada, pelo nó que a ofereceu. Como todos os saltos compartilham um único hash, no momento em que o recebedor reivindica seu dinheiro revelando a preimagem, cada salto anterior fica sabendo dela e reivindica o seu. Nunca ninguém paga adiante sem receber de volta, e é nessa propriedade que a Lightning se baseia.

As alturas de bloco diminuem ao longo da rota. Cada canal anuncia um cltv_expiry_delta, e o pagador empilha esses deltas para que o salto mais próximo do recebedor expire primeiro e cada salto anterior tenha uma margem de segurança. O BOLT 11 orienta o pagador a reservar pelo menos 18 blocos para o salto final quando a fatura não diz outra coisa. Esse atraso acumulado é o custo real de um HTLC: se um pagamento trava, o dinheiro não se perde, mas pode ficar congelado por horas enquanto os prazos se resolvem.

On-chain, esses contratos viram transações reais. Em um canal âncora, uma transação HTLC-timeout pesa 666 unidades de peso e uma transação HTLC-success pesa 706, e um fechamento forçado com vários pagamentos em andamento significa transmitir uma dessas para cada um deles. Valores pequenos demais para valer uma saída não recebem nenhuma; eles são somados à taxa de mineração, e é por isso que um pagamento minúsculo pode desaparecer nas taxas se um canal fechar no momento errado.

Onde você o encontra

Você encontra os HTLCs nos segundos entre tocar em pagar e a fatura ficar verde, e volta a encontrá-los no cálculo de taxas de uma troca on-chain.

Serviços com foco em Lightning, como a Strike, movimentam dinheiro assim em cada pagamento, e os nós de roteamento Lightning listam o número de HTLCs pendentes como métrica operacional, porque um canal cheio de contratos travados não consegue encaminhar nada. A mesma construção funciona fora da Lightning: um swap submarino troca um HTLC on-chain por um pagamento Lightning travado no mesmo hash, e um swap atômico entre cadeias faz o mesmo entre dois livros-razão. Em cada caso, o hash é o árbitro compartilhado e o prazo é o reembolso.

O limite importa mais do que parece. Uma transação de compromisso precisa continuar sendo uma transação de bitcoin válida, então o BOLT 2 proíbe mais de 483 contratos aceitos por direção, caindo para 114 no formato mais novo de compromisso sem taxa. Canais grandes de roteamento esbarram nesse teto em períodos de movimento intenso, e essa é uma razão honesta pela qual um pagamento às vezes falha e funciona trinta segundos depois.

HTLC vs PTLC

Um HTLC usa um único hash para toda a rota, enquanto um PTLC dá a cada salto um bloqueio diferente derivado de um ponto de curva elíptica. Essa única diferença é uma falha de privacidade: dois nós de roteamento do mesmo operador, em pontos diferentes da sua rota, podem ver o mesmo hash duas vezes e recompor o seu pagamento. Os HTLCs são o que a rede realmente usa. Os PTLCs são o substituto especificado, e até que sejam lançados, suponha que qualquer grande operador de roteamento pode correlacionar os saltos que encaminha.