A proposta de Lightning Network de Antoine Riard pode atenuar os ataques de bloqueio de canal?

Este é um editorial de opinião de Shinobi, um educador autodidata no espaço Bitcoin e host de podcast Bitcoin orientado para tecnologia.

O bloqueio de canal é um dos problemas pendentes mais ameaçadores da Lightning Network. Ele apresenta um mecanismo aberto para nós de ataque de negação de serviço na rede para impedi-los de rotear, perdendo dinheiro enquanto sua liquidez está bloqueada e incapaz de encaminhar pagamentos que lhes renderão taxas. Um invasor pode encaminhar um pagamento por meio de outros nós de si para si e se recusar a finalizar o pagamento. Isso torna essa liquidez inútil para encaminhar outros pagamentos até que o prazo do contrato de timelock hash (HTLC) expire e o pagamento seja reembolsado.

No mês passado, o desenvolvedor do Lightning, Antoine Riard, propôs uma especificação formal para uma solução para esse problema. Em agosto, Riard e Gleb Naumenko publicaram pesquisa olhando para o problema geral em si, bem como várias soluções diferentes que podem ser usadas para mitigá-lo ou resolvê-lo. Uma dessas soluções propostas era uma forma de credenciais anônimas que os nós poderiam usar para construir uma espécie de sistema de pontuação de reputação para usuários que encaminham pagamentos por meio deles sem ter que dox ou associar essa reputação a um identificador estático que impactaria negativamente a privacidade das pessoas. Esta solução tornou-se agora o proposta de protocolo formal feito por Riard no mês passado.

Por Dentro da Proposta de Mitigação de Bloqueio de Canal

O núcleo da ideia é um token de ecash Chaumian. Estes são tokens centralizados emitidos por uma autoridade de cunhagem de forma a impedir que a emissão de um token seja correlacionada com o resgate de um token posteriormente. Isso é feito assinando um token de maneira cega, permitindo que o destinatário do token o revele sem invalidar a assinatura. O emissor pode então verificar se é um token legítimo sem poder conectar esse token a quando foi emitido.

A proposta sugere o uso desses tokens Chaumian, emitidos por cada nó de roteamento da rede, como forma de prova de reputação. Ao rotear um pagamento, um token de ecash Chaumian emitido por cada nó no salto de pagamento seria agrupado no pacote de cebola para esse nó ao longo do pagamento. As unidades de token representariam tanto o valor do HTLC permitido quanto o período de bloqueio do reembolso. Antes de encaminhar o HTLC, cada nó verificaria se o token incluído em seu blob de cebola é válido e nunca foi resgatado antes, apenas encaminhando o HTLC se ambas as condições forem verdadeiras.

Se o HTLC for liquidado com sucesso com a pré-imagem sendo revelada, todos os nós ao longo do caminho de pagamento assinam e incluem um token Chaumian recém-emitido a ser devolvido ao remetente, junto com a pré-imagem HTLC. Se o HTLC não for resolvido com sucesso, os nós de roteamento “queimam” o token incluindo-o em sua tabela de tokens gastos e não emitem um novo token. Isso força o remetente a adquirir novos tokens desses nós para rotear os pagamentos por meio deles novamente. Todo o conceito é que os ataques de interferência sempre falham em resolver, portanto, nesse esquema, esses tokens emitidos por cada nó que você percorre são queimados se você executar um ataque de interferência e criar o custo de adquirir mais para fazê-lo novamente. No momento, os ataques de interferência não custam nada além de tempo, então isso acrescentaria um custo econômico a eles.

Então, é hora de discutir o elefante na sala: como você inicializa a emissão e a circulação desses tokens na rede? Cada nó que você deseja rotear exigiria um token emitido por eles. A solução: pagar por eles. Outra solução proposta para o problema de bloqueio de canal são as taxas iniciais, ou seja, cobrar uma taxa até mesmo para tentar encaminhar um pagamento, independentemente de ter sucesso ou não. Portanto, mesmo os pagamentos com falha incorreriam em uma taxa para o remetente.

A proposta de Riard é comprar esses tokens diretamente de cada nó como compras pontuais. Desse ponto em diante, em vez de pagar taxas iniciais para cada pagamento, desde que o pagamento anterior seja liquidado com sucesso, você receberá “tokens de roteamento” reemitidos que permitirão que seu próximo pagamento proposto seja roteado sem taxa. Dessa forma, os pagamentos bem-sucedidos pagam apenas a taxa de roteamento real e os pagamentos malsucedidos pagam apenas a taxa inicial, evitando uma espécie de “taxa dupla” para pagamentos bem-sucedidos. Pelo menos economicamente, pense nisso como uma espécie de meio-termo entre o estado atual das coisas, em que os pagamentos malsucedidos não custam nada e apenas os pagamentos bem-sucedidos pagam uma taxa, e um modelo de taxa inicial completa em que todos os pagamentos pagam uma taxa inicial e os bem-sucedidos também pagam uma taxa de roteamento.

Conclusões da proposta

Pessoalmente, acho que esse tipo de pagamento direto por tokens antecipadamente pode introduzir um grande grau de fricção de UX no processo de uso da Lightning Network. No entanto, acho que há uma solução bastante simples para esse atrito, ajustando um pouco a proposta.

Em vez de ter que pagar especificamente cada nó diretamente pelos tokens Chaumian com antecedência, a proposta poderia ser hibridizada mais diretamente com a proposta de taxa inicial. Se você tiver tokens para um nó, inclua-os no onion blob, se não simplesmente pagar uma taxa inicial diretamente na proposta HTLC e se o pagamento for liquidado com sucesso, você receberá tokens Chaumian de volta proporcionalmente ao que você deseja. -taxa frontal foi. Dessa forma, em vez de ter que coletar tokens de muitos nós diferentes com antecedência, você simplesmente os adquire ao longo dos pagamentos iniciais até obter uma boa coleta dos diferentes nós que você usa com frequência e muito raramente tem que arcar com o custo de taxas iniciais para alcançá-los.

Outra fonte potencial de atrito é para os operadores de nó e se resume a questões fundamentais do próprio ecash de Chaumian. Para garantir que um token seja gasto apenas uma vez, o emissor precisa manter um banco de dados de todos os tokens que foram gastos. Isso cresce para sempre, tornando as pesquisas para verificar a validade do token cada vez mais caras e demoradas quanto maior o banco de dados cresce. Por causa disso, Riard propõe que esses tokens Chaumian expirem periodicamente, em uma altura de bloco anunciada no protocolo de fofoca por nó. Isso significa que os remetentes precisam recomprar periodicamente esses tokens ou, se a implementação for compatível, resgatá-los por novos tokens assinados pela nova chave de assinatura após a anterior expirar.

Isso representaria um custo econômico regular para os remetentes de pagamentos ou exigiria que eles verificassem periodicamente para garantir a reemissão quando os tokens antigos expirassem. Na prática, isso pode ser automatizado para pessoas que executam seus próprios nós Lightning e, para quaisquer carteiras construídas em torno de um modelo de provedor de serviços Lightning (LSP), o próprio LSP pode realmente lidar com a aquisição e manutenção de tokens em nome de seus usuários, lidando com o provisionamento de tokens para pagamentos de seus usuários. À margem, no entanto, sem um nó Lightning completo ou LSP, isso pode se tornar um pouco incômodo para usuários de carteiras leves.

Acho que essa proposta pode realmente ajudar muito a mitigar o congestionamento de canal como um vetor de ataque, especialmente se hibridizado um pouco mais firmemente com o esquema básico de taxa inicial, e a maioria das fricções de UX podem ser tratadas com muita facilidade para usuários LSP e pessoas que operam seus próprios nós do Lightning. E mesmo que as taxas iniciais apresentem um alto grau de atrito, é possível que simplesmente comprovando o controle de um Bitcoin UTXO poderia ser usado no lugar de realmente pagar taxas para adquirir tokens.

Este é um post convidado por Shinobi. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.