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.