Inbound Liquidity

Petr tem uma cafeteria e aceita pagamentos pela Lightning Network. Seu nó, o programa que cuida dos pagamentos, mostra fundos, mas um cliente não consegue pagar. A falta de liquidez de entrada pode ser uma causa. Um canal de pagamento é um acordo entre nós sobre a divisão dos bitcoins depositados. A parte de Petr é o local balance; a do parceiro, o remote balance. Receber um pagamento transfere valor do lado do parceiro para Petr. Para isso, precisa haver fundos do outro lado. O remote balance continua pertencendo ao parceiro: adquirir capacidade de receber não é ganhar bitcoins de presente nem receita já realizada. [1] [6]

Imagine um canal com capacidade de 1000000 sat. Sat abrevia satoshi, uma pequena unidade de bitcoin. Petr tem local balance de 800000 sat e o parceiro remote balance de 200000 sat. O espaço bruto de recebimento é, portanto, 200000 sat. Se Petr receber 100000 sat, seu lado sobe para 900000 sat e restam 100000 sat ao parceiro. Petr ganhou o pagamento, mas reduziu o espaço para receber mais. Para simplificar, o exemplo desconsidera reservas, taxas e pagamentos pendentes chamados HTLC, explicados adiante. Quando Petr financia sozinho um canal novo, sem transferência inicial ao parceiro, ganha principalmente capacidade de enviar. Confirmar a abertura não inverte essa direção. [1] [2]

Em um dia de boas vendas, os fundos aumentam do lado de Petr enquanto o espaço de entrada dos canais usados diminui. Um saldo maior pode vir com menor capacidade de receber o próximo pagamento. Infraestrutura própria exige acompanhar canais utilizáveis, valores esperados, pagamentos em andamento e custos de recompor liquidez. Algumas carteiras cuidam de parte disso pelo usuário, mas o mecanismo permanece. Petr talvez nem veja uma tentativa fracassada: o pagamento pode parar antes de chegar ao seu nó. Uma fatura emitida ou uma informação antiga de capacidade não confirma o recebimento. [6]

Ao pagar um fornecedor pela Lightning, Petr reduz o local balance dos canais usados e aumenta o remote balance. Isso pode abrir espaço para futuros recebimentos. Loop Out funciona de maneira semelhante: por meio de um swap, uma troca entre camadas de pagamento, ele envia valor da Lightning e recebe bitcoin em um endereço na blockchain. Não é preciso fechar os canais. Loop In faz o caminho inverso, convertendo fundos da blockchain em saldo disponível na Lightning. Nenhuma operação cria bitcoin. A comparação do resultado deve incluir taxas de roteamento, do serviço de swap e da transação na blockchain, além de verificar a conclusão da operação. [1] [4]

Outra possibilidade é o parceiro financiar um canal até Petr. Ele ganha espaço de entrada sem receber de presente os fundos do parceiro. A documentação da Lightning Pool descreve um mercado desses acordos: bid solicita liquidez e ask oferece fornecê-la. O aluguel tem prazo medido em blocos e envolve um prêmio e outras taxas. Um bloco é um grupo de transações acrescentado à blockchain, o histórico público de transações do Bitcoin. O prazo acompanha a chegada de blocos, não uma quantidade exata de horas. Não compra todo o saldo remoto. O prazo acordado também não significa que o mesmo valor ficará disponível durante todo o período: pagamentos mudam a distribuição. Tampouco se pode presumir disponibilidade permanente do canal depois do acordo. [1] [5]

Petr pode ter vários canais e precisar de espaço de entrada junto a outro parceiro. Circular rebalancing, o rebalanceamento circular, envia seu pagamento à rede por um canal e o traz de volta por outro canal seu. O canal de saída ganha espaço de entrada; o de chegada o consome. Fundos se movem entre os lados de Petr nos canais, sem criar capital, e o roteamento tem taxas. É necessária uma rota utilizável. Se faltarem fundos em todos os lados remotos de seus canais, não haverá por onde receber o pagamento de volta. O rebalanceamento circular sozinho não resolve isso. [1]

Parte dos fundos precisa ficar como reserva para o funcionamento seguro do canal. Outros fundos podem ficar temporariamente comprometidos em HTLC, compromissos de pagamento condicionais. O destinatário pode resgatá-los revelando um valor secreto a partir do qual se calcula o hash de pagamento combinado, um valor usado para verificação. Se o pagamento falhar, a parte que o enviou tem uma forma de recuperar os fundos após o prazo. BOLT 2, a especificação de gestão dos canais, também limita o valor mínimo, a quantidade de HTLC simultâneos e seu valor total. Assim, nem todo o remote balance estará disponível para outro pagamento. Somar saldos remotos e descontar uma reserva universal não basta; importam os canais individuais e seu estado atual. [2]

Um pagamento geralmente passa por vários nós. Mesmo que Petr tenha espaço para receber, um trecho anterior pode estar fora do ar ou sem fundos. BOLT 7 descreve mensagens channel_update, usadas pelos nós para anunciar condições de roteamento em uma direção do canal. Elas incluem taxas e htlc_maximum_msat, o limite de um pagamento condicional individual em msat, milésimos de satoshi. Não prometem saldo atual ao longo de toda a rota. Por isso, a soma do espaço de entrada de Petr não garante receber esse valor de qualquer remetente específico. Liquidez no destinatário é uma parte necessária da solução, mas não a única. [3]