Os limites do Lightning, Ark e as novas camadas de pagamento

Curiosidade

1. Por que um canal de pagamento que possui dez bitcoins ainda não consegue enviar nove?
2. O que acontece com um usuário que fica off-line por dois dias enquanto sua contraparte monitora a cadeia?
3. Uma rede com capacidade pública de alguns milhares de bitcoins pode atender bilhões de usuários em potencial?

Explorar

Parte IOs limites do Lightning

1. Um canal de pagamento é um buffer finito, e não um tubo infinito. A capacidade total é fixa no momento da abertura; à medida que os recursos se movem de um lado para outro, o saldo de saída do remetente diminui, enquanto o saldo de entrada aumenta. Um usuário que gasta de forma agressiva esgota sua capacidade de enviar mais recursos até receber pagamentos ou reequilibrar a situação por outra via. Transferências grandes que excedem a capacidade de saída restante do canal falham imediatamente, forçando tentativas repetidas ou o uso de métodos mais lentos.
2. Receber liquidez é estruturalmente mais difícil do que enviá-la para novos participantes. Abrir um canal com os próprios fundos cria apenas capacidade de envio; a contraparte detém todo o saldo de entrada. Para receber pagamentos, um usuário precisa ou gastar primeiro (transferindo recursos para fora), pedir a outra pessoa que abra um canal em sua direção ou adquirir liquidez de entrada de um provedor de serviços. Essa assimetria gera uma dependência persistente de terceiros ou de um histórico de transações anterior para novos nós que entram na rede.
3. A segurança sem custódia requer vigilância constante. Se um nó ficar off-line enquanto sua contraparte transmite um estado de compromisso desatualizado, o usuário off-line tem uma janela limitada para responder com uma transação punitiva usando segredos de revogação. Perder essa janela permite que o trapaceiro mantenha o que lhe foi pago no estado antigo. As torres de vigilância podem monitorar em nome dos usuários, embora o usuário precise confiar na torre para permanecer online e agir; uma torre não pode roubar fundos. Para muitos usuários, manter um nó online 24 horas por dia é um fardo prático que os serviços custodiados absorvem ao gerenciar a infraestrutura internamente.
4. A topologia da rede é distribuída de forma desigual. A eficiência do roteamento depende de nós grandes e bem financiados que possuem liquidez substancial em vários canais, a fim de facilitar transferências de alto volume. Nós menores costumam não ter a capacidade ou conectividade necessárias para rotear pagamentos significativos de forma independente, criando gargalos. Ataques de sondagem podem revelar os saldos dos canais ao enviar pagamentos de teste que falham em etapas específicas, permitindo que observadores mapeiem onde está a liquidez, o que enfraquece a privacidade dos pagamentos.
5. Os custos na cadeia permanecem uma restrição significativa para a adoção. Cada abertura e fechamento de canal requer uma transação em Bitcoin, gerando taxas que aumentam durante períodos de alta atividade no mempool. Para usuários que abrem e fecham canais com frequência, essas taxas podem corroer as economias obtidas com pagamentos fora da cadeia. Soluções como fábricas de canais e acordos visam reduzir esse ônus, permitindo que vários usuários compartilhem um único resultado na cadeia ou apliquem scripts complexos sem sobrecarregá-los, mas sua implementação generalizada ainda está pendente.
6. A capacidade da rede pública permanece modesta em relação à oferta total do Bitcoin. De acordo com observações recentes, a soma de todos os canais públicos fica na casa dos poucos milhares de BTC, enquanto os canais privados, que não são visíveis no grafo, representam uma parcela significativa, mas desconhecida. Essa visibilidade pública limitada dificulta a avaliação da verdadeira saúde da rede ou da profundidade de liquidez. O ataque de ciclo de substituição (replacement-cycling) divulgado em 2023 mostrou que um invasor poderia explorar as regras de substituição no mempool para impedir que a transação de timeout de um nó de roteamento fosse confirmada até que o prazo upstream passasse, e então tomar os fundos; as mitigações reduzem, mas não eliminaram, o risco.

Parte IIArk e as novas camadas de pagamento

7. Burak Keceli propôs o Ark em maio de 2023 como um protocolo de segunda camada que permite a muitos usuários compartilhar UTXOs coordenados por um operador. Diferentemente do Lightning, que requer canais entre duas partes com liquidez pré-financiada, o Ark agrega saldos em saídas compartilhadas geridas pelo operador. Essa estrutura reduz significativamente a pegada on-chain por usuário, visando à adoção global da autocustódia sem a complexidade do gerenciamento de canais.
8. O mecanismo central depende do operador coordenar os pagamentos off-chain enquanto mantém um estado válido no Bitcoin. Os usuários podem sair unilateralmente para seus próprios endereços a qualquer momento antes que suas saídas compartilhadas expirem, enviando uma transação on-chain. Esse caminho de saída é crucial: ele impede que o operador congele fundos indefinidamente, diferenciando o Ark dos modelos custodiantes nos quais o emissor detém o controle exclusivo das chaves.
9. A Ark Labs lançou o Arkade, realizando seus primeiros pagamentos na mainnet em agosto de 2025 e abrindo ao público em outubro de 2025. Simultaneamente, a Second desenvolveu o Bark, uma implementação distinta que chegou à mainnet em 9 de junho de 2026. Os dois sistemas não são interoperáveis; os usuários não podem transferir fundos diretamente entre Arkade e Bark sem antes sair para a camada base, o que cria pools de liquidez fragmentados.
10. Em comparação com o Lightning, o Ark elimina a necessidade de liquidez de entrada para receber pagamentos. No Lightning, um usuário precisa abrir canais com pares para aceitar pagamentos, exigindo uma gestão cuidadosa da liquidez. O Ark simplifica isso ao permitir que o operador gerencie internamente estados semelhantes aos dos canais, e suas transações compartilhadas oferecem aos usuários algum nível de privacidade semelhante à do CoinJoin.
11. Os trade-offs envolvem a disponibilidade (liveness) do operador e os custos de saída. Se um operador ficar off-line, os usuários ainda podem sair on-chain, mas precisam pagar taxas de transação e aguardar confirmação. Timeouts determinam com que rapidez um usuário pode forçar uma saída caso o operador não assine as transações cooperativas. As saídas compartilhadas também expiram: no design original, os usuários devem ficar online para atualizar seus saldos antes do timeout, muitas vezes de semanas, ou o operador pode reivindicar a saída.
12. Os sistemas Ecash oferecem privacidade, mas são custodiantes: o Cashu depende de um único mint, o Fedimint de uma federação, e ambos detêm o bitcoin. O Ark visa à autocustódia não custodial com benefícios semelhantes de privacidade. O debate continua sobre se essa complexidade é justificada em comparação ao ecossistema maduro do Lightning, já que ambos os protocolos coexistem e podem se complementar em futuros stacks de pagamento.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• A. M. Antonopoulos, O. Osuntokun & R. Pickhardt, Mastering the Lightning Network (2021)
• A. Riard, replacement cycling disclosure (bitcoin-dev mailing list, October 2023)
• Public network statistics from 1ML and mempool.space Lightning
• Ark protocol documentation (ark-protocol.org)
• Bitcoin Magazine, 'Bark Launches on Mainnet' (June 2026)
• Ark Labs announcements (August and October 2025)