Lightning Routing é encontrar e usar um caminho para pagar pela rede Lightning. Esse caminho é formado por canais de pagamento: seus participantes bloqueiam fundos em conjunto no Bitcoin e atualizam quanto pertence a cada um. Programas chamados nós gerenciam esses canais. O remetente geralmente planeja a rota com informações públicas, dados do destinatário e tentativas anteriores. Porém, não conhece todos os saldos atuais; por isso, precisa estimar se o caminho funcionará e, às vezes, tentar outro.
Anna quer pagar um café, mas não tem um canal com a cafeteria. Ela tem um com Pavel, que por sua vez tem outro com o estabelecimento. O pagamento pode passar por ele: no primeiro canal, parte do saldo passa de Anna para Pavel; no segundo, de Pavel para a cafeteria. Não é a mesma moeda que circula entre canais; os saldos mudam em etapas vinculadas. Por isso, Pavel precisa de fundos próprios disponíveis no lado pelo qual paga à cafeteria. A carteira ou o nó do remetente escolhe o caminho até o destinatário e prepara instruções para cada etapa. O destinatário informa os dados necessários e os recursos compatíveis; pode incluir informações sobre um trecho final não público. Os nós intermediários encaminham o pagamento conforme as instruções, sem procurar cada um a rota inteira até o destino. [1] [4]
Gossip é a forma de distribuir informações entre nós. BOLT #7 descreve anúncios de canais e atualizações por direção: taxa básica e proporcional, diferença entre prazos CLTV, valores mínimo e máximo e indicador de disponibilidade. As condições anunciadas não comprovam que o outro nó esteja online ou tenha fundos suficientes naquele momento. Aqui, CLTV se refere a um prazo expresso como altura de bloco do Bitcoin, ou seja, sua posição na cadeia, não como um horário exato. A diferença entre os prazos dá ao intermediário tempo para reagir caso o encaminhamento pare. [2]
A capacidade total de um canal não informa quanto cada lado pode enviar agora. O remetente conhece seus próprios canais; para os demais, usa estimativas e o histórico de sucessos e falhas. O programa considera tanto a taxa quanto a probabilidade de passagem. Outro pagamento pode alterar a liquidez nesse intervalo, ou seja, os fundos que podem ser enviados na direção necessária. [4] [5]
As etapas são vinculadas por HTLC, pagamentos condicionais cuja conclusão exige revelar o segredo correspondente. Se um pagamento não for concluído, os fundos podem ser recuperados após o prazo. O cálculo começa no valor destinado ao recebedor e segue para trás. Cada intermediário precisa receber o valor para o próximo nó mais sua própria taxa. O HTLC de entrada deve expirar suficientemente depois do de saída, conforme a diferença CLTV exigida. Um caminho mais longo pode aumentar os custos e o tempo durante o qual os fundos ficam comprometidos se houver um problema. [1] [2]
Onion routing, conforme BOLT #4, usa a construção Sphinx: cada etapa recebe instruções criptografadas separadamente. O intermediário conhece seus parceiros anterior e seguinte e suas próprias instruções. O pacote, por si só, não revela a rota completa, seu comprimento nem a posição exata do nó. A análise do tráfego ou a colaboração entre nós ainda podem reduzir a privacidade. [1]
Um canal pode falhar temporariamente, a taxa ser insuficiente, o CLTV estar incorreto ou o próximo parceiro estar indisponível ou ser desconhecido. O remetente recebe apenas informações limitadas sobre o erro. Seu programa pode reduzir a pontuação da rota, recalculá-la e tentar de novo. Isso não é uma multa paga ao nó, e um resultado isolado não é uma avaliação permanente de confiabilidade. [1] [4]
Encontrar conexões não basta: cada etapa precisa aceitar o HTLC e ter fundos disponíveis suficientes na direção necessária. Parte do saldo pode estar reservada ou comprometida em pagamentos ainda não concluídos. Os campos técnicos htlc_minimum_msat e htlc_maximum_msat também definem os valores mínimo e máximo de um único HTLC naquela direção. A unidade msat equivale a um milésimo de satoshi; o satoshi é a menor unidade de valor na blockchain do Bitcoin. Mesmo um limite anunciado alto não comprova que a liquidez necessária esteja disponível agora. Assim, um único canal inadequado pode impedir o uso de toda a rota. [2]
Se o destinatário aceita basic MPP, ou seja, um pagamento dividido em várias partes, o remetente pode dividir o valor total, identificado no protocolo como total_msat, entre várias rotas. O destinatário espera as partes necessárias e as liquida em conjunto. Isso aproveita a liquidez distribuída entre canais, mas MPP não cria liquidez nova. Aumentam os HTLC, as tentativas e, possivelmente, as taxas. [1]
Route hints, em BOLT #11, podem fornecer ao remetente dados sobre as últimas etapas não anunciadas. Route blinding, usado em BOLT #12, oferece em vez disso um trecho final criptografado por meio de um nó de entrada, o introduction point. O remetente ainda precisa encontrar um caminho utilizável até esse ponto e cumprir as condições agregadas de taxas e CLTV. Mais privacidade não garante a entrega. [3] [6] [1]
Nos pagamentos do dia a dia, a carteira cuida da busca de rotas. Os detalhes a seguir são mais úteis para operadores de nós e para investigar problemas recorrentes. Registre o programa e sua versão, o valor, os limites de taxa e CLTV, o número de tentativas, as rotas usadas, o tempo até a conclusão e a causa exata da falha. Compare o mesmo par de nós em momentos próximos. O sucesso descreve um pagamento específico em determinado estado da rede, não uma pontuação global permanente. [4] [5]
Para ter uma visão mais completa, leia este verbete junto com Lightning Network, HTLC, Liquidez Lightning, Payment Channel, Bitcoin, Inbound Liquidity. Também há referências a este verbete em HTLC, Liquidez Lightning, BOLT 12, Inbound Liquidity.