Tópico: Análise Quantitativa da Privacidade e escalabilidade na Lightning Network

Localização: Lightning Hacksprint (Fulmo)

Slides: https://docs.google.com/presentation/d/1H9EdrhjQ9x3q0qfsei7iFYINVf2lwPyjUKHd3CScy4k/edit#slide=id.g7774542944_0_0

Pesquisar: https://eprint.iacr.org/2020/303

Olá a todos. Meu nome é Sergei, eu sou um estudante de PhD na Universidade de Luxemburgo. Vou apresentar nosso trabalho em grupo com Pedro Moreno-Sanchez e Matteo Maffei da Universidade Técnica de Viena sobre alguns aspectos de privacidade e escalabilidade na Lightning Network. O paper completo pode ser encontrado aqui.

Vamos começar com uma contextualização de o que é a Lightning Network. A Lightning Network é uma solução de escalabilidade de segunda camada para o Bitcoin e a ideia geral é que aproveitamos as garantias de segurança do Bitcoin, mas nós realizamos a maioira das transações fora da blockchain (offchain). Assim nós melhoramos a latência e tornamos possíveis pagamentos de menor valor do que os que seriam possíveis no Bitcoin. Um canal de pagamento é um protocolo entre pares. Trata-se de um endereço multiassinatura 2-de-2 que permite às duas partes realizar transações e rebalancear o saldo nesse canal da forma que quiserem com atualizações offchain.

O elemento principal da Lightning é com certeza o mecanismo de revogação, um mecanismo de segurança baseado em teorias econômicas dos jogos. Esse elemento garante que se Alice tenta trapacear, Bob pode retaliar e tomar os fundos do canal e vice-versa antes de um determinado tempo (timeout) se esgotar. Portanto estamos negociando essa obrigação de estar online ao menos de vez em quando e acompanhando a blockchain, monitorando potenciais quebras de confiança. Mas estamos obtendo um grande volume de transações e uma latência muito baixa comparados à primeira camada, que é o Bitcoin. É claro que não precisamos abrir canais com todos os pares da rede. Podemos usar pagamentos multi-hop em que cada usuário abre apenas um pequeno número de canais com nodes selecionados e então pagamentos são roteados através de uma sequência de canais que são rebalanceados atomicamente. A atomicidade aqui é importante e é possível graças ao fato de que todas as atualizações de canais são ligados pelo mesmo valor secreto.

Aqui está o pagamento ilustrativo do Usuário 1 para os Usuários 2, 3, 4 e 5. A primeira parte de um típico pagamento Lightning é o Usuário 5 gerando um valor r aleatório localmente, calculando o hash desse valor H(r) e transferindo esse valor para o Usuário 1 em uma espécie de fatura (invoice). O Usuário 1 envia um HTLC, como um contrato hash timelocked para o Usuário 2 que essencialmente diz "Esse contrato entre o Usuário 1 e o Usuário 2 com o valor de hash de y (=H(r)), 1,3 moedas vão para o Usuário 2 se o Usuário 2 fornecer o valor que retorna o hash y. Caso contrário, se o Usuário 2 não fornecer esse valor antes do tempo 4 então o dinheiro será desbloqueado e o Usuário 1 poderá movê-lo como quiser". Esse é um passo de um pagamento multi-hop, os HTLCs sendo criados. Então o Usuário 2 cria um HTLC semelhante para o Usuário 3, oferecendo ao Usuário 3 enviar 1,2 moedas pois ele pega essa diferença como comissão. 0,1 é a comissão recebida pelo Usuário 2. Todos os Usuários subsequentes também pegam 0,1 moedas. O usuário 2 diz "Eu vou dar 1,2 moeda a você Usuário 3 se a pré-imagem desse hash for fornecida antes do tempo 3 e pegar esse dinheiro de volta caso isso não aconteça". Então uma vez o primeiro passo da sequência de pagamentos de HTLCs é criado, então o Usuário 5 revela o segredo do valor r e pega o dinheiro do Usuário 4. O Usuário 4 recebe do Usuário 3 e assim por diante e o pagamento é finalizado. Esse é geralmente o fluxo de pagamentos na Lightning Network.

Aqui vai o esboço dessa palestra. Essa palestra consiste em duas partes já que o paper foi feito em duas parte que são mais ou menos separadas. A primeira parte avalia as probabilidades de vários ataques à Lightning Network. A segunda parte avalia um certo aspecto que o protocolo Lightning tem na aplicabilidade de micropagamentos e sua visibilidade em circunstâncias do mundo real. Pode vir a ser que a Lightning Network, apesar da visão descrita no whitepaper origina, não seja boa para vários pequenos pagamentos.

Começando pela parte 1, deixem-me descrever os três ataques relacionados à privacidade que consideramos. Eu diria que os dois primeiros são relacionados à privacidade e o terceiro é mais um ataque de negação de serviço (DDoS). São eles "privacidade dos valores", "anonimidade da relação" e "ataques wormhole". Vou descrever em mais detalhes nos próximos slides o que exatamente são esses ataques e qual definição e os critérios para eles. Em geral estamos tentando responder quão prováveis são esses ataques e de que depende essa probabilidade. Porque é claro, a depender dos parâmetros da rede e das diferentes capacidades do atacante , a probabilidade dos ataques também é diferente.

O primeiro ataque que precisamos considerar é o da privacidade dos valores. Esse é provavelmente o ataque mais simples. O objetivo do atacante é descobrir o valor sendo transferido. Na Lightning Network os valores não são escondidos, não são encriptados, são transferidos em texto claro. Se o Usuário 3 quer saber quanto dinheiro está sendo transferido pelo seu node, pode olhar o HTLC e ver que ele recebeu um HTCL com valor 1,2 e foi solicitado a ele um HTLC de valor 1,1, o que significa que o valor verdadeiro do pagamento é aproximadamente 1. É claro que não podemos dizer com certeza porque diferentes nodes possuem diferentes políticas no que diz respeito a suas comissões. Assumindo que a comissão é relativamente pequena comparada com o valor do pagamento sendo transferido, isso significa que cada node ao longo da rota pode saber com alto grau de precisão quanto dinheiro está sendo transferido. É o suficiente então que o atacante controle apenas um dos nodes intermediários. Aqui o node número 3.

O segundo ataque é um pouco mais complexo. Aqui o atacante quer saber quem está pagando quem. Se formularmos esse problema no cenário como os criptógrafos sempre fazem quando eles falam sobre problemas e algoritmos criptográficos nós temos duas coisas acontecendo simultaneamente. A questão é se um atacante pode distinguir entre essas duas coisas com uma probabilidade significativamente maior do que 50%, aleatoriamente jogando uma moeda. Aqui esses dois eventos são dois pagamentos. Os pagamento vai do Usuário 1, passando pelos Usuários 2, 3 e 4 até chegar no Usuário 5. O segundo pagamento está indo do Usuário 1' através dos mesmos nodes intermediários 2, 3 e 4 até o Usuário 5'. O objetivo do atacante que controla dois nodes dentro dessa parte em comum da rota, digamos Usuário 4 e Usuário 2, é determinar que o Usuário 1' está pagando o Usuário 5' e não o Usuário 5'. É mais difícil formular esse problema do que resolvê-lo porque na Lightning Network como eu descrevi antes a atomicidade dos pagamentos é possível porque eles compartilham do mesmo hash do pagamento e da mesma pré-imagem do pagamento. Isso significa que para todas as atualizações de canais, para todos os HTLCs aqui nós temos o mesmo valor y aqui, aqui e aqui. No segundo pagamentos nós temos um valor y' aqui, aqui e aqui. Portanto esses dois nodes podem entender quem está realmente pagando quem.

O terceiro ataque que consideramos. Aqui o atacante está tentando trapacear e pegar todas as comissões dos participantes honestos. Imagine que o atacante controla os Usuários 2 e 4. A primeira parte do pagamento acontece como usualmente, a sequência de HTLCs é criada do Usuário 1, Usuários 2, 3, 4 e 5. Então o Usuário 5 começa a resgatar o pagamento revelando o valor secreto r para o Usuário 4. Então no lugar de compartilhar esse valor com o Usuário 3 e resgatar o valor do Usuário 3, o Usuário 4 apenas encaminha o valor r fora do protocolo Lightning direto para o Usuário 2, o que permite ao Usuário 2 resgatar o valor do Usuário 1. O resultado é que o Usuário 1 e 5 podem nem perceber nada porque do ponto de vista deles tudo ocorreu normalmente e o pagamento foi finalizado. Mas o Usuário 3 foi enganado aqui porque a comissão que seriam dos Usuários 2 e 3 foram coletadas apenas pelo Usuário 2. Não apenas o Usuário 3 perde a comissão, como também ele tem seu capital bloqueado porque esses HTLCs não são resgatáveis e vão precisar expirar. Apenas depois do timeout o Usuário 3 poderá retirar seus fundos, alocá-los em outro lugar ou usar os fundos no canal para encaminhar outros pagamento e ganhar comissões. Essa possibilidade é tirada desse usuário enquanto esse ataque está acontecendo.

Agora vamos falar sobre os parâmetros que influenciam a taxa de sucesso dos ataques. Primeiro de tudo é importante saber quantos nodes estão comprometidos. É claro que se a rede inteira estiver sobre controle do inimigo isso é basicamente game over, tudo está muito ruim. Se o atacante tem apenas um node em algum lugar na periferia da rede, provavelmente não é muito assustador. Estamos tentando quantificar o que acontece no meio do caminho. Quantos nodes um atacante precisaria comprometer para atingir uma taxa de sucesso não-negligenciável no ataque? Quais nodes estão comprometidos? Isso também é muito importante porque nodes possuem diferentes níveis de autoridade, por assim dizer, na Lightning Network. É claro que do ponto de vista do protocolo qualquer um pode participar, é uma rede aberta, você não precisa pedir permissão. Apenas coloque seu Bitcoin em canais abertos e você está bem. Mas por razões econômicas, alguns nodes possuem maior liquidez e mais canais. Obviamente pagamentos estão passando por eles mais ativamente do que por nodes com menos canais ou com menos capital comprometido. Intuitivamente faz mais sentido atacar esses grandes hubs de pagamento, mas de novonão sabemos quão mais eficiente isso seria comparado com outra abordagem. Estamos quantificando isso também mais a frente no paper.

Tudo é também dependente da quantia do pagamento, porque pagamentos menores tem mais opções. Um pagamento pode apenas ser roteado por um canal se for menor do que a capacidade daquele canal. Para ser ainda mais preciso se ele é menor do que o saldo do lado remetente do canal. Em todo caso, pagamentos menores possuem mais opções porque há uma quantidade maior de canais que pode acomodar pequenos pagamentos do que grandes pagamentos. Pode ser que o atacante controle alguns nodes grandes no meio da rede, mas pagamentos pequenos ainda possam passar por canais menores, mas pagamentos grandes não. Nós também quantificamos isso. Saber quão longas podem ser as rotas também é importante porque para rotas maiores é mais provável tropeçar em um node comprometido. Mas para os experimentos limitamos o tamanho dos caminhos para quatro canais o que significa três nodes intermediários. Nós mostramos esse gráfico no paper. Para valores de pagamento mais comuns para pagamentos pequenos e médios, é o suficiente que pelo menos alguns caminhos existam para um dado pagamento de um remetente aleatório para um destinatário aleatório. Isso significa que na vida real, já que as implementações Lightning são otimizadas entre outras coisas para rotas mais curtas, nós achamos que os resultados são aplicáveis também no mundo real.

Essa é a nossa abordagem de um ponto de vista mais prático. Nós não nos metemos com nodes ou canais Lightning reais. Conduzimos nossos experimentos em um ambiente simulado usando uma fotografia instantânea da Lightning Network. Primeiramente criamos um modelo gráfico de um instantâneo da Lightning Network. Aqui eu deveria dar um obrigado especial ao fiatjaf por esse website. Esse website contém informações histórias sobre todos os canais públicos timestamps de quando foram abertos, quando foram fechados e os montantes. Isso se provou de muito valor entre nossos recursos. Nós baseamos nossa pesquisa nesse conjunto de dados. Para uma dada combinação de parâmetros criamos 100 pares aleatórios, que seriam um remetente e um destinatário. Para cada par, geramos todos os caminhos que seriam teoricamente adequados para esses valores de pagamentos. Apenas contendo canais com capacidade maior ou igual ao montante do pagamento. Para cada caminho checamos se são propensos a um desses ataques ou não. Para cada um dos três ataques, nós definimos como um modelo, um padrão em um caminho. Nós comparamos cada caminho com esse padrão. Por exemplo, para a "privacidade dos valores", o padrão é muito simples. Apenas um node comprometido em qualquer lugar do caminho. Para "anonimidade da relação" o atacante precisa controlar dois nodes distintos ao longo do caminho. Para o "ataque wormhole" o padrão é um pouco mais complexo. Nesse caso o atacante precisa comprometer dois nodes na rota, mas é necessário haver um node honesto no meio porque esse será o node vítima do ataque. Então calculamos a porcentagem dos caminhos que são propensos a um ataque e a dos que não são. Fazendo uma média de todos os pares de remetentes e destinatários aleatoriamente, estimamos a probabilidade de um ataque bem sucedido, dada uma certa combinação de parâmetros.

Esses são nossos parâmetros e os valores que consideramos. Quais nodes estão sob controle de um atacante? Nós consideramos duas heurísticas para nodes importantes, para hubs importantes. Consideramos os nodes com maior quantidade de canais adjacentes a eles. E consideramos nodes com com maior capacidade nos canais. É claro que esses subconjuntos se cruzam em grande medida porque os nodes que abrem muitos canais costumam ser bem capitalizados, mas ainda assim esses são subconjuntos distintos da Lightning Network. Como grupo de controle nós utilizamos uma seleção aleatória de nodes. Outro parâmetro, outro eixo de análise é quantos nodes estão comprometidos. Consideramos valores de 0 a 100. Para referência, no momento de nossos experimentos em fevereiro de 2020 a Lightning Network possuía 5842 nodes e 35196 canais. Isso apenas falando da parte pública da rede. Os valores dos pagamentos também importante para nossos experimentos. Nós consideramos quatro quantidades diferentes de pagamento, os múltiplos de 10 de 100 a 100.000 satoshis, o que assumindo um câmbio de 10.000 dólares por Bitcoin correspondiam a 10 centavos de dólar, 1 dólar, 10 dólares e 100 dólares.

Esse slide apresenta nossos principais resultados. Deixe-me passar algum tempo explicando isso porque pode não ser óbvio. Nós temos esses 9 subgráficos. Cada subgráfico contém o eixo x que representa o montante do pagamento de 100 a 100.000. O eixo y mostra a porcentagem dos caminhos aleatórios entre um remetente e um destinatário que são vulneráveisa um ataque de 0% a 100%. As três colunas correspondem aos três ataques. Nós temos três gráficos para "privacidade dos valores", "anonimidade da relação" e "ataque wormhole". As três fileiras correspondem aos tipos de nodes que consideramos comprometidos. A fileira superior é a dos nodes mais conectados, a do meio é dos nodes com maior capacidade e aqui temos a dos nodes selecionados aleatoriamente. Em cada um dos subgráficos as linhas representam a proporção de caminhos vulneráveis para esse número de nodes comprometidos, de zero a 5, 10, 20, 50 até 100. Se pegamos um gráfico como exemplo. Se comprometermos zero nodes então para o pagamento de 100 satoshis nós temos 0% de caminhos vulneráveis, para 1000 satoshis nós temos 0% de caminhos vulneráveis, para 100, 1000, 10.000, 100.000 teremos 0% de caminhos vulneráveis, o que é absolutamente lógico já que temos zero nodes comprometidos. Então se tivermos 5 nodes maliciosos com a maior capacidade, nós comprometemos 5 dos nodes de maior capacidade e quantos caminhos estariam vulneráveis ao ataque de "privacidade dos valores"?Nós temos cerca de 30%, 25%, 20% e 30% para diferentes montantes. Então se comprometermos mais nodes, os 10 de maior capacidade nós teríamos cerca de 40% dos caminhos sendo vulneráveis. É assim que você deve ler esses gráficos. Se formos para o panorama global. Primeiro de tudo, nosso experimento controlado com os nodes aleatórios, é claro, não faz o menor sentido porque um atacante não atacaria nodes aleatoriamente, já que isso não o ajudaria. Apenas se o atacante comprometer 100 nodes aleatórios é que a probabilidade de sucesso em um ataque de "privacidade dos valores" sobe um pouco acima de zero. Mas para todos os outros casos, todo o resto é zero. Ataque randômico não funciona. Mas se o atacante comprometer os nodes com maior capacidade, aí sim vemos um padrão em comum que se repete em outros gráficos também, quanto mais nodes o atacante compromete, maior a fatia de caminhos vulneráveis. Isso também é lógico. Nesse caso em particular é o suficiente comprometer os 20 nodes de maior capacidade para que a probabilidade de sucesso seja maior do que 50%. Se 100 nodes são comprometidos, então temos perto de 100% de probabilidade de um ataque bem-sucedido. Como isso se compara com outras combinações de parâmetros? Se comparamos ao longo dessa fileira, como diferentes ataques se comportam quando os nodes de maior capacidade estão comprometidos? Nós vemos que o efeito é o mesmo, mas mais fraco. Se vamos de 5 para 10 para 20 nodes comprometidos, a porção de caminhos vulneráveis cresce apenas um pouco. Um "ataque wormhole", esse é provavelmente apenas um artefato estatístico, mas é mais difícil realizar um "ataque wormhole" considerando um número fixo de nodes comprometidos do que realizar um de "anonimidade da relação ou "privacidade dos valores". Vou explicar isso pelo fato de que a estrutura do caminho é mais simples nesse caso. Para o atacante é mais fácil comprometer um node em qualquer lugar do caminho como é o caso aqui, do que comprometer dois nodes do caminho como é o caso aqui. É ainda mais difícil comprometer dois nodes com uma restrição adicional de que um node honesto precisa estar entre os nodes comprometidos. Finalmente se compararmos esses gráficos através das colunas a questão é qual é melhor para o atacante? Seria focar nos nodes de maior capacidade ou nos mais conectados? Como mostramos em nosso gráfico, o preferível é focar em nodes mais conectados porque como vocês podem ver a probabilidade de ataque cresce mais rápido do que com nodes de maior capacidade. Comprometendo apenas 5 nodes bem conectados, o atacante tem uma chance de 50% de ataque bem-sucedido contra 25-30% no outro caso. Esses padrões também se repetem nesse gráfico e nesse gráfico também. De onde concluímos que para o atacante, dentre essas estratégias a mais lucrativa e o preferível é focar nos nodes melhor conectados. Talvez isso seja explicável pelo fato de que um grande número dos pagamentos na Lightning Network são relativamente pequenos e para pagamentos pequenos não importa muito que os canais sejam muito grandes. Importa mais se os nodes intermediários são bem conectados. Pagamentos regulares que não são muito grandes em termos de satoshis irão fluir através de nodes intermediários com a maior conectividade no lugar de maior capacidade.

A lição que podemos tirar da parte 1 é que é o suficiente comprometer uma quantidade relativamente pequena de nodes. Mesmo 100 nodes é por volta de 2% do tamanho da rede inteira. O atacante deveria provavelmente focar nos nodes mais conectados e não nos nodes de maior capacidade. É claro que comprometer nodes aleatórios é mais ou menos inútil como mostramos nos dados. Um fato interessante é que a entidade conhecida como LNBIG em algum momento controlou 40% da capacidade da Lightning Network, o que significa que o cenário em que muitos nodes importantes estão sob controle de uma única entidade centralizada não é tão fora da realidade. É na verdade bem próximo da realidade. É importante entender isso e o que isso significa para privacidade e segurança da Lightning Network. Há um trade-off de eficiência/privacidade, como acontece com frequência. Você precisa pagar por privacidade, se você quer proteger seus pagamentos você provavelmente não deveria otimizar muito no que diz respeito às taxas. Você deve entender que passar por grandes e populares nodes intermediários o torna mais vulnerável porque esses nodes são mais propensos a ser alvo de um ataque e portanto comprometer a privacidade dos seus pagamentos de seus usuários ou algo do tipo.

Agora partindo para a parte 2 do paper. Nós estudamos o problema dos HTLCs simultâneos. A questão que pesquisamos é como a Lightning Network lida com pagamentos concorrentes? Há esse fato pouco conhecido sobre a especificação da Lightning Network e de fato sobre as implementações também de que o número de HTLCs pendentes, ou seja, pagamentos simultâneos que a Lightning Network suporta é limitado porque o tamanho de uma transação no Bitcoin é limitado e nós precisamos ser capazes de fechar o canal em uma transação. Por isso o canal pode manter no máximo 966 HTLCs não liquidados. Chamamos isso de HTLC slots (espaços/vaga para HTLCs) e argumentamos que para pagamentos pequenos esses slots se esgotam mais rápido do que a capacidade do canal. Primeiro de tudo, para transações menores do que o limite de dust (transações "poeira") de 546 satoshis, HTLCs nem mesmo são criados, então esse problema que vamos discutir não se aplica para pagamento ultra pequenos. Eles não são protegidos pelas garantias de segurança do Bitcoin, de qualquer forma. Mas depois temos os pequenos pagamentos que são maiores do que o limite de dust em que os HTLCs são criados, mas pode acontecer de a quantidade de slots se esgote antes da capacidade do canal. O que significa que o canal será subutilizado. O canal pode estar em um estado em que possui maior capacidade e poderia teoricamente suportar ainda mais pagamentos, mas não pode porque tem 966 HTLCs não liquidados esperando pela pré-imagem ser revelada ou pelo tempo da transação (timeout) expirar. Nós tentamos medir esse efeito e medir a evolução desse efeito ao longo do tempo.

Nossa métrica mais importante que definimos no paper é a taxa efetiva de atualização do canal. Aqui está o exemplo ilustrativo para que entendam melhor o que significa. Se você considerar um canal com a capacidade de 10.000 satoshis então significa que teoricamente ele poderia suportar 1000 transações de 10 satoshis pendentes. Mas de fato, devido à especificação e às implementações não será permitido ao canal fazer mais do que 966 transações. O que significa que ele será subutilizado, haverá subutilização de capacidade.

É assim que esta porcentagem muda dependendo do valor da transação. Se o montante é maior do que o limite de dust, então o HTLC é realmente criado, nós calculamos que por volta de 20% é a real taxa efetiva de atualização. Os canais serão apenas 20% utilizados. Essa proporção de utilização, esse número de atualizações simultâneas que um canal pode realmente suportar em vez do montante que teoricamente deveria suportar cresce linearmente até que atinge o ponto de inflexão que chamamos de montante borderline (fronteira), que é por volta de 2700 satoshis. Acima desse limite a capacidade é o fator limitante. Esse problema com o limite de HTLCs não existe nesse caso porque a capacidade é o que limita a produtividade desse canal. Nesse intervalo entre um pouco mais de 500 satoshis e um pouco menos de 3000 satoshis, é onde está o intervalo para micropagamentos que queremos investigar um pouco mais.

Nós também calculamos a porção de canais afetados. Nós vemos novamente que para uma transação média bem próxima do limite de dust, quase 50% dos canais são afetados. Isso significa que metade dos canais da Lightning Network são menos efetivos do que poderiam sem essa limitação. Essa porcentagem de canais afetados cai até atingir aproximadamente 10%. Para uma transação média de aproximadamente 10.000 satoshis, temos ainda por volta de 10% dos canais podendo ser subutilizados por conta desse problema.

Nós também geramos uma série de snapshots no primeiro dia de cada mês desde primeiro de março de 2018, logo após o lançamento da mainnet (rede oficial, depois da versão de testes) e nós calculamos como a porcentagem de canais afetados mudou através do tempo. Observamos que tem aumentado para diferentes valores de transação, essa linha azul é o limite do dust. Aqui nós temos 1K, 10K e 100K satoshis. Todas essas linhas vinham crescendo de forma bastante constante até meados de 2019. Desde então, há cerca de um ano, elas têm sido estáveis. Isso significa que esse efeito que nós descrevemos não está piorando nem melhorando, mas que afeta a Lightning Network mais ou menos na mesma faixa que afetou durante o último ano.

Finalmente nós estávamos interessados em como o montante borderline foi mudando. Cresceu dramaticamente no final de 2018. E então se manteve relativamente estável e nos últimos meses está em algum lugar por volta de 2500 satoshis. Para pagamentos de valores menores do que 2500 satoshis esse problema é realmente relevante.

A lição é que a Lightning Network pode não ser tão bem adaptada para micropagamentos como o paper da Lightning Network previu. O paper da Lightning de 2016 por Poon e Dryja continha parágrafos que descreviam casos de uso como usuários podendo pagar por cada megabyte de tráfego de internet consumido ou cada segundo de vídeo que eles assistissem. Na verdade esses casos de uso para pagamentos pequenos e muito frequentes podem não ser possíveis, ao menos não com a tecnologia atual. Abaixo do limite de dust, para pagamentos abaixo desse número de satoshis, os pagamentos não são de modo algum assegurados pelos HTLCs. Eles não herdam a segurança da primeira camada do Bitcoin como pagamentos Lightning maiores fazem. Nessa faixa entre 546 e 2500 satoshis, esses pagamentos são menos eficientes do que poderiam em teoria. Quanto mais próximos do valor limite de dust, mais profundo é o efeito. Observamos que esse efeito é estável na atual Lightning Network até meados de 2019. A propósito o limite de HTLC é também a base de um ataque de negação de serviço localizado, discutido brevemente em nosso paper. Nós fazemos alguns cálculos de guardanapo sobre quanto valor o atacante precisaria comprometer para esse ataque. Acontece que houve ataques descritos na literatura em que o atacante pode bloquear capacidade ao longo de uma rota quando o atacante inicia o pagamento e inicia uma série de HTLCs, mas então não os resgata do lado do destinatário, o que significa que a capacidade em todos os canais fica bloqueada pela duração do timeout, que pode ser bastante longa. Aqui com esse limite de HTLCs podemos fazer a mesma coisa, mas com um capital bem menor. O atacante seria capaz de bloquear a capacidade nos canais apenas mandando 1000 micropagamentos, mas não os finalizando, o que requer pouco dinheiro comparado com as outras possíveis formas de conseguir o mesmo efeito.

Deixe-me sugerir três papers que citamos em nosso paper e que me parecem relevantes para o que eu descrevi. Malavolta e co-autores descreveram para "cadeados" multi-hop anônimos para escalabilidade e interoperabilidade na blockchain. Esse trabalho sugere um mecanismo criptográfico que possibilitaria à Lightning Network se afastar dessa arquitetura em que cada atualização de canal ao longo da rota é conectada com outras atualizações na mesma transação pelo mesmo hash do pagamento, o que permite que nodes intermediários conectarem as partes de um mesmo pagamento. Isso é ruim para "anonimidade da relação". E essa é uma proposta para corrigir o problema.

Esse é um paper que apareceu concomitantemente a nossa pesquisa e eles entraram em mais detalhes a respeito do vetor de negação de serviço que descrevi no último slide. Como os ataques de congestão em redes de canais de pagamento podem funcionar e como um atacante com relativamente pouco capital pode bloquear grandes quantias na Lightning Network.

Finalmente esse trabalho, "Lockdown: Balance Availability attack against Lightning Network" também propõe um vetor de negação de serviço para a Lightning Network que vocês podem ler e comparar com nossa abordagem.

A Lightning Network é um campo de estudos empolgante para pesquisadores de privacidade e segurança com esse novo modelo de privacidade e esse novo modelo de segurança, novas suposições de segurança comparada ao Bitcoin. Isso a torna um campo de estudos excitante e consigo prever muitos papers interessantes por vir. Vamos torcer para que não apenas eles levem a publicações em conferências e revistas de prestígio como também acarretem melhorias nos protocolos e implementações Lightning para que todos possamos nos beneficiar de pagamentos rápidos, confiáveis, seguros e privados no Bitcoin, seja pela camada 1 ou camada 2 e possivelmente futuras camadas 3 ou algo assim.

Vou deixar aqui um link para o paper mais uma vez. Muito obrigado ao Pedro e ao Matteo. Muito obrigado à Universidade Técnica de Viena por me hospedar no verão de 2019 para uma visita de pesquisa. Vocês podem me seguir no Twitter nessa Twitter handle.