Pular para o conteúdo
buybitcoinsmart

Glossário / Lightning e camada 2

Delta de expiração CLTV

O que é um delta de expiração CLTV?
Um delta de expiração CLTV é o número de blocos que um nó da Lightning subtrai do timelock de um pagamento recebido antes de repassá-lo, anunciado por direção de canal no gossip.

Cada nó que encaminha em uma rota Lightning cobra dois preços, uma taxa em milisatoshis e um atraso em blocos, e o delta de expiração CLTV é o atraso. O BOLT 7 o carrega como um campo de 16 bits na mensagem channel_update, ao lado de fee_base_msat, e cada lado de um canal publica seu próprio valor de forma independente. Se um pagamento travar, essa pilha de blocos é o tempo que seu dinheiro fica congelado.

Como funciona

O delta de expiração CLTV é escolhido pelo nó que fará o encaminhamento, e ele rege apenas a direção de saída desse nó.

A redação da especificação é exata: um nó deve definir o campo com o número de blocos que subtrairá do cltv_expiry de um HTLC recebido. Portanto o delta não é um prazo, é uma diferença. O nó aceita um pagamento bloqueado até certa altura de bloco absoluta, fica com o delta para si e oferece ao próximo salto um pagamento bloqueado até essa altura menos o delta. Essa diferença é a margem de segurança do nó: se o salto seguinte liquidar no último momento possível, restam ao nó esses tantos blocos para reclamar o pagamento na ponta anterior.

Cada canal público carrega dois desses números, um por direção, cada um assinado pelo nó que o definiu. Eles viajam no channel_update, a mensagem do tipo 258, ao lado de htlc_minimum_msat e dos dois campos de taxa. Só importam as atualizações anunciadas pelos nós que vão encaminhar: em uma rota de A para B para C para D, o pagador usa a atualização de B para o trecho de B para C e a de C para o trecho de C para D, e nenhuma das suas próprias.

Por isso as rotas são construídas de trás para frente. O pagador começa no destino com a expiração final mínima que a fatura pede, retrocede somando o delta anunciado de cada salto, e o total acumulado se torna o timelock do HTLC que ele entrega ao seu primeiro par. Quando um nó revisa seus preços, o BOLT 7 pede que ele continue aceitando os parâmetros anteriores por 10 minutos, porque o gossip não chega a todos os pagadores ao mesmo tempo.

Onde você vê isso

Os deltas de expiração CLTV decidem quanto tempo um pagamento Lightning travado prende seu saldo, e o próprio exemplo de roteamento do BOLT 7 coloca números em duas rotas de resto idênticas.

Quatro nós formam um losango: A, B, C e D, anunciando 10, 20, 30 e 40 blocos, com C pedindo um delta de expiração final de 18, que a especificação chama de padrão. A envia 4.999.999 milisatoshis a C. Encaminhado por B, A entrega ao seu par 5.010.198 milisatoshis, 10.199 deles como taxa de B, e o primeiro HTLC expira na altura de bloco atual mais 80: 20 blocos para o salto de B, 18 para C e 42 a mais de preenchimento. Encaminhado por D, o mesmo pagamento custa 5.020.398 milisatoshis e expira na altura atual mais 100. Mesmo remetente, mesmo destinatário, mesmo valor, e 20 blocos a mais de exposição.

Esse 42 não é folga arbitrária. O BOLT 7 adverte que uma rota construída somando os deltas honestamente permite que um nó intermediário descubra sua própria posição e, a partir daí, adivinhe quem está sendo pago, então o pagador é aconselhado a adicionar um deslocamento aleatório, obtido percorrendo o grafo para fora a partir do destinatário e somando os deltas que encontra. A especificação chama o resultado de shadow route extension.

Nada disso é você quem define, a menos que você opere o nó que encaminha. A Phoenix, que nossa análise chama de um verdadeiro nó Lightning autônomo no celular, publica seu preço de envio como 0,4% mais 4 sat, e essa tabela precifica o dinheiro, não os blocos.

Delta de expiração CLTV vs OP_CHECKLOCKTIMEVERIFY

Um delta de expiração CLTV é um número de política de roteamento publicado no gossip, enquanto OP_CHECKLOCKTIMEVERIFY é o opcode de script do bitcoin que impõe um prazo absoluto on-chain.

Eles compartilham três letras e pouco mais. Um delta é relativo e vive inteiramente off-chain: não aparece em nenhum script, nenhum nó completo o valida, e o nó que o definiu o revisa com um novo channel_update. OP_CHECKLOCKTIMEVERIFY está escrito na saída, é verificado por todos os nós completos e não pode ser editado depois que a saída existe.

Não confundir com

Perguntas frequentes

Um delta de expiração CLTV maior me custa mais em taxas?

Não, ele custa tempo em vez de dinheiro. Um salto anuncia seu atraso e sua taxa como dois números separados no mesmo channel_update, então um salto barato ainda pode prender seu pagamento por um longo trecho de blocos se a rota falhar e tiver de expirar.

Qual é a diferença entre um delta de expiração CLTV e a expiração final em uma fatura?

O delta pertence a um salto que encaminha, enquanto a expiração final pertence ao destinatário. O pagador soma o delta anunciado de cada salto sobre a expiração final mínima que a fatura pede, que o exemplo de roteamento do BOLT 7 dá como 18 blocos.

Posso mudar o delta de expiração CLTV nos meus próprios canais?

Sim, se você opera seu próprio nó, porque é um número de política que você mesmo publica em um channel_update. O BOLT 7 pede que você continue aceitando os parâmetros anteriores por 10 minutos depois, para que pagadores que trabalham com um gossip mais antigo não sejam rejeitados.

Leia a seguir

Termos relacionados

Mais em Lightning e camada 2

Ler esta página em inglês