Prova matemática de que a Lightning Network não pode ser uma Solução de Escala Descentralizada para o Bitcoin

Tempo de Leitura: 14 minutos

Já ouviu falar da Lightning Network do Bitcoin? É uma proposta que clama que

“Usando uma rede de canais de micropagamentos, Bitcoin pode escalar para bilhões de transações por dia”

O que isso não está te contando é que isso só pode ser alcançado usando grandes e centralizados Hubs “bancários”.

Muitos na comunidade Bitcoin assumiram erroneamente ou foram levados a acreditar que a Lightning Network (LN) seria uma rede peer-to-peer distribuída.

Entretanto, isso é inviável. Na verdade, mesmo usando uma série de pressuposições generosas, nós vamos provar que é matematicamente impossível.

Vamos dividir esse documento em seções. A parte um será um brief geral da LN. A parte dois irá explicar em termos simples porque não pode prover escala descentralizada. E a parte três será uma prova matemática mais rigorosa.

Parte 1: Panorama da Lightning Network

O Debate sobre a capacidade de escalar do Bitcoin

Bitcoin foi originalmente desenhado para ser um dinheiro peer-to-peer que poderia escalar com simples aumentos do tamanho dos blocos. Entretanto, a discussão em como escalar a rede se tornou mais complicada e controversa.

57 desenvolvedores do Bitcoin “Core” assinaram seu suporte a um apoio oficial de aumento da capacidade que advoga que a Lightning Network é uma “mecanismo de escala” sem uso de rede que pode prover uma descentralização muito alta.

Nós discordamos e iremos provar que não. Após ler e entender a informação aqui, nós recomendamos que vocês cheguem as suas próprias conclusões.

O que é a Lightning Network e como ela funciona?

Lightning Network é um protocolo que permite uma série de canais de pagamentos bidirecional offchain. Aqui está uma excelente série de três etapas feitas por Aaron van Wirdum, caso você queira entender as tecnicalidades.

Bidirecional significa simplesmente duas direções, então assim Alice e Bob poderiam abrir um canal privado e mandar bitcoins pra frente e pra trás, (fora da blockchain):

Para abrir um canal, um ou as duas partes tem que depositar bitcoins eu um endereço de bitcoin especial. Depois disso, eles podem fazer quantas transações quiserem dentro do canal, até que um deles decida fechar o canal, que então se encerra (paga os apropriados balanços finais) na blockchain principal do Bitcoin.

Linkando múltiplos canais

Indo um passo adiante, se alice tem um canal com Bob, e Bob tem um canal com Carol, então Alice poderia mandar dinheiro indiretamente para Carol: bob primeiro pagaria carol e depois Alice reembolsaria Bob.

A Rede Almejada

Os evangelistas da LN promovem a ideia de que se Alice pode pagar a Carol através de Bob, nós devemos continuar a estender essa ideia para construir uma rede inteira de canais de pagamento, assim permitindo uma larga porcentagem de transações de ocorrerem off-chain.

Entretanto, isso não pode ser alcançado realisticamente como uma rede peer-to-peer, pelo menos não de um tamanho significativo.

Semântica “Descentralizada” vs “Distribuida”

Nas conversas diárias sobre Bitcoin, muitas pessoas dizem “descentralizado” para querer dizer o que na verdade é uma topologia distribuída.

Por outro lado, uma rede com hubs centralizados pode ser chamada tecnicamente de descentralizada, se não tem um só centro.

Mas, não vamos ficar presos em jogos de palavras. O diagrama abaixo deve clarear as coisas.

Parte 2: Uma explicação para o leigo: por que a Lightning Network não pode escalar

Eu vou fazer essa explicação o mais curta que eu posso.

Primeiro, você precisa entender que a Lightning Network não é como outras redes que você pode simplesmente conectar para outro usuário sempre que você quiser.

Para enviar ou receber bitcoins, você precisa ou de um canal de pagamento com aquele usuário específico, ou uma série de canais ligados (uma “rota”).

É sem sentido criar um canal de pagamento apenas para o propósito de mandar uma transação off-chain, já que é requerido que haja uma transação on-chain para abrir o canal (e outra para fechar). Você poderia mandar simplesmente uma transação on-chain ao invés disso, você não precisa da LN.

A ideia é que você devia ser capaz de rotear seu pagamento para qualquer destinação através de uma série de conexões. Do ponto de vista do usuário, o caminho possível para qualquer outra pessoa parece como uma estrutura de arvore:

Começa como um problema matemático básico.

Vamos assumir que o propósito é escalar para 1 milhão de usuários.

Vamos pensar sobre isso: se você tem uma arvore com 10 ramos, cada um dos ramos tem 10 folhas, você pode chegar a 100 folhas.

E se você tem uma planta com 10 ramos, cada uma com 10 subramos e cada um desses tem 10 subramos, etc…. você pode ir a 6 níveis de profundidade e ter: 10 x 10 x 10 x 10 x 10 x 10, ou simplesmente: 10⁶, o que equivale a um milhão.

Então como você precisa pular de galho em galho 6 vezes para alcançar a folha, nós podemos dizer que temos 6 pulos. Então 10 ramos com 6 pulos, ou em nosso caso: 10 canais com 6 pulos.

Então, qual o desafio?

Seu dinheiro não pode estar em dois lugares ao mesmo tempo

Se assumirmos que precisamos de 10 pagamentos para chegar na rede completa com 6 pulos, significa que você tem que dividir seus bitcoins em 10 partes.

Mas, provavelmente apenas um dos canais chegará no recipiente desejado no tempo requerido. Isso significa que você só será capaz de mandar parte do seu dinheiro, por exemplo 10%.

Poderíamos simplesmente sair dessa por ter 2 canais e termos, digamos, 20 pulos? Iremos voltar depois a essa questão. Primeiro, vamos entender outro fato importante:

Todo mundo está emprestando para todo mundo

Imagine que Alice quer mandar 1 BTC para a Carol através de BOB como: Alice->Bob->Carol

Para rotear esse dinheiro, Bob precisa possuir pelo menos 1 BTC em seu saldo nesse canal com Carol. Essencialmente, Alice está emprestando a Bob para pagar Carol.

Bob transfere seu 1 BTC para Carol em seu canal [Bob->Carol], e Alice transfere seu 1 BTC para Bob em seu canal [Alice->Bob]. É assim que funciona, — Alice não pode “dar” o 1 BTC para BOB para então passar ele para Carol.

É realmente um empréstimo porque a rede usa timelocks para eliminar riscos de custódia. Alice não pode repagar o valor a Bob até que ela esteja certa de que Bob pagou Carol.

Na verdade, cada pulo na rota para o destino preciso ter os fundos disponíveis para cada transação. Então quanto mais pulos forem usados, mais o valor emprestado será multiplicado.

Porque esse é um grande problema?

Isso significa que um número muito grande de pulos é um destruidor de negócios.

Digamos que todos estejam usando rotas com 20 pulos e que a maioria dos usuários gastem em torno de $1000 por mês. Se todos usarem sua justa parte para hostear os pagamentos da rede, cada usuário precisaria rotear $20000 por mes.

Isso sequer seria possível?

Isso depende de muitos fatores incluidno: a quantidade de tempo requerida para uma rota e o número de transações.

Mesmo se nós fizermos (a possivelmente generosa) pressuposição de que um usuário pode rotear 20X mais do que transaciona e só sofrer uma redução de 50% na disponibilidade de seus próprio canais, então ele precisaria dobrar o número de canais que ele normalmente teria.

Na realidade, é muito pior.

Tem pelo menos 5 problemas adicionais que na verdade pioram a situação.

Mesmo com a matemática básica que nós começamos com 10⁶ = 1,000,000 não é exatamente aplicável. Se nós assumirmos peers que formam conexões em sua maioria randômicas sem uma autoridade central para planejar as rotas, então tem certa probabilidade de sucesso. Como uma chance em um milhão, que repetida um milhão de vezes, apenas produz uma taxa de sucesso de 63%. Escolher 2 milhões de vezes aumenta isso para 84% o que significaria aumentar o número de canais.
Na medida que usuários gastam seus recursos, as rotas disponíveis decaem, até que mais recursos sejam depositados. Em outras palavras, quando uma pessoa recebe o pagamento de um salário e deposita fundos na rede, seus canais estão no máximo, na capacidade total de roteamento. Mas, na medida em que seu dinheiro é gasto, seu poder de roteamento dropa tendendo a zero. Na média, esse padrão corta o poder da rota pela metade, requerendo o dobro do número de canais.
Fundos para roteamento para outros desregula uma distribuição que de outra forma seria regular, o que também diminui o número de canais usáveis.
Tem uma desigualdade de renda grande em qualquer população. Assim, o número de usuários que podem rotear fundos para qualquer outro usuário randomicamente é uma parte da rede. E esse problema é aumentado exponencialmente com o aumento do número de pulos.
Sempre existe um risco de um canal de roteamento se tornar irresponsível (seja intencionalmente ou não intencionalmente). O risco aumenta exponencialmente com o número de pulos em aumento.

O Sumário TLDR

Para chegar em alguém em uma rede grande com uma série de coneções de ramos de canais, você precisa ou de um grande número de canais, ou de um grande número de pulos.

Os dois são um grande problema. Um largo número de canais significa que os usuários terão que dividir seus fundos e não fazer nada além de minúsculos pagamentos. E um largo número de pulos significa que o dinheiro de todos estará preso roteando o dinheiro de todos.

Conclusão: Um sistema completamente impraticável

Na medida que a rede chegue a milhões de usuários, parece que não haverão formas realísticas de evitar esses problemas. Dividir fundos em muitos canais e continuar a emprestar dinheiro, os dois farão a rede não ser usável.

As únicas soluções concebíveis são A) todos irão depositar muito mais do que eles precisam transacionar, ou B) o sistema depende de grandes hubs centralizados.

Ou não é uma solução descentralizada, ou não é parte de uma solução maior que o seja.

Parte 3: Prova matemática informal

Pressuposições:

Modelar uma rede teórica que não existe realmente, de um grupo largo de pessoas diversas, é obviamente impossível de fazer precisamente. Nós sabemos que estamos fazendo um certo número de pressuposições, algumas estabelecidas, outras implicitas e algumas generosas aos críticos dessa prova.

Nesse contexto, nós queremos demonstrar, através de calculos probabilíticos, que um largo número de canais abertos seriam necessários para cada usuário, fazendo o sistema impraticável com o tamanho de 1.000.000 de usuários.

Canais e pulos requeridos, sem restrições.

Ao modelar uma rede com um gráfico complexo de 1.000.000 de nodes, nós devemos examinar a probabilidade de chegar a um peer random dado um determinado número de canais abertos, C, e que permitem um certo número de pulos, H.

Da perspectiva do usuário, chegar a peers distantes através de uma série de canais rameados é similar a uma estrutura de arvore. O número de folhas aumenta exponencialmente e são possíveis destinos de transações.

Para simplificar esses cálculos, vamos ignorar a possibilidade de que um ramo em uma arvore possa linkar a outro ramo que já está na arvore (um ancentral ou um primo).

Essa possibilidade acontecendo iria reduzir o número de pares encontrados de um branching puramente exponencial para um número significativamente menor. Já que estamos tentando provar que um relativamente pequeno número de pares pode ser chegado sem um número grande de canais e pulos, então o número real seria ainda menor, sendo essa uma pressuposição generosa (aumentando a força da prova).

Que N seja o número de folhas, definido por C^H. Por exemplo, 10 canais abertos e 6 pulos, 10⁶ = 1,000,000.

A probabilidade P de falhar para selecionar um membro do conjunto |N| com cardinalidade n ao pular N vezes, com substituição é:

No nosso caso, obter um destino desejado ao encontrar uma folha.)

Nós podemos generalizar isso com essa forma limitada

Já que 1/e = 0.3678… então a probabilidade de escolher corretamente ao menos uma vez é de (1- (1/e)) = 63.21…%

Tendo acesso a qualquer dado par numa taxa de apenas 63,21% é muito baixa para ser considerada bem sucedida para um sistema de pagamento.

Usando um número diferente de tentativas pode ser expresso como:

Por exemplo:

Ao tomar vários expoentes de e, nós podemos calcular as probabilidades correspondentes:

Usando um valor de 1,000,000 de usuários e a forma limitada, nós podemos derivar a fórmula:

Usando essa fórmula, nós podemos calcular alguns valores iniciais chegando ao nível de ao menos 80% de probabilidade, entretanto isso não está considerando outros fatores que não foram discutidos até então:

Canais e pulos requeridos com uma restrição monetária simples

Todos os pulos ao longo da rota precisam ter fundos o suficiente para processar qualquer pagamento que eles queiram servir. Isso é a restrição monetária.

Modelar uma rede de milhões de usuários com uma variedade larga de perfis financeiros e padrões de gasto não é possível de ser feito precisamente porque existem fatores desconhecidos demais.

Entretanto, nós podemos fazer uma pressuposição de senso comum que muitos e a maioria dos usuários irá receber algum tipo de salário em algum tipo de intervalo regular, e depositar uma mesada de fundos dentro da LN para gastar.

Fundos depositados irão geralmente serem ou gastos ou retirados. (vamos assumir que a LN não é usado como um meio de reserva).

Na medida em que usuários gastam seus fundos, a disponibilidade dos fundos para roteamento doscanais de pagamento irá diminuir, seja porque um canal irá fechar, ou porque o valor disponível diminuirá. Quando fundos adicionais forem depositados, as capacidades da rota serão revitalizadas.

Nós não temos um modelo de quais e quantos usuários estão sendo pagos, quanto, quando e com que frequência. Entretanto, nós podemos agregar um comportamento de um conjunto de usuários graças a lei dos grandes números, que estabelece que ” a média de resultados obtidas de um grande número de tentativas deve ser próxima do valor esperado”.

O ciclo típico do consumidor consiste em receber salário, gastar e então repetir. Nós podemos generalizar esse comportamento em um onda em formato de dente de serra reverso:

Visualmente, ele irá aparecer dessa forma:

Pagamentos de salários são representados como picos, e o salário é então gasto gradualmente até o próximo pagamento.

Integrando a função concede metade do valor do período, como esperado:

Isso também é aparente visualmente na medida em que as ondas formam triangulos cortando metade da área.

A implicação é que mais ou menos metade dos canais usados para rota estariam inválidos. Além disso, o número de canais em cada pulo precisa ser dobrado. Nossa fórmula de probabilidades muda para:

E a tabela com nossos resultados se torna:

Além disso existe também a enormemente generosa pressuposição que estamos fazendo de que todos os usuários seriam uma parte útil para o roteamento de todos os outros usuários. Na realidade, uma distribuição largamente irregular de recursos iria por adicionais e mais significativas restrições ao sistema.

A restrição adicional do empréstimo

Em adição aos problemas de dividir fundos e encontrar rotas, nós assumimos que o usuário que participar na rede também ajudará a outros a rotearem pagamentos.

Isso irá perturbar o usuário de duas formas.

Primeiro, poderá provocar que a distribuição dos fundos pessoais do usuário irão se tornar desbalanceados, diminuindo o número de rotas disponíveis. Ao longo do tempo, isso poderia teoricamente ser superado com dinheiro fluindo em qualquer direção para qualquer canal. Entretanto, cada usuário iria encontrar um grau elevado de variação em qualquer tempo dado.

O segundo é que o dinheiro usado em rotear o pagamento de outros não está disponível para o usuário durante o tempo que a rota está em uso.

Nós devemos generosamente ignorar a primeira causa da disrupção e simplesmente focarmos em modelar o segundo. Nós vamos tomar a abordagem simplista de assumir que todos os usuários terão o mesmo número médio de transações e volume de gastos e assumiremos que todos os usuários participarão igualmente no roteamento.

Vamos definir as seguintes variáveis:

U: o número de usuários
H: o número de pulos
V: o volume total de transação da rede durante um período de tempo
v: o volume de transação por usuário durante um período de tempo
r: o volume total roteado por usuário durante um período de tempo

D: a duração em horas de um período de tempo medido
t: o número médio de transações por usuário para o período de tempo D
d: a duração em horas da rota média

Já que cada pulo precisa rotear o valor inteiro da transação para qualquer transação na rota que ele participa, o volume total roteado para a rede inteira durante o período de tempo é = VH. Então, r= VH/U. E já que V/U=v, r=Hv.

Por exemplo, se v=$1000, a fórmula parece como:

Vamos introduzir o conceito de horas-dolar para mensurar a capacidade de roteamento.

Cada usuário pode gastar seu dinheiro apenas uma vez, claro. Mas, para propósitos de rotear dinheiro para os outros, nós podemos pensar nas horas-dólar como os dólares totais em seus canais, multiplicados pelo número de horas disponíveis. Por exemplo, $1000 permanecendo não movido por uma semana equivale a 168,000 horas-dólar.

Então podemos calcular um quociente Q, que representa a porcentagem da capacidade disponível que permanece após rotear para outros:

Q = 1- (d(H-1))/D

Note que v e t não aparecem na equação na medida em que eles foram fatorados para fora, mas eles estão ali implicitamente na proporção d/D. A razão para H-1 é que um pulo não custa a rede nada além que as próprias transações do usuário (r=Hv).

Por exemplo, se a rede usa 4 pulos, e as rotas requerem 4 horas, e os fundos dos usuários para rotar são baseados em 168 horas (1 semana), então:

Q=1- ((4)*(3))/168 ) = 0.92

Nossa formula probabilística é agora:

Assumindo que D=168, e que o tempo de roteamento seja d = 4 hours, chegamos nas seguintes probabilidades:

Determinando as limitações das transações baseado em uma distribuição de Pareto

É difícilmente necessário provar que se os fundos fossem divididos em pequenos bolsos, então isso teria um efeito enormemente negativo na sua usabilidade. Entretanto, para maior completude, nós incluímos essa sessão.

Nós assumimos que a maioria dos gastos de consumidores e negócios seguem uma distribuição de Pareto em que cada usuário faz um relativamente pequeno número de grandes transações, muitas transações de médio tamanho e um número maior de pequenas transações.

A densidade da função de probabilidade de Pareto é expressa em:

Para a curva de pareto mais simples de tipo 1, isso simplificará para:

A distribuição não muda ao aplicar restrições, mas nós podemos visualizar melhor esse modelo com alguns valoresdo mundo real ao multiplicar os valores de Y por 1000, assim os valores em dólar para itens maiores se tornam mais substanciais, e integrando um conjunto típico de X valores (número de transações em cada valor de dólar), digamos 50 .

A soma total das transações = $980. Usando uma porcentagem de 10% sobre $98, nós podemos resolver essa equação: 98 = 1000/x² para obter 3.194 transações.

Depois, nós iremos integrar o conjunto menor de transações para obter o valor somado das transações que tem tamanhos que são menores do que nosso valor mínimo de $98.

Já que 293.48/980=.299, nós podemos dizer que apenas 29.9% de toda a atividade econômica desejada seria possível se 10 canais fossem usados.

Pensamentos finais

Eu espero que os críticos se prendam a detalhes. Eu encorajo que você tenha seu próprio pensamento crítico. Não se esqueça das pressuposições generosas que nós fizemos para ignorar a disparidade de renda.

Lembre-se Bitcoin precisa ser descentralizado. Tome cuidado com a racionalização de “Centralização está ok enquanto a camada base se mantiver descentralizada”. Essa é uma armadilha que força usuários para fora da camada base e em sistemas centralizados. Nunca devemos permitir isso.

Então, o Bitcoin está com problemas porque as soluções de segunda camada podem não funcionar? Não, não mesmo. Bitcoin foi designado para escalar on-chain com simples aumentos do tamanho do bloco. Ele pode e irá, se permitirmos.

Adendo

Eu publiquei uma curta réplica a algumas objeções e desentendimentos desse artigo.

Update 7 de Junho de 2018.

As predições nesse artigo se provaram corretas na medida em que já estamos vendo a rede formar hubs centralizados. A narrativa dos apoiadores da LN agora está mudando para “ok é centralizado, mas não se preocupe sobre isso”. Para entender porque hubs centralizados levam a censura econômica, clique aqui.

Traduzido de Jonald Fyookball