Bitcoin Lightning vs. pagamento on-chain: taxas, confirmações e canais

As duas podem transferir valor denominado em bitcoin, mas usam a camada base de maneiras diferentes. Um pagamento on-chain cria uma transação que os nós do Bitcoin podem propagar e os mineradores podem incluir em um bloco. Um pagamento Lightning percorre canais de pagamento; cada pagamento individual não é gravado como uma transação Bitcoin própria na blockchain.

Essa diferença afeta taxas, disponibilidade, privacidade e os status exibidos pela carteira. Lightning não é outra moeda, e “off-chain” não significa ausência de regras ou riscos. Os participantes usam transações Bitcoin para abrir o canal e liquidar os saldos quando necessário.

A carteira escolhe saídas disponíveis, monta e assina a transação e a transmite aos nós do Bitcoin. Os nós podem retransmiti-la e mantê-la em seus próprios mempools até que um minerador a inclua em um bloco. A taxa de rede depende do tamanho da transação e da taxa escolhida, não apenas da quantidade de bitcoin enviada. Consulte o guia de processamento de pagamentos do Bitcoin Developer Guide.

O ID da transação permite verificar o que foi transmitido, mas ver a transação não significa que ela foi confirmada. Uma confirmação indica que um bloco contém a transação; blocos posteriores aumentam essa contagem. O destinatário ou serviço define quantas confirmações esperar conforme o valor e o contexto. O tempo dos blocos e a meta de confirmação não prometem disponibilidade em um minuto específico.

O destinatário pode compartilhar uma fatura Lightning com um pedido de pagamento, muitas vezes com valor, destino, descrição e prazo. A carteira de quem paga lê a fatura e procura uma rota com capacidade e limites adequados. A especificação de faturas BOLT 11 descreve os campos; a BOLT 7 trata de anúncios de canais e atualizações de roteamento.

O pagamento roteado usa transferências condicionais conhecidas como HTLC. Cada nó intermediário recebe o valor e as condições de tempo necessárias para o próximo trecho; o destinatário final revela o segredo que conclui o pagamento. A rota pode falhar se faltar liquidez na direção necessária, se uma atualização estiver desatualizada, se um limite for atingido ou se um nó estiver indisponível. Um pagamento Lightning bem-sucedido pode terminar sem esperar por um novo bloco, mas não há garantia de sucesso para todas as faturas.

Um canal de pagamento começa com uma transação de funding on-chain e tem uma capacidade total. Quando as partes pagam umas às outras, o saldo muda sem publicar uma transação Bitcoin separada para cada atualização. Quanto um lado pode enviar naquele momento depende do saldo naquela direção, das reservas, dos limites e da rota escolhida. O protocolo peer BOLT 2 descreve parâmetros de canal e limites HTLC.

Um canal com capacidade total suficiente ainda pode não ter liquidez de saída para um pagamento específico. O destinatário também pode não ter uma rota de entrada utilizável para aquele valor. Abrir um canal, mover liquidez ou fechá-lo pode exigir transações e taxas on-chain. A BOLT 5 sobre operações on-chain descreve fechamentos cooperativos e unilaterais. A ilustração separa pagamentos repetidos no canal do funding e do fechamento liquidados no Bitcoin.

Uma taxa on-chain paga por espaço no bloco. O total depende do tamanho da transação e da taxa escolhida para as condições atuais; uma transação maior pode custar mais mesmo enviando menos bitcoin. A estimativa da carteira muda e não reserva espaço em um bloco futuro.

As taxas de encaminhamento Lightning são definidas pelos operadores dos canais e podem combinar um valor base com um valor proporcional. Comprimento da rota, políticas, liquidez e comportamento da carteira afetam o total. Algumas carteiras podem incluir cobranças próprias de serviço ou liquidez. Lightning pode sair mais barata em um caso específico, mas não é sempre gratuita nem mais barata que on-chain. Antes de aprovar, confira o valor final, os detalhes das taxas e os requisitos da rota.

Uma carteira on-chain pode mostrar status como transmitida, pendente ou confirmada. Transações e blocos são públicos na blockchain, e o destinatário pode aplicar um limite de confirmações adequado ao valor e ao contexto. Uma transação pode continuar sem confirmação por mais tempo do que o esperado; a estimativa de taxa não controla a escolha dos mineradores.

Na Lightning, a fatura é paga quando a rota termina e a carteira recebe uma resposta de sucesso. Esse pagamento não é incluído separadamente em um bloco Bitcoin. Uma tentativa que falhou não é confirmação, e uma tela incerta não prova que pagar de novo seja seguro. Antes de tentar novamente, confira o status final da carteira que enviou e a fatura ou o comprovante do destinatário.

Dados on-chain são públicos e podem ser analisados, embora um endereço não revele automaticamente o nome de alguém. O onion routing da Lightning busca limitar o que cada nó intermediário sabe sobre a rota completa, mas não torna todos os pagamentos anônimos. A especificação BOLT 4 de onion routing e as atualizações públicas de canal descritas pela BOLT 7 mostram partes desse modelo de privacidade.

As carteiras também variam em quem controla as chaves e em como os canais são monitorados, copiados e recuperados. Uma carteira de autocustódia e uma conta Lightning custodial têm responsabilidades e riscos de falha diferentes. Internet, disponibilidade de peers, estado do canal, recuperação e termos do provedor podem importar. A palavra “Lightning” não informa sozinha quem guarda os fundos nem como o backup é protegido.

On-chain pode fazer sentido quando o destinatário fornece um endereço Bitcoin e quer uma transação verificável na blockchain. Lightning pode servir para carteiras compatíveis quando há uma fatura e liquidez suficiente na rota. Pagamentos pequenos e recorrentes podem usar um canal existente, mas abrir, manter e fechar canais têm custos e limites próprios.

Antes de enviar, confira o tipo de pagamento, a rede, o valor, o vencimento da fatura, o destinatário, a taxa exibida e os limites. Não cole uma fatura Lightning no campo de endereço on-chain e não use uma rota que o destinatário não pediu. Use uma alternativa on-chain apenas se a fatura e a carteira a oferecerem e suportarem explicitamente. Leia também: taxas de transação Bitcoin, confirmações de depósitos e lista de verificação para transferências cripto.

Referências técnicas primárias: Bitcoin Developer Guide: processamento de pagamentos; BOLT 2: protocolo peer; BOLT 4: onion routing; BOLT 5: transações on-chain; BOLT 7: informações de roteamento; BOLT 11: codificação de faturas.