56 / 736CHAN

Payment Channel

Canal de pagamento

Um canal de pagamento permite que duas partes façam pagamentos repetidos sem registrar cada um na blockchain. O que muda é o acordo sobre a divisão dos bitcoins; a possibilidade de liquidar esse acordo na blockchain lhe dá força. A Lightning Network se apoia nesses canais.

Um Payment Channel, ou canal de pagamento, permite mudar a divisão de bitcoins bloqueados em conjunto por meio de acordos assinados digitalmente. A assinatura confirma a aceitação da nova divisão; cada mudança não precisa entrar na blockchain, o registro público de transações do Bitcoin. Os participantes continuam tendo um meio de fechar o canal e liquidá-lo na blockchain. Aqui descrevemos um canal Lightning bilateral convencional com revogação: um acordo anterior pode ser revogado, e seu uso posterior pode ser penalizado. Outros modelos podem seguir regras diferentes.

Imagine duas partes atualizando seus direitos sobre uma quantia bloqueada em conjunto. Cada pagamento não precisa de uma transação Bitcoin própria em um bloco. Em vez disso, elas trocam assinaturas para um novo estado. Não é apenas uma planilha na qual precisam confiar: possuem transações que permitem impor a liquidação nas condições combinadas. [1] [2]

A transação de financiamento coloca bitcoins no canal. Sua saída é uma quantia com regras sobre quem pode gastá-la; a confirmação significa que a transação foi incluída em um bloco. Em um canal Lightning convencional, essa saída exige as assinaturas de ambos os participantes: 2-of-2. Antes de divulgar o financiamento, os participantes precisam ter um caminho válido para fechar unilateralmente. Normalmente aguardam confirmações. Em certas condições, zero-conf permite usar o canal sem esperar confirmação. O recebedor passa a depender mais de quem financia o canal: a transação ainda não está confirmada e pode ser substituída por outra que gaste os mesmos fundos. [2] [3]

Uma transação commitment é assinada antecipadamente para liquidar a divisão acordada naquele momento. Aqui, um nó é o programa que gerencia o canal e suas atualizações. Cada parte tem sua própria versão da transação commitment. Na atualização, os nós coordenam assinaturas e segredos de revogação por commitment_signed e revoke_and_ack. Um acordo mais recente não invalida uma transação antiga assinada segundo o consenso do Bitcoin. Por isso, a proteção contra a publicação de um estado revogado precisa estar nas condições das saídas. [2] [3]

Em um canal convencional com revogação, quem publica seu commitment espera to_self_delay para gastar os próprios fundos. O prazo é contado em blocos a partir da confirmação da transação commitment. Se publicou um estado revogado, a outra parte pode usar a chave de revogação para gastar as saídas relevantes como medida corretiva. É preciso agir a tempo e obter confirmação. Um Watchtower é um serviço que monitora a cadeia e pode usar dados preparados de antemão para reagir à publicação de um estado revogado. Ainda assim, esse serviço não garante sucesso nem substitui um backup. [3] [4]

Sat é a abreviação de satoshi, a menor unidade de bitcoin na cadeia. Capacidade é o valor total do canal, não o saldo de cada participante. Considere um canal de 100000 sat: Alice tem 70000 sat e Bob 30000 sat. Se Alice paga 10000 sat a Bob, a divisão passa a 60000 sat e 40000 sat. Para simplificar, ignoramos taxas e reservas. A capacidade não mudou, mas Alice pode enviar menos e receber mais. Reservas e pagamentos pendentes também afetam os limites reais. [6]

A Lightning procura rotas por vários canais conectados. Um HTLC é um pagamento condicionado: para receber os fundos, é preciso revelar um segredo, a preimage, cujo hash, ou impressão digital, corresponda ao valor conhecido de antemão. Condições de tempo também permitem a liquidação se o pagamento não for concluído. Os intermediários precisam de liquidez, ou seja, fundos disponíveis para enviar no sentido necessário, e podem cobrar taxas. Não é necessário um canal direto com cada comerciante, mas a conexão por si só não garante uma rota utilizável para qualquer valor. [2] [4]

No fechamento por acordo, ou cooperative close, os participantes combinam a transação de fechamento, a divisão dos fundos e a taxa. Ambos assinam e publicam a transação na blockchain. Em geral é mais simples que a liquidação unilateral, mas não é automaticamente gratuito ou imediato. A transação ainda precisa de confirmação e de uma taxa adequada às condições da rede. [2] [4]

Um fechamento unilateral, ou force close, permite publicar seu commitment atual sem obter novo consentimento do parceiro. Os fundos podem não estar disponíveis para gasto imediato: continuam valendo os prazos e a eventual resolução de HTLC. Outras transações e taxas podem ser necessárias. Existe uma saída de emergência, mas sua duração e seu custo dependem do estado do canal e das condições da blockchain. [3] [4]

Uma Seed Phrase é um conjunto de palavras de backup com as quais a carteira recupera suas chaves. Sozinhas, elas não restauram o estado mais recente de um canal aberto; siga o procedimento da sua carteira. Por exemplo, o LND, um programa para operar um nó Lightning, combina essas palavras com um Static Channel Backup (SCB). Esse backup estático guarda os dados necessários para contatar os parceiros e pedir que fechem os canais; não restaura canais para continuar fazendo pagamentos. A recuperação por esse caminho também depende da resposta dos parceiros. Já channel.db é o arquivo do banco de dados dos canais, e uma cópia antiga pode conter um estado perigosamente desatualizado. Nunca informe suas palavras de backup reais em um site de terceiros para “consertar” um canal. [5]

Descubra quem guarda as chaves, quem monitora os canais e como recuperar o acesso após perder o dispositivo. Custodial significa que o provedor do serviço guarda as chaves. Um saldo Lightning em um serviço custodial pode não representar um canal próprio. Na autocustódia, backups, disponibilidade e resposta a problemas ficam sob sua responsabilidade. Canais economizam registros na blockchain; não eliminam todas as tarefas operacionais nem os custos de liquidação. [4] [5]

Para ter uma visão mais completa, leia este verbete junto com Lightning Network, HTLC, Liquidez Lightning, Lightning Watchtower. Também há referências a este verbete em Confirmação, Gasto duplo, Timelock, HTLC.

DOC · 001Lightning Network paperFonte primária DOC · 002BOLT #2 — Channel lifecycleFonte primária DOC · 003BOLT #3 — Transaction and script formatsFonte primária DOC · 004BOLT #5 — On-chain handlingFonte primária DOC · 005Lightning Labs — Disaster recoveryDocumentação DOC · 006Lightning Labs — Managing LiquidityDocumentação
Revisto em: Fontes em primeiro lugar · Não é recomendação de investimento